关键决策
这一页整理容灾系统设计过程中遇到的关键决策点，每个决策都说明了问题、对比过的方案和最终选择理由。
决策 1：RTO/RPO 先于技术选型
问题
容灾方案如何选？直接上多活还是先做热备？
决策
RTO/RPO 先于技术选型。 不知道恢复目标，就无法判断方案是否足够。支付系统要求 RTO 5 分钟、RPO 30 秒，报表系统可以接受 RTO 2 小时、RPO 1 天。目标不同，投入不同。不要一开始就追求多活——很多系统先做到热备和可演练切换，收益已经很大。
决策 2：主备还是多活
问题
多机房架构选主备、同城双活还是异地多活？
方案对比
| 架构 | 抗地域故障 | 复杂度 | 数据一致性难度 |
|---|---|---|---|
| 主备 | 弱 | 低 | 低 |
| 同城双活 | 弱 | 中 | 中 |
| 异地多活 | 强 | 高 | 高 |
决策
取决于业务写入模型和成本承受能力。 主备简单可控，适合大多数业务；同城双活应对单机房故障；异地多活抗地域故障但复杂度最高，通常需要业务拆分，把能本地闭环的业务留在本地域，强一致核心能力集中或做特殊设计。
决策 3：同步还是异步复制
问题
数据库跨地域复制，选同步还是异步？
方案对比
- 同步复制：RPO 接近 0，但跨地域延迟高，可能降低可用性（故障时主库写不进去）。
- 异步复制：可用性好，但要接受数据丢失窗口（RPO 大于 0）。
决策
核心交易数据优先同步或中心化写入，其余异步复制 + 对账补偿。 支付流水强一致或中心化写入；订单状态主写 + 异步复制 + 对账；用户资料、日志最终一致。把强一致成本集中在真正关键的数据上。
决策 4：自动切换还是人工确认
问题
故障发生时，切换由系统自动执行还是人工操作？
决策
分层处理，人工做决策，不让人工手敲复杂命令。 单实例故障自动恢复，集群主备自动切换，机房级切换自动化执行但人工确认。自动切换响应快但误切风险高；人工切换更谨慎但可能拖长 RTO。关键是让切换动作可一键执行，让决策由人确认。
决策 5：切换后是否全功能可用
问题
切到备用机房后，是否维持所有功能？
决策
容灾优先保核心链路，非核心功能降级。 备用机房可能容量不足，切换时暂停非核心功能、限制低优先级流量、关闭报表批处理、对强一致能力收紧写入。容灾目标是保住登录、下单、支付、查询这些核心链路，而不是在事故时维持所有功能。
决策 6：缓存是否强同步
问题
缓存数据在容灾切换时如何处理？
决策
缓存不一定要强同步，很多可以回源重建。 但要检查缓存是否承载会话或关键状态、缓存丢失后数据库能否承受回源压力、备用机房是否需要提前预热热点数据。如果缓存不可用会导致雪崩，容灾预案里要包含限流、降级和预热。
决策 7：消息在切换时的处理
问题
消息队列跨机房切换时，如何避免丢失和重复？
决策
让消费端具备幂等能力，并保存业务侧处理状态。 切换时可能出现消息在主机房已写入但未同步、备用机房重复消费、消费进度不一致。即使消息重复投递，也不能导致重复扣款、重复发货或重复通知。消息补偿能力决定了系统能否从不一致中恢复。
决策 8：演练层级与频率
问题
容灾演练怎么安排，多久一次？
决策
分层推进，按业务重要性确定频率。 桌面推演 → 组件演练 → 局部演练 → 全链路演练，不要第一次就做全链路。核心交易链路季度或月度演练，重要支撑系统半年演练，普通系统重大架构变更后演练。容灾能力会随系统变化退化，只有持续演练，预案才不会变成过期文档。