好未来的课程录制和回放服务需要7x24小时可用，请设计一个容灾方案，包括数据备份、多机房部署、故障切换等。
好未来基础平台难度：困难
答案
1) 【一句话结论】：采用“主备+实时数据同步”的多机房容灾架构，通过主备机房数据实时同步（如CDC），结合自动化故障检测与切换，确保7x24高可用，同时兼顾数据一致性与切换效率。
2) 【原理/概念讲解】：
老师口吻解释关键概念：
- 数据备份：分为全量备份（定期，如每日）和增量备份（实时，如日志级）。全量备份用于灾难恢复（如机房全毁），增量备份用于快速同步数据变更，减少恢复时间。
- 多机房部署：选择主备或主主架构。主备模式下，备机房数据滞后（RPO为分钟级），故障切换后可能丢失少量数据；主主模式下，双机房数据实时同步（RPO接近0），但需解决数据冲突。
- 故障切换：通过心跳检测（主备间定时发送心跳包）、服务健康检查（如API调用返回状态码）判断主机房是否故障，自动将流量切换到备机房，减少人工干预时间（RTO）。
类比：数据备份像“存保险箱”，全量备份是存整份家当，增量备份是存每天新增的物品，恢复时不用搬全家的东西，只补新增的；多机房像两个仓库，主仓库卖货，备仓库同步库存，主仓库断电时，备仓库能继续卖，保证不缺货。
3) 【对比与适用场景】：
| 模式/策略 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 全量备份 | 定期（如每日）完整备份数据 | 恢复时间长，数据完整 | 灾难恢复（机房全毁） | 需足够存储空间，恢复时数据滞后 |
| 增量备份 | 实时记录数据变更（如日志） | 恢复快，数据同步及时 | 日常数据同步，故障切换 | 需处理日志丢失或损坏 |
| 主备架构 | 主机房处理请求，备机房同步数据 | RPO较高（分钟级），切换后数据可能丢失 | 对数据一致性要求不高的场景（非核心业务） | 切换时需回滚未完成事务 |
| 主主架构 | 双机房均处理请求，数据实时同步 | RPO接近0，切换后无数据丢失 | 对数据一致性要求高的场景（核心业务） | 需解决数据冲突（分布式事务/最终一致性） |
4) 【示例】：
- 数据同步伪代码（CDC）：
# 主机房数据库（MySQL）的binlog订阅 def start_cdc(): with MySQLConnection(host='master', user='cdc_user', pwd='pwd') as conn: conn.start_binlog_subscription() for event in conn.get_binlog_events(): if event.type in ('UPDATE', 'INSERT'): sql = generate_sql(event) with MySQLConnection(host='standby', user='cdc_user', pwd='pwd') as standby_conn: standby_conn.execute(sql) # 故障切换流程（伪代码） def check_master_health(): try: response = requests.get('http://master:8080/health', timeout=2) return response.status_code == 200 except: return False def switch_to_standby(): if check_standby_health(): update_load_balancer('master', 'standby') update_service_status('standby')
5) 【面试口播版答案】：
“面试官您好，针对7x24可用性的容灾方案，我考虑采用‘主备+实时数据同步’的多机房架构。首先，数据备份方面，采用全量+增量策略：每日做一次全量备份（存储在异地备份中心），同时通过CDC（如MySQL的Binlog）实时同步增量数据，确保备机房数据与主机房一致。多机房部署上，选择主备模式，主机房（北京机房）处理日常请求，备机房（上海机房）同步数据，故障时自动切换。故障切换通过健康检查（如心跳包、服务状态）实现，当主机房不可用时，自动将流量切换到备机房，RTO控制在分钟级以内。另外，监控方面，部署实时监控（如Prometheus+Grafana），监控数据同步延迟、服务可用性，及时告警。这样既能保证数据一致性，又能快速恢复服务，满足7x24可用性要求。”
6) 【追问清单】：
- 问：RTO和RPO具体怎么定义？如何保证数据一致性？
回答要点：RTO（恢复时间目标）指故障后服务恢复时间，RPO（恢复点目标）指故障时数据丢失量。数据一致性通过CDC实时同步（最终一致性），主备切换时回滚未完成事务。 - 问：跨机房网络延迟高怎么办？比如数据同步延迟？
回答要点：优化网络链路（如专线），使用异步复制（降低延迟），或采用分片策略，减少单次同步的数据量。 - 问：如何处理数据冲突？比如主备切换后，备机房的数据与主机房不一致？
回答要点：主备模式下，切换后可能丢失少量数据，通过日志补全；主主模式下，使用分布式事务（如两阶段提交）或最终一致性（如版本号、时间戳）解决冲突。 - 问：备份策略中，全量备份的频率如何确定？比如每天一次是否足够？
回答要点：根据数据变化频率，若数据变化大，可增加全量备份频率（如每日），或采用增量+差异备份，减少存储压力。 - 问：监控和告警机制具体如何设计？如何快速定位故障？
回答要点：部署监控指标（如数据同步延迟、服务响应时间、心跳状态），设置告警阈值（如延迟超5分钟），通过邮件/短信告警，并集成日志分析（如ELK）快速定位问题。
7) 【常见坑/雷区】：
- 坑1：只强调数据备份，忽略实时同步，导致故障切换后数据不一致。
- 坑2：选择主主架构但未考虑数据冲突，导致切换后服务异常。
- 坑3：RTO/RPO目标设定过高（如RTO超分钟级），无法满足7x24要求。
- 坑4：忽略网络延迟对容灾的影响（如跨机房网络不稳定，导致数据同步失败）。
- 坑5：故障切换依赖人工干预，导致恢复时间过长，不符合7x24要求。