交易系统需要高可用，请设计一个灾备方案，包括主备切换机制（如热备、冷备），并说明切换时间（RTO）和恢复时间（RPO）的要求。
上海证券交易所A04难度：中等
答案
1) 【一句话结论】交易系统灾备应采用“主备热备+多活架构”结合，通过数据库实时同步（如MySQL GTID复制）和消息队列双写，实现RTO接近0，RPO小于秒级，确保业务连续性。
2) 【原理/概念讲解】高可用（HA）指系统在故障时能快速恢复，灾备是应对灾难的备份。RTO（恢复时间目标）：从故障到系统可用的时间，目标为秒级；RPO（恢复点目标）：允许的数据丢失量，目标为秒级。热备：主备系统实时同步数据，切换快（秒级），成本高；冷备：定期备份，切换慢（小时级），成本低。类比：热备像双手机同时在线，冷备像备用手机，但冷备需要重新配置。
3) 【对比与适用场景】
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 热备 | 主备系统实时同步数据，故障时备系统立即接管 | 数据实时同步，切换时间短（秒级），系统持续运行 | 核心交易系统（如订单处理、行情系统） | 成本高，对网络和存储要求高 |
| 冷备 | 主系统定期备份，备系统不实时同步，故障时需重新配置 | 数据非实时同步，切换时间长（小时级），系统停机 | 非核心系统或数据不敏感系统 | 成本低，切换后需验证数据一致性 |
4) 【示例】
# 主备切换伪代码（Python）
def monitor_primary():
while True:
if is_primary_down():
trigger_switch_to_standby()
break
time.sleep(1)
def is_primary_down():
# 检测主节点心跳，如数据库连接、网络心跳
return not check_primary_connection()
def trigger_switch_to_standby():
# 备节点切换为主节点，更新配置，通知应用
switch_to_primary()
notify_applications()
# 数据库实时同步示例（MySQL GTID复制）
# 主库写操作：
INSERT INTO orders (id, amount) VALUES (1, 100);
# 备库自动同步：
# 备库执行：
INSERT INTO orders (id, amount) VALUES (1, 100);
5) 【面试口播版答案】
面试官您好，针对交易系统高可用灾备，核心方案是采用“主备热备+多活架构”结合，通过数据库实时同步（如MySQL GTID复制）和消息队列双写，实现RTO接近0，RPO小于1秒。具体来说，主节点持续将数据同步到备节点，当主节点故障（如网络中断、硬件故障），备节点通过心跳检测自动切换，切换时间小于3秒（RTO），数据丢失量小于1秒（RPO）。同时，结合多活部署，部分业务节点可同时处理请求，提升整体可用性。
6) 【追问清单】
- 问题1：如何保证数据一致性？
回答要点：通过数据库事务提交后，备库立即执行（如GTID复制），结合消息队列双写，确保数据最终一致。 - 问题2：热备切换的触发机制？
回答要点：主节点通过心跳检测（如ZooKeeper、Consul）监控备节点状态，当连续多次检测失败，触发自动切换。 - 问题3：多活架构下的负载均衡？
回答要点：使用负载均衡器（如Nginx、HAProxy），将请求分发到多活节点，避免单点过载，同时故障节点自动下线。 - 问题4：灾备数据中心的成本控制？
回答要点：采用云服务（如阿里云、腾讯云）的弹性资源，按需扩容，灾备中心仅部署冷备或热备的备用节点，降低闲置成本。 - 问题5：灾备演练的频率？
回答要点：每月进行一次故障模拟演练，验证切换流程和恢复时间，确保方案有效性。
7) 【常见坑/雷区】
- 坑1：混淆RTO和RPO的具体数值，仅说“快”或“慢”，未量化。
- 坑2：热备切换时间描述错误，如说冷备切换快，实际冷备慢。
- 坑3：忽略多活架构下的数据一致性问题，未说明如何同步多活节点的数据。
- 坑4：未考虑监控和告警机制，如故障时无法及时检测。
- 坑5：灾备方案未测试，仅理论设计，实际故障时无法执行。