解读

在国内金融、电商等高并发场景下，Cloud SQL 的只读副本常被用来做读写分离。负载均衡（如 GCP 自带的 Cloud Load Balancing 或客户自建的 Spring Cloud 网关）需要把读流量实时地分发到延迟最小的副本，否则会出现“用户刚下单却查不到订单”的幻读事故。
“副本延迟阈值”就是只读副本与主实例之间允许的最大复制延迟时间，单位毫秒。健康检查会把该阈值作为硬指标：一旦某副本的延迟超过阈值，负载均衡器立即将其标记为不健康，不再转发新连接；延迟回落后自动恢复。该机制直接决定了读库池的可用容量与用户体验的一致性。

知识点

1. 监控指标：replication_lag 由 Cloud SQL 内部采集，对应 MySQL 的 Seconds_Behind_Master 或 PostgreSQL 的 pg_stat_replication.flush_lag。
2. 阈值配置：在 GCP Console 的只读副本详情页 → 高可用与复制 → 副本延迟阈值，可设 0–600,000 ms；0 表示不允许任何延迟，一旦 lag>0 立即摘流。
3. 健康检查协议：
   • TCP 探测：只检查端口 3307/5432 是否可连接，不感知延迟。
   • HTTP 探测：客户需自建 /readiness 接口，内部查询 SHOW SLAVE STATUS 或 pg_stat_replication，把 lag 与阈值比较后返回 200/503。
   • Cloud Monitoring 探测：直接引用指标 cloudsql.googleapis.com/database/replication/replica_lag，在 alerting policy 里设置阈值，与负载均衡后端服务联动。
4. 国内合规：银行监管要求RPO<1 秒，通常把阈值设在 500 ms；互联网秒杀活动可放宽到 2 s，以换取更高并发。
5. 风险：阈值过小会导致频繁抖动，副本反复上下线，连接池不断重建，可能触发连接风暴；阈值过大则会让业务读到过期数据，引发客诉。

答案

“副本延迟阈值”是 Cloud SQL 只读副本与主实例之间允许的最大复制延迟。负载均衡健康检查把它作为关键判活条件：当监控指标 replication_lag 超过该阈值时，健康检查立即返回失败，负载均衡器把该副本踢出后端池，读流量不再分发；延迟回落到阈值以内后，副本被重新标记为健康，流量自动恢复。
合理设置阈值能在数据一致性与后端可用性之间取得平衡：国内金融场景建议 500 ms，互联网业务可放宽到 1–2 s；同时需配合连接池重试策略与熔断器，防止因阈值过小引发抖动。

拓展思考

1. 双阈值策略：在 Terraform 里定义两个 alerting policy——warning 阈值为 1 s，critical 为 3 s。warning 时只告警，critical 才触发负载均衡摘流，既提前发现隐患，又避免误杀。
2. 只读副本预热：国内大促前用 Sysbench 压测，把副本延迟推到阈值附近，观察健康检查 QPS 曲线，确认不会频繁上下线；压测结束立即调回正常阈值。
3. 跨域容灾：如果主实例在北京 Region，副本在上海 Region，网络 RTT 本身 30 ms，阈值必须大于 RTT，否则正常复制也会被误判；可设置 200 ms 并开启并行复制降低 lag。
4. 与 IAM 联动：把“修改副本延迟阈值”权限单独授予SRE 团队，开发团队无权调整，防止因随意改小阈值导致线上事故。