多活与容灾架构
容灾架构等级
| 方案 | RPO | RTO | 成本 | 适用 |
|---|---|---|---|---|
| 冷备 | 小时级 | 小时级 | 低 | 非核心业务 |
| 温备（主从） | 分钟级 | 分钟级 | 中 | 一般业务 |
| 同城双活 | 秒级 | 秒级 | 高 | 核心业务 |
| 两地三中心 | 接近 0 | 分钟级 | 很高 | 金融/支付 |
RPO 与 RTO
- RPO（恢复点目标）：能承受丢失多少数据
- RTO（恢复时间目标）：从故障到恢复服务的时间
同城双活关键设计
| 组件 | 方案 |
|---|---|
| 流量 | DNS 轮询 / GSLB / 云 LB 多可用区 |
| 应用 | 无状态设计，双机房部署 |
| 数据库 | MySQL Group Replication / PG 同步复制 |
| 缓存 | Redis Cluster 跨 AZ |
| 消息队列 | Kafka MirrorMaker / 多 AZ 部署 |
常见面试问题
Q1: 同城双活最大的挑战是什么？
答案：
数据一致性。两个机房同时写同一份数据时如何保证一致：
- 数据分片：按用户/业务维度分片到不同机房，每个数据只在一个机房写
- 强一致同步：数据库同步复制（牺牲写延迟换一致性）
- 最终一致：允许短暂不一致，通过对账/补偿机制修复
实践中最常用方案 1（分片路由），避免跨机房写冲突。