解读

在国内云原生面试中，这道题考察的是候选人对 Cloud SQL 高可用链路 与 客户端重连行为 的闭环理解。
面试官真正想听的是：

1. 故障转移（Failover）瞬间，Proxy 与后端实例的 TCP 连接是否仍然有效；
2. 如果连接中断，Proxy 自身有没有内置指数退避重试；
3. 作为开发者，你是否需要 在应用侧再做一层重试或连接池刷新，才能保证业务零感知。
   一句话，“Proxy 会帮你重连，但不会帮你重试业务 SQL”，这是区分“只背八股”与“真踩过坑”的关键。

知识点

• Cloud SQL 高可用架构：采用跨区域主从（Regional HA）+ 自动故障切换，切换后 IP 不变、连接字符串不变，但底层实例已切换，原 TCP 连接被强制 RST。
• Auth Proxy 工作原理：本地进程监听 127.0.0.1，把 OAuth2/IAM 鉴权 封装进握手，再与 GCP 控制面建立 TLS 1.3 长连接 到实际实例。
• 重连策略：Proxy 1.33 版本之后内置 指数退避重试（最大 32 s 间隔、累计 5 min），仅针对 “连接建立阶段”；一旦连接进入 ESTABLISHED，后续网络闪断由 内核 TCP Keepalive 感知，Proxy 会 重新拨号，但 不会重放已失败的 SQL。
• 国内网络差异：由于 跨境链路 RTT 高、GFE 入口偶尔丢包，建议把 Proxy 的 --max-connections 调到 1 万以内，并开启 --health-check 周期 30 s，提前触发重连，减少业务受损窗口。
• 应用侧兜底：Java 连接池（HikariCP）需配置 connectionTestQuery 与 connectionTimeout；Go 需用 database/sql 的 SetMaxIdleConns + Ping 主动驱逐失效连接；否则会出现 “连接池僵尸” 导致持续报错。

答案

不会自动重试业务 SQL，但会自动重连底层通道。
具体过程：

1. 故障转移完成瞬间，原主实例被置为只读并强制断开所有 TCP，Proxy 收到 RST；
2. Proxy 立即检测到 “backend down”，关闭本地 socket，进入 指数退避重连循环；
3. 一旦新主实例在控制面注册完成，Proxy 拿到新后端 IP，重新完成 IAM 鉴权握手，建立新 TLS 隧道；
4. 此时应用侧旧连接已失效，需要连接池或应用代码捕获 “connection reset by peer” 错误后主动重试；
5. 若应用使用 Cloud SQL Language Connectors（Java、Python、Go 版），则内置 自动重试一次 的语义，可进一步降低感知延迟。

因此，Proxy 帮你解决了“重连”与“鉴权刷新”，但“重试 SQL”必须留给应用或连接池完成，这是生产零中断的完整方案。

拓展思考

• 国内双活场景：如果业务要求 RPO=0、RTO<30 s，可叠加 Cloud SQL 跨区域只读副本 + 内部负载均衡（ILB） 做读写分离；故障时通过 Traffic Director 把读流量切到备区域，写流量等待 Proxy 重连完成，整体 SLA 可做到 99.99%。
• Terraform 一键演练：用 google_sql_database_instance 的 deletion_protection=false 起一套 Regional HA 实例，再写 null_resource 调用 gcloud sql instances failover 做 混沌工程，观察 Proxy 日志是否出现 “reconnecting in 1s…2s…4s…” 的退避序列，验证重连策略生效。
• 成本陷阱：Proxy 常驻进程会占用 每个 Pod 50 MB 内存；在大规模 Sidecar 场景下，1 k Pod 就是 50 GB 内存开销，国内用户常忽略这笔隐形费用，可通过 集中式 Proxy Pool 或 Workload Identity 直连 Private IP 优化。