跨机房容灾的核心目标是保障业务在主中心完全失效时于备用机房快速、一致、可控恢复服务，重点解决数据零丢失（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 无延迟）、执行步骤、回滚脚本，禁止人工敲命令
