设计一个高校在线课程系统的容灾方案，特别是针对课程录播和直播的稳定性，如何保证在服务器故障时数据不丢失且服务快速恢复？请说明具体的架构设计。

1) 【一句话结论】采用“多活+热备份+实时同步”的混合架构，通过负载均衡分发请求、主从服务器实时同步数据、心跳检测自动切换，确保课程录播和直播在服务器故障时数据不丢失且服务快速恢复（故障切换时间<30秒，数据同步延迟<1秒）。

2) 【原理/概念讲解】老师口吻，解释容灾核心逻辑：
高可用（HA）的本质是“故障检测+快速切换”，把服务器比作“备用发电机”——正常时主发电机工作，备用发电机待命；当主发电机故障（服务器宕机），备用发电机立即启动，用户几乎感觉不到断电。具体需解决三方面：

• 数据持久化：通过分布式存储（如Ceph、GlusterFS）实现，确保数据不丢失；
• 服务可用性：通过负载均衡（如Nginx、HAProxy）和主从复制（如MySQL主从同步）实现，避免单点故障；
• 故障检测：通过心跳检测（如Keepalived）实时监控服务器状态，及时响应故障。

3) 【对比与适用场景】
以“冷备份”与“热备份”为例：

方式	定义	特性	使用场景	注意点
冷备份	定期全量备份（如每日）	备份数据与主数据有延迟，恢复时需完整恢复	非核心数据（如历史课程录播）	恢复时间长，故障时数据可能丢失
热备份	实时同步（如数据库主从同步）	数据与主数据实时一致，故障时立即切换	核心数据（如直播、实时互动）	需额外带宽，成本较高

4) 【示例】伪代码（故障检测与切换流程）：

// 故障检测服务（心跳检测）
function check_server_health(server_id):
    try:
        response = http_get(f"http://{server_id}:8080/health")
        if response.status_code == 200:
            return True
        else:
            return False
    except:
        return False

// 故障切换逻辑
function handle_failure():
    current_server = get_current_active_server()
    if not check_server_health(current_server):
        standby_server = find_standby_server()
        if standby_server:
            update_load_balancer_target(standby_server)
            notify_app_switch(standby_server)
            log("Server failure detected, switching to standby server")
        else:
            log("No standby server available, service degraded")

5) 【面试口播版答案】
各位面试官好，针对高校在线课程系统的容灾方案，核心思路是构建“多活+热备份”的混合架构，确保课程录播和直播的稳定性。具体来说：

• 通过负载均衡（如Nginx）分发请求到多台服务器，避免单点故障；
• 采用数据库主从复制（如MySQL主从）和分布式存储（如Ceph），实现数据实时同步，保证数据不丢失；
• 部署心跳检测（如Keepalived）监控服务器状态，当主服务器故障时，自动切换到备用服务器，故障切换时间通常控制在30秒以内。
  对于直播，额外增加流媒体服务器集群，通过RTMP协议的负载均衡和备份服务器，确保直播流不中断；对于录播，采用对象存储（如阿里云OSS）的版本控制，定期备份，同时本地服务器与对象存储同步，确保即使服务器故障，录播视频也能从备份中恢复。整个方案通过监控、自动切换、数据同步，实现了服务器故障时数据不丢失且服务快速恢复的目标。

6) 【追问清单】

• 问：故障检测的延迟是多少？如何保证切换的快速性？
  回答要点：通过心跳检测（每秒检测一次），故障检测延迟<1秒，切换时间（从检测到切换完成）通常<30秒，因为负载均衡和主从切换都是预配置的。
• 问：如何保证数据同步的实时性？比如直播数据同步延迟？
  回答要点：采用数据库主从同步（如MySQL的异步复制，延迟<1秒）和流媒体服务器实时推送（如RTMP的推送延迟<0.5秒），确保数据同步延迟低，满足直播的实时性要求。
• 问：容灾方案的成本如何？是否适合高校预算？
  回答要点：采用开源软件（如Keepalived、Nginx、Ceph）降低成本，同时通过云服务（如阿里云的弹性伸缩）按需付费，避免固定成本过高，适合高校的预算控制。
• 问：如果多个服务器同时故障，如何处理？
  回答要点：通过冗余服务器（如3台主服务器+2台备用服务器），采用故障检测的优先级排序，先检测主服务器，再检测备用服务器，确保至少有一台可用服务器提供服务。
• 问：如何处理数据一致性问题？比如主从同步中的数据不一致？
  回答要点：采用最终一致性模型（如BASE理论），允许短暂的数据不一致，通过补偿机制（如定时同步）保证数据最终一致；对于关键数据（如用户登录状态），采用分布式事务（如两阶段提交）保证强一致性。

7) 【常见坑/雷区】

• 坑1：只强调数据备份，忽略恢复速度。比如只说定期备份，但未说明故障时恢复时间过长，导致服务中断时间过长。
• 坑2：架构过于复杂，导致维护成本高。比如使用过多分布式组件，导致系统难以维护。
• 坑3：忽略直播的实时性要求。比如只考虑录播的备份，未考虑直播的流媒体传输的容灾。
• 坑4：数据同步延迟过高。比如主从同步延迟超过秒级，导致直播数据丢失。
• 坑5：未考虑多活架构的一致性问题。比如多活架构中数据不一致，导致用户看到不同数据。