描述主备同步在“同步提交”与“异步提交”模式下的 RPO 差异。 - 问题详情 - 创脉思

解读

国内面试官问这道题，核心想确认两件事：

你是否真正理解 RPO（Recovery Point Objective） 的业务含义——“最多能丢多少数据”；
你是否能结合 Cloud SQL 的 跨区域高可用（HA）与只读副本（Read Replica） 架构，把“同步/异步”对应到 数据落盘位置 与 事务提交 ack 时机，从而给出可量化的 RPO 区间。
回答时务必先给出 RPO=0 与 RPO>0 的量化结论，再用 Cloud SQL 原生机制解释“为什么做不到绝对 0”以及“国内网络条件下异步模式的典型 RPO 范围”。

RPO 定义：灾难发生后，业务可接受的数据丢失时间窗口；单位是时间，越小越好。
同步提交（Synchronous Commit）：主实例等待 备库 redo 落盘并返回 ack 后才向客户端回包；理论 RPO=0，但受限于 RTT。
异步提交（Asynchronous Commit）：主实例 本地落盘即回包，备库延迟重放；故障瞬间备库可能尚未收到最新事务，RPO>0。
Cloud SQL 高可用实现：
- 区域级 HA：同一区域跨可用区，采用 半同步（Semi-sync）+ 并行复制，Google 内部称为 “同步复制”，但只保证 多数派（quorum）落盘 即 ack，RTT 通常 <2 ms，RPO 近似 0。
- 跨区域只读副本：基于 原生异步流复制，无 quorum 等待，国内公网或专线 RTT 30~80 ms，典型 RPO 5~30 秒；若出现大事务或网络抖动，可放大到 分钟级。
国内合规限制：金融、政企客户常要求 两地三中心，但 Cloud SQL 目前仅支持 单向异步跨区域副本，无法做双向同步，因此 RPO 不可能为 0；如需 0 丢失，必须改用 Cloud Spanner 或 自建 MySQL Group Replication + 专线。

在 Cloud SQL 的语境下：

同步提交模式（区域 HA）：主库等待 同区域备库 redo 落盘 才提交，RTT 极低，RPO 近似 0；极端双可用区同时故障场景下，Google 仍保证 多数派副本已落盘，故数据不会丢。
异步提交模式（跨区域只读副本）：主库 本地提交即返回，事务通过 异步流复制 发送到国内另一区域，副本应用延迟取决于 事务大小、网络 RTT、IO 带宽，正常负载下 RPO 5~30 秒；大事务或网络抖动时可膨胀到 分钟级。
因此，两者核心差异是：同步模式 RPO≈0，异步模式 RPO>0 且不可控到秒级甚至分钟级；国内若需监管级 0 丢失，应优先使用区域 HA，而非跨区域异步副本。

面试官可能追问：

“如果业务必须跨城 0 丢失，Cloud SQL 做不到，你怎么办？”
答：可 专线+自建 MySQL Group Replication 或 评估 Cloud Spanner；若坚持用 Cloud SQL，只能 缩小异步副本延迟：
- 开启 并行复制（ replica_parallel_workers ）；
- 把 大事务拆小、避免 DDL 高峰；
- 使用 Private Service Connect + 专线 降低 RTT 抖动；
  但 RPO 仍无法承诺为 0，需在 SLA 里明确 “秒级到分钟级” 并接受监管备案。
“半同步会不会退化为异步？”
答：Cloud SQL 区域 HA 的半同步设有 超时窗口（默认 10 秒），若备库无响应，主库会 自动降级为异步 以保证可用性，此时 RPO 从 0 瞬间变为>0；监控指标 cloudsql.googleapis.com/database/mysql/replication/availability 可告警降级事件，运维需 立即介入排查 IO 阻塞或可用区故障。