SQL异地多活核心是解决一致性、延迟、故障隔离与流量调度四大问题，需结合应用协同、中间件路由与同步机制；数据同步依业务选强一致（Paxos/Raft）或最终一致（binlog+Kafka）；流量按单元化路由，跨单元写异步补偿；故障时依赖熔断、降级与本地数据自治；灾备切换重演练，元数据变更须全节点同步。
SQL数据库实现异地多活，核心不是简单复制数据，而是解决一致性、延迟、故障隔离与流量调度四大问题。单靠主从复制或双写无法支撑真实多活，必须结合应用层协同、中间件路由与数据同步机制设计。
数据同步：强一致 vs 最终一致的取舍
金融类业务通常要求跨地域强一致，需采用基于Paxos/Raft的分布式事务方案（如TiDB、OceanBase），或通过两阶段提交+全局时钟（如Google Spanner）。普通业务可接受秒级延迟，用基于binlog解析的异步复制（如Canal + Kafka + Flink）更轻量、扩展性更好。关键点在于：同步链路需具备断点续传、冲突检测与自动修复能力，避免因网络抖动导致数据漂移。
流量调度：读写分离与单元化路由
异地多活不是所有节点都处理全量请求，而是按“用户ID哈希”或“城市归属”划分逻辑单元（Cell），每个单元包含完整读写能力。应用层通过路由中间件（如ShardingSphere、自研RouteSDK）将请求精准打到所属单元的本地数据库。跨单元写操作（如修改非本单元用户信息）需走中心化服务或异步消息补偿，避免强依赖跨地域写入。
故障隔离：熔断、降级与数据自治
任一机房故障时，其他机房应能独立提供服务。这要求：数据库连接池支持自动剔除异常节点；应用层配置超时与重试策略（如读超时300ms、最多1次重试）；本地缓存（如Redis）预热关键数据，支撑短时降级读；每个机房保留最小可用数据集（如用户基础信息+本地订单），不依赖远程查询补全。
灾备切换：演练比方案更重要
自动切换易引发脑裂或数据覆盖，建议以“人工确认+半自动执行”为主。每次大促前需开展真实断网演练：模拟某地机房失联，验证DNS/SLB切流时效、数据延迟水位、应用报错率及监控告警完整性。切换后重点核验三类数据：账户余额（资金类）、订单状态（状态机）、库存扣减（幂等性），确保无资损、无重复、无丢失。
不复杂但容易忽略的是元数据一致性——表结构变更、索引调整、权限配置必须在所有活节点同步生效，否则会引发SQL执行失败或查询结果异常。建议将DDL纳入发布流水线，经灰度验证后再批量推送。
