这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
数据同步
容灾系统最难的部分往往不是服务部署，而是数据同步。服务可以快速拉起，但如果备用机房没有最新数据，切过去也无法提供正确业务。
数据分类
不同数据同步策略不同：
| 数据类型 | 示例 | 同步要求 |
|---|---|---|
| 强业务数据 | 订单、支付、账户余额 | RPO 小，严格校验 |
| 可重建数据 | 搜索索引、推荐缓存 | 可异步重建 |
| 临时数据 | Session、验证码、限流计数 | 可丢弃或降级 |
| 文件数据 | 图片、合同、附件 | 对象存储跨区域复制 |
| 消息数据 | MQ 未消费消息 | 要处理重复和丢失 |
所有数据都按最高标准同步，成本会非常高。先分类，才能设计合理策略。
数据库同步
数据库常见同步方式：
- 主从复制：实现成熟，但跨地域延迟和复制中断要监控。
- 双向复制：支持多地写入，但冲突处理复杂。
- 逻辑日志同步：通过 binlog 或 CDC 把变更推到备用地域。
- 应用层双写：业务可控，但容易出现部分失败和一致性问题。
对核心交易系统，通常先采用单主写入 + 异地只读或热备，等业务具备分区能力后再考虑多活写入。
缓存同步
缓存不一定要强同步。很多缓存可以在切换后回源重建。真正需要关注的是：
- 缓存是否承载会话或关键状态。
- 缓存丢失后数据库是否能承受回源压力。
- 备用机房是否需要提前预热热点数据。
如果缓存不可用会导致雪崩，容灾预案里要包含限流、降级和预热。
消息同步
消息系统在容灾中容易出问题。切换时可能出现：
- 消息在主机房已写入但未同步。
- 备用机房重复消费。
- 消费进度不一致。
解决思路是让消费端具备幂等能力，并保存业务侧处理状态。容灾切换后，即使消息重复投递，也不能导致重复扣款、重复发货或重复通知。
同步监控
数据同步必须可观测：
- 主备延迟。
- 复制中断时间。
- 待同步日志量。
- 校验差异数量。
- 最近一次成功同步时间。
没有这些指标，团队无法判断是否能安全切换。下一章会讨论故障转移，数据同步状态会成为切换决策的重要依据。