机场核心系统（如航班调度）需要7×24小时不间断运行，请设计一个容灾备份方案，说明故障切换流程和恢复时间目标（RTO/RPO）。
中国航空集团运行维护岗位难度：中等
答案
1) 【一句话结论】
针对机场航班调度系统7×24不间断运行需求，采用异地多活热备份架构，通过实时数据同步与快速故障切换，实现RTO（恢复时间目标）≤5分钟、RPO（恢复点目标）≤1分钟，确保系统故障时业务无缝切换。
2) 【原理/概念讲解】
容灾备份的核心是“故障检测+快速切换+数据同步”，需明确两类关键架构：
- 热备份（Active-Active）：主备数据中心同时处理业务，数据实时同步（如数据库GTID、消息队列Kafka同步），故障时无业务中断，但架构复杂。
- 冷备份（Active-Standby）：主数据中心故障时，备用数据中心启动，数据同步延迟（如定时备份），切换时间较长。
类比：机场的“备用跑道”，主跑道故障时立即切换，确保航班不停航。
3) 【对比与适用场景】
| 架构类型 | 定义 | 数据同步 | 故障切换时间 | RTO/RPO | 适用场景 |
|---|---|---|---|---|---|
| 热备份 | 双活数据中心，同时处理业务 | 实时同步（数据库GTID、消息队列同步） | <1分钟（切换+同步） | RTO≤5min，RPO≤1min | 高可用场景（如航空核心系统） |
| 冷备份 | 主备数据中心，主故障时备用启动 | 定时/异步同步（如数据库备份、文件同步） | 5-30分钟（启动+同步） | RTO≥30min，RPO≥分钟级 | 预算有限、非实时性要求高的场景 |
4) 【示例】
假设航班调度系统为微服务架构，主数据中心（DC1）与备用数据中心（DC2），数据库用MySQL（GTID实时同步），应用服务部署双活。
故障切换流程伪代码：
def check_health():
# 检测DC1心跳（如数据库连接、网络延迟）
if is_unhealthy():
trigger_switch()
def trigger_switch():
# 更新负载均衡器指向DC2
update_lb("DC2")
# 通知应用服务切换
notify_app("switch_to_DC2")
数据同步示例（MySQL GTID）：
主DC1的写操作通过GTID同步到DC2，确保数据一致性。
5) 【面试口播版答案】
面试官您好，针对机场航班调度系统7×24不间断运行的需求，我设计的容灾方案核心是采用异地多活的热备份架构，通过实时数据同步和快速故障切换，确保RTO（恢复时间目标）低于5分钟，RPO（恢复点目标）低于1分钟。具体来说，方案分为三部分：
- 数据层：主备数据中心部署高可用数据库（如MySQL GTID同步），实时同步业务数据；
- 应用层：双活应用服务器，主备数据中心同时处理请求，通过负载均衡器分发流量；
- 故障切换：通过心跳检测机制，当主数据中心出现故障（如网络中断、数据库宕机），自动切换到备用数据中心，切换时间控制在30秒内。这样既能保证系统不间断运行，又能快速恢复业务。
6) 【追问清单】
- 问题：如果主备数据中心的网络延迟较高，如何保证数据同步的RPO？
回答：采用异步复制加补偿机制，如数据库半同步复制，结合消息队列的确认机制，确保数据延迟在秒级内。 - 问题：容灾方案中，如何处理数据一致性问题？
回答：通过两阶段提交或分布式事务，结合最终一致性模型，在故障切换后进行数据校验和补偿。 - 问题：如果备用数据中心负载过高，如何保证主数据中心故障后能快速接管？
回答：采用资源预留和弹性扩容，如备用数据中心预留20%容量，故障时自动扩容。 - 问题：容灾方案的成本如何？
回答：热备份成本较高，但通过云服务（如阿里云多可用区）降低成本，适合高可用场景。 - 问题：如果系统有实时性要求高的业务（如航班实时调度），如何保证切换后的性能？
回答：通过预加载和缓存，如切换前预加载关键数据到备用服务器，切换后立即使用缓存数据，减少延迟。
7) 【常见坑/雷区】
- 只说冷备份，忽略热备份的实时性，导致RTO/RPO过高；
- 故障切换流程不具体，如只说“切换”，未说明检测机制和步骤；
- 忽略数据一致性，如切换后数据不一致导致业务错误；
- 未考虑网络延迟对容灾的影响，如异地数据同步延迟导致RPO不达标；
- 成本和实际场景脱节，如说热备份但预算不足，无法落地。