程序员如何做「容灾设计」：不是万一，是一定会发生
容灾是系统设计中最容易被忽视的部分。
很多人觉得"我的系统不会出问题"，但现实是：任何系统都会出问题。
一、容灾的目标
1. RTO（Recovery Time Objective）
系统中断到恢复的时间目标。
比如：RTO = 4 小时。
2. RPO（Recovery Point Objective）
能接受的数据丢失时间窗口。
比如：RPO = 1 小时。
3. 业务连续性
灾难发生时，业务不能完全停摆。
核心功能要能继续运行。
二、常见的灾难类型
1. 硬件故障
- 服务器硬盘损坏
- 网络设备故障
- 机房断电
2. 软件故障
- 代码 bug
- 配置错误
- 第三方服务不可用
3. 人为故障
- 误删数据
- 误操作
- 安全攻击
4. 自然灾害
- 地震、洪水
- 火灾
- 极端天气
三、容灾方案
1. 主备切换
- 主库故障 → 切换到备库
- 同城容灾（低延迟）
- 异地容灾（更高保障）
2. 多活架构
- 多个机房同时提供服务
- 任意一个机房挂了，其他继续服务
- 数据同步是关键挑战
3. 数据备份
- 全量备份 + 增量备份
- 定期演练恢复流程
- 验证备份可用
四、数据同步策略
1. 同步复制
- 主从实时同步
- 延迟低，一致性高
- 对网络要求高
2. 异步复制
- 主从延迟同步
- 性能好，可能丢数据
- 适合对一致性要求不高的场景
3. 半同步复制
- 折中方案
- 主库确认至少一个备库收到日志
五、容灾演练
1. 定期演练
- 每季度至少一次
- 模拟各种故障场景
- 验证恢复流程
2. 演练后复盘
- 发现了什么问题
- 流程是否需要改进
- RTO/RPO 是否达标
六、一句话总结
容灾设计 = RTO + RPO + 主备切换/多活/备份 + 数据同步 + 定期演练，核心是业务连续性。