构建多机房冗余架构以减少香港机房出问题带来的风险

1. 目标与总体方案概述

目标：在香港机房出现故障时，能快速切换并保持业务可用。总体方案：至少两个机房（香港 + 备份机房A/B），采用跨机房负载分发、数据库复制、文件同步、DNS/BGP多路径和自动化健康检查与故障切换。简要步骤：1) 评估现状；2) 确定拓扑（Active-Active 或 Active-Passive）；3) 建立同步/复制；4) 配置流量切换与监控；5) 演练与回滚。

2. 评估现状与准备清单

步骤：1) 列出所有组件（应用、DB、缓存、文件、证书、IP白名单）；2) 统计带宽/延迟/会话粘性需求；3) 标注哪些可以异步复制、哪些必须同步；4) 确认备机房网络互联（VPN/专线/BGP）。产出：依赖清单、RPO/RTO 指标、预算。

3. 选择多机房拓扑及优缺点

Active-Active（双活）：优点切换快、流量均衡；缺点跨机房一致性复杂。Active-Passive（冷/热备）：实现简单但切换时间较长。操作建议：初期可采用Active-Passive热备（数据近实时复制），成熟后迁移到Active-Active并使用全局负载均衡（GLB）。

4. 网络层与流量控制（BGP/Anycast/DNS）

步骤：1) 与带宽/骨干提供商确认多出口BGP；2) 使用Anycast或多区域Anycast IP发布关键服务；3) DNS：将TTL降至30-60秒用于快速切换，使用支持健康检查的DNS（如Route53/Cloudflare）；4) 配置DNS故障切换策略（主机房健康检查失败则切换到备机房IP）。示例：Route53配置：创建基于健康检查的加权或故障转移记录，TTL=60。

5. 数据库层的冗余实现

关系型数据库：MySQL 可选方案——主从异步、GTID+半同步、Galera或MySQL Group Replication。实操（MySQL 主->备）：1) 在主库执行 mysqldump --single-transaction 或使用XtraBackup做全量备份；2) 在备库恢复并配置 CHANGE MASTER TO MASTER_HOST='主IP', MASTER_USER='repl', MASTER_PASSWORD='pwd', MASTER_AUTO_POSITION=1; START SLAVE; 3) 验证秒延迟。PostgreSQL：使用 streaming replication + pg_basebackup，恢复时创建 standby.signal。注意：若要求强一致性考虑同步复制或应用层幂等处理。

6. 文件与对象存储同步

静态文件：推荐使用对象存储（S3 兼容）+跨区复制；若用文件系统：1) 使用 rsync -avz --delete 主:dir 备:dir 做初始同步；2) 使用 lsyncd 进行实时同步或使用分布式文件系统（Ceph）。操作示例：lsyncd 配置 watch 和 rsync 做增量同步。大文件/媒体建议放到 CDN 并启用源站跨区复制。

7. 应用层与负载均衡器配置

步骤：1) 应用改造为无状态或把会话存到 Redis 集群；2) 部署全局 LB（Nginx/HAProxy + GLB）；3) HAProxy 健康检查配置示例：option httpchk GET /health；backend 设置 server ip:port check fall 3 rise 2；4) 如果使用云厂商 LB，启用健康检查并配置后端权重和故障转移。

8. 会话管理与一致性策略

建议：尽量无状态；若必须持久化会话，使用跨机房 Redis 主从/Cluster 或托管Redis，启用持久化和备机房只读副本。处理粘滞会话：在非关键路径禁用粘滞，或用全局Session存储（Redis或数据库）。设计幂等接口以减少切换影响。

9. 健康检查、监控与自动化切换

监控项：业务健康、延迟、错误率、DB延迟、同步延迟、磁盘空间、链路状态。工具：Prometheus+Alertmanager、Grafana、Zabbix。自动化：结合DNS提供商健康检查（或使用自建监测 + API 调用DNS切换）或 BGP 控制平面实现流量引导。故障切换流程示例：监测触发 -> 自动将主流量权重调低 -> DNS/GLB 指向备 -> 验证应用正常 -> 完成切换。

10. 演练、演练脚本与回滚步骤

演练计划：1) 定期（至少季度）演练；2) 演练步骤：灰度流量切换 -> 全流量切换 -> 回滚；3) 回滚条件：数据丢失、功能异常、性能不达标。回滚步骤：将DNS/GLB切回、同步数据增量、验证一致性。每次演练记录时间和问题，更新Runbook。

11. TLS/证书与安全注意事项

证书：使用 ACME 自动签发（Let's Encrypt）并在各机房同步私钥或统一使用全局证书管理（Vault +自动下发）。安全：防火墙规则同步、WAF 策略统一、加密链路（VPN/专线）保护机房间复制流量。保存私钥的地方要做严格访问控制。

12. 成本估算、SLA 与交付清单

估算要点：带宽、跨机房流量、双写/副本开销、CDN费用、监控告警成本。交付清单（Checklist）：DNS策略、BGP配置、DB复制验证、文件同步验证、负载均衡测试、监控告警、演练记录、回滚方案。达到既定 RPO/RTO 后进入生产化维护。

13. 常见问题与操作注意汇总

注意：1) 降低DNS TTL要在切换前一段时间调整生效；2) 跨机房同步需考虑带宽与延迟，批量初始化要在低峰期执行；3) 自动故障切换前必须保证数据一致策略明确并能回滚。

14. 问：香港机房完全不可用时，最快的流量切换实践是什么？

回答：最佳实践是结合BGP和低TTL的DNS。操作步骤：1) 事先将DNS TTL设置为30-60秒；2) 配置DNS基于健康检查的故障转移记录并准备备机房IP；3) 启用BGP多出口并预配置备机房路由；4) 发生故障时触发DNS故障转移或调整BGP路由，监测流量到位后逐步提升备的权重。演练前务必同步证书和会话存储。

15. 问：如何在切换时保证数据库不丢数据？

回答：关键在于选对复制方式与切换策略。若不能容忍丢数据，采用同步复制或半同步+应用重试；若可接受短时RPO，使用异步复制并在切换前确认已应用的binlog位置。切换步骤示例：确认主库binlog位置 -> 暂停写入或进入维护模式 -> 确保备库追上主库 -> 把应用指向新主库 -> 恢复写入。

16. 问：演练频率和关键检查点有哪些？

回答：建议至少每季度一次完整切换演练，月度小规模验证。关键检查点：DNS生效时间、数据同步延迟、健康检查触发正确性、应用登录/支付等关键业务路径验证、回滚耗时与数据完整性。每次演练后更新Runbook并记录问题与改进项。

来源：构建多机房冗余架构以减少香港机房出问题带来的风险