设计交易系统的灾备方案，需设定RPO（数据丢失量）和RTO（恢复时间）目标，并说明灾备系统的架构与切换流程。
上海证券交易所A02难度：困难
答案
1) 【一句话结论】交易系统灾备需根据业务风险设定合理RPO（如秒级数据丢失）和RTO（如分钟级恢复），采用多活热备架构（如两地三中心），通过实时数据同步（如binlog复制）实现数据一致性，结合自动化切换流程（如心跳检测+故障转移），确保系统在灾难发生时快速恢复业务。
2) 【原理/概念讲解】
首先解释关键概念：
- RPO（Recovery Point Objective）：允许的最大数据丢失量，以时间衡量。比如“RPO=1秒”表示允许最多1秒内的数据丢失。类比：就像“允许的迟到时间”，越短表示对数据一致性要求越高。
- RTO（Recovery Time Objective）：系统从故障到恢复运行的时间。比如“RTO=30分钟”表示故障后30分钟内系统可恢复。类比：从“迟到”到“到现场”的总时间，越短表示恢复能力越强。
灾备架构分为三类：
- 热备：主备系统实时同步数据，主故障时自动切换（如交易所交易系统需高可用，采用此模式）。
- 冷备：主备数据定期同步（如每日备份），切换时需恢复数据（适用于业务允许中断的场景）。
- 温备：介于热备与冷备之间（如每小时同步数据，切换时需少量恢复）。
数据同步方式：
- 实时同步（如数据库binlog复制、CDC）：数据实时写入灾备中心，RPO低（秒级），但需保证网络与系统稳定性。
- 异步复制（如Kafka、消息队列）：延迟低但可能存在数据丢失，适用于对数据丢失容忍度高的场景。
3) 【对比与适用场景】
| 架构类型 | 定义 | 数据同步方式 | RPO | RTO | 适用场景 |
|---|---|---|---|---|---|
| 热备 | 主备实时同步，故障自动切换 | 实时同步（binlog/CDC） | 低（秒级） | 低（分钟级，切换后秒级恢复） | 对数据一致性要求极高，业务不可中断（如交易所交易系统） |
| 冷备 | 主备数据定期同步，切换需恢复数据 | 定期备份（增量/全量） | 高（小时级/天级） | 高（小时级/天级，切换后需恢复数据） | 业务允许短时间中断，数据丢失可接受（如非核心系统） |
| 温备 | 主备数据定期同步，切换需少量恢复 | 增量备份（每小时） | 中（分钟级） | 中（小时级，切换后需恢复少量数据） | 介于热备与冷备之间，部分业务允许中断（如部分交易系统） |
4) 【示例】
假设采用“上海主中心-北京灾备中心”的热备架构，数据同步通过数据库binlog实时复制。
- 数据同步伪代码（实时binlog复制）：
def start_binlog_replication(): while True: binlog = get_latest_binlog_from_master() # 获取主库最新binlog apply_binlog_to_slave() # 应用到灾备库 time.sleep(1) # 模拟实时同步 - 故障切换流程（自动化）：
def monitor_system_health(): while True: if is_master_down(): # 检测主库故障 trigger_failover() # 触发故障转移 break time.sleep(5) # 心跳检测间隔
5) 【面试口播版答案】
面试官您好，关于交易系统的灾备方案，核心思路是根据业务风险设定RPO和RTO。首先，RPO（数据丢失量）我们设定为秒级，比如允许最多1秒内的数据丢失，因为交易数据每秒产生，若允许1秒丢失，业务影响可接受；RTO（恢复时间）设定为分钟级，比如30分钟内恢复系统运行。架构上采用两地三中心的热备模式，主中心（上海）与灾备中心（北京）通过数据库binlog实时同步数据，确保数据一致性。切换流程是自动化检测：通过心跳检测主中心状态，一旦检测到故障，自动触发故障转移，将流量切换到灾备中心，整个过程由自动化脚本控制，减少人工干预，保证切换效率。这样既能保证数据不丢失，又能快速恢复业务，满足交易所对系统高可用性的要求。
6) 【追问清单】
- 问：RPO和RTO的具体数值是如何确定的？
回答要点：根据业务数据更新频率和容忍的数据丢失程度，比如交易数据秒级更新，若允许1秒丢失，业务影响可接受；RTO根据系统恢复能力，比如灾备中心有完整系统，切换后30分钟内可恢复，符合业务连续性要求。 - 问：如何保证数据在同步过程中的一致性？
回答要点：采用实时binlog复制，确保数据实时写入灾备中心；同时设置数据校验机制，定期比对主备数据一致性，避免延迟或丢失。 - 问：如果切换失败，如何回滚？
回答要点：设置回滚机制，切换失败后自动回滚到主中心，并通知运维团队排查故障，启动人工干预流程，确保系统安全。 - 问：灾备系统的成本如何控制？
回答要点：采用共享资源架构（如灾备中心硬件与主中心部分共享），软件用开源方案（如MySQL、Kafka），运维通过自动化工具减少人工成本，定期演练降低实际故障成本。
7) 【常见坑/雷区】
- RPO/RTO设定不合理：比如RPO设为小时级，但交易数据秒级更新，导致数据丢失严重。
- 架构选择错误：采用冷备模式，但业务要求实时交易，切换时需恢复数据，导致RTO过高。
- 数据同步延迟：异步复制导致数据延迟超过RPO，比如延迟1分钟，RPO设为1秒，不满足要求。
- 切换流程复杂：依赖人工干预，导致RTO超过设定值（如切换需要人工确认）。
- 未考虑业务连续性测试：灾备方案未定期演练，实际故障时流程不顺畅。