跨地域流量切换如何设计？

简化版

跨地域切流要先确认目标地域的数据水位、写权和剩余容量，再通过 GSLB、Anycast、网关或 DNS 分级迁移流量，并持续校验业务与数据。 切流不是单改 DNS：客户端缓存、长连接、出口白名单、会话和数据归属都会影响收敛；写流量必须在 fencing 后迁移。

详细版

正常时维护稳定的地域归属和健康探针。故障时先隔离旧地域写权，计算目标地域是否满足 N-1 容量和 RPO，然后按 1%→10%→50%→100% 调整入口权重。DNS 适合粗粒度但受缓存影响，网关/VIP 更快，应用层路由可按租户稳定切换。

全过程监控各地域 QPS、成功率、P99、跨区带宽、复制 lag、缓存命中和业务转化。客户端会话应外置或可重建，目标地域提前配置证书、密钥、第三方白名单和配额。恢复原地域属于 Failback，不能自动反向切回。

完整版教学

一、切流包含控制面和数据面

控制面决定用户去哪个地域，数据面决定该地域能否给出正确结果。只把流量导向健康应用，但数据库仍落后或无写权，会把“不可访问”变成“可访问但数据错误”。因此入口、数据和容量三项必须同时满足。

记忆钩子：流量能到只是第一关，数据够新、写权唯一、容量够用才算可切。

二、常见入口技术的差异

手段	收敛速度	粒度	风险
DNS/GSLB	秒到分钟以上	域名/地域	缓存不受控
Anycast/BGP	较快	网络前缀	路由复杂
全局网关	秒级	请求/用户	网关成为关键组件
应用路由	精细	租户/数据分区	业务耦合高

生产常多层组合：DNS 指向多地域入口，网关在健康地域间精确分配。

三、DNS 为什么不能保证按 TTL 收敛

递归解析器、操作系统、JVM 和应用连接池都可能缓存地址；已有 TCP/HTTP2 长连接也不会因 DNS 改动立刻断开。TTL=30 秒不代表 30 秒后全部切完。应实测各客户端分布，并通过连接排空、网关摘流等手段补充。

DNS change -> recursive cache -> OS/JVM cache -> connection pool -> new request

四、数据与写权的切换顺序

先停止或 fencing 旧地域写，确认目标副本达到可接受恢复点，再提升写权并切写流量。读流量可以先小比例验证，但如果读取会触发副作用也要受控。异步复制落后 20 秒且业务 RPO 只允许 5 秒时，不能贸然提升。

分区多活则按租户或 shard 转移 ownership，每份数据带 epoch。旧地域收到更低 epoch 的写必须拒绝，防止缓存路由造成双写。

五、容量和冷启动推演

两个地域各承担 50%，目标地域当前 CPU 60%。全量接管后近似需要 120% CPU，还没计算缓存命中下降和重试，显然不可行。可先关闭非核心功能、预扩容并预热热点数据，把接管后安全水位控制在例如 70%。

假设缓存命中从 95% 降到 80%，10000 QPS 的数据库回源会从 500 增到 2000 QPS，数据层容量也要提前验证。

六、分级切流和退出条件

按稳定 userId/tenantId 分桶切 1%、10%、50%、100%，每级要求最少样本和观察时间。护栏包括错误率、P99、复制 lag、数据库水位、跨区费用和业务成功率。异常时把流量退回仍具权威写权的一侧，不能出现双方都接受写。

记录切换 epoch、权重、操作者和每阶段指标。切完后继续观察旧连接、新会话、消息消费和数据差异；原地域恢复后走独立 Failback。

七、常见误区与追问

• 误区：把 DNS 权重改成 0 就全量切完。 多层缓存和长连接仍保留旧路径。
• 误区：应用健康即可接管写流量。 还需数据追平和唯一写权。
• 误区：双地域各 50% 天然能互相接管。 剩余地域可能没有两倍容量。
• 误区：恢复后自动切回延迟最低地域。 回切涉及数据追平和新一轮写权转移。
• 追问：如何处理会话？ 使用跨地域可用状态、签名无状态会话或要求重登录，并明确取舍。
• 追问：如何缩短 DNS 影响？ 低 TTL 只是基础，还需网关、连接排空和客户端刷新。
• 追问：第三方依赖怎么办？ 预配置出口 IP 白名单、证书、配额并在演练中真实调用。

八、加强记忆

跨地域切流按“入口可控、数据达标、写权唯一、容量足够、分级放量、持续验证”展开。DNS 只是其中一层，长连接和客户端缓存决定真实收敛；数据 epoch 与 fencing 决定安全。切走和切回都是完整变更，不能互相替代。

切流观察不能只看目标地域是否有请求，还要看源地域是否仍有残留写入；只有两侧流量与数据水位共同收敛，才能判断迁移完成。

对于无法强制刷新的客户端，应保持旧入口可转发或返回明确迁移指令，直至覆盖其最长连接和缓存生命周期。