跨机房容灾的核心目标是保障业务在主中心完全失效时于备用机房快速、一致、可控恢复服务，重点解决数据零丢失（RPO=0）、切换时间可控（RTO）等问题。

跨机房容灾的核心目标

不是简单复制数据，而是保障业务在主中心完全失效时，能在备用机房快速、一致、可控地恢复服务。重点解决三个问题：数据零丢失（RPO=0）、切换时间可控（RTO

网络与架构层设计要点

跨机房容灾依赖稳定低延迟的骨干网络。两个机房之间建议部署双活BGP链路，延迟控制在5ms以内；若超15ms，需规避强同步复制方案。关键设计包括：

• 使用DNS智能解析+健康探测实现入口流量自动切流，避免单点DNS故障
• 应用无状态化改造，会话信息统一存入Redis Cluster（跨机房部署为双写+冲突检测模式）
• 数据库采用“一主一备一异地”三节点部署，主备同城异机柜，异地机房只读+日志实时拉取

数据同步与一致性保障

不同组件需差异化同步策略：

• MySQL：主库binlog通过Canal+RocketMQ投递至异地机房，消费端用Flink做幂等写入+GTID校验，避免主键冲突；定期跑checksum比对表级一致性
• 文件存储：NFS或Ceph集群不跨机房直连，改用rclone定时增量同步+inotify实时触发，关键目录启用versioning保留历史版本
• 配置中心：Nacos或Apollo启用双写模式，通过分布式锁保证同一配置项不被并发覆盖，切换时强制刷新本地缓存

容灾切换与演练机制

真实可用的容灾能力必须靠常态化演练验证。每次演练要覆盖完整链路：

• 每月执行一次半自动切换：关闭主中心所有入口网关，观察备用中心是否在3分钟内接管全部流量并返回正确响应码
• 每季度执行一次全链路断电演练：物理切断主中心供电，验证数据库从库提升、中间件重选主、应用自动注册新服务发现节点全过程
• 所有切换操作封装为Ansible Playbook，含前置检查（如确认binlog无延迟）、执行步骤、回滚脚本，禁止人工敲命令