设计一个课程直播系统的容灾方案，当主服务器故障时，如何快速切换到备用服务器，同时保证数据不丢失？
答案
1) 【一句话结论】采用主备热备架构，通过心跳检测+数据同步机制，确保主服务器故障时秒级切换至备用服务器，并利用“异步复制+同步验证”保证数据一致性。
2) 【原理/概念讲解】老师口吻：同学们，课程直播系统的容灾核心是“主备热备+数据同步”。主服务器负责正常处理直播请求（如推流、播放），备用服务器处于待命状态，通过心跳协议（如每5秒发送一次HTTP请求检测主服务器存活）实时监控主服务器状态。当备用服务器检测到主服务器超时（连续3次心跳失败），则触发切换流程。数据同步方面，采用“异步复制+同步验证”：主服务器将数据变更异步写入备用服务器（保证高可用性，避免主服务器故障时同步延迟导致服务中断），同时通过“写后读验证”（写完数据后从备用服务器读取验证一致性）确保数据不丢失。类比：就像双机热备系统，主服务器是主要工作机，备用服务器随时待命，一旦主服务器宕机，备用服务器能立刻接管，就像手机双卡切换，主卡没信号时自动切换到副卡，通话记录不会丢失。
3) 【对比与适用场景】
| 方案类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 主备模式（Active-Standby） | 一台主服务器处理请求，另一台备用服务器不处理，仅同步数据 | 主服务器故障时，备用服务器秒级接管，无业务中断；数据同步延迟低（异步复制） | 对实时性要求高、单点故障风险大的场景（如课程直播，若主服务器故障导致直播中断影响用户体验） | 备用服务器需保持低负载，避免切换时资源不足；需考虑数据一致性验证 |
| 主主模式（Active-Active） | 两台服务器同时处理请求，通过负载均衡分配流量 | 两台服务器负载均衡，故障时需重新分配流量，切换时间较长（秒级到分钟级） | 对并发量高、需要高可用但允许短暂中断的场景 | 需要复杂的负载均衡和会话同步，数据一致性维护复杂 |
4) 【示例】
伪代码展示心跳检测和切换流程：
// 心跳检测逻辑（备用服务器）
function monitorMaster():
while True:
try:
response = http_get("http://master-server/heartbeat")
if response.status == 200:
print("主服务器存活")
sleep(5) // 每5秒检测一次
else:
print("主服务器未响应，开始故障切换")
triggerFailover()
except Exception as e:
print("心跳检测异常:", e)
triggerFailover()
// 故障切换逻辑
function triggerFailover():
// 1. 验证数据一致性（写后读验证）
if verifyDataConsistency():
// 2. 切换负载均衡器（如Nginx）将流量从主服务器切换到备用服务器
updateLoadBalancer("master", "backup")
print("切换成功，备用服务器接管")
else:
print("数据不一致，等待主服务器恢复")
// 数据一致性验证（示例）
function verifyDataConsistency():
// 从备用服务器读取关键数据（如直播状态、用户会话）
data_from_backup = http_get("http://backup-server/data")
data_from_master = http_get("http://master-server/data")
return data_from_backup == data_from_master
5) 【面试口播版答案】
“面试官您好，针对课程直播系统的容灾方案，核心思路是采用主备热备架构，通过心跳检测+数据同步确保故障切换时数据不丢失。具体来说，主服务器负责正常处理直播请求，备用服务器通过心跳协议（比如每5秒发送一次HTTP请求检测主服务器存活），一旦检测到主服务器超时（比如连续3次未响应），就会触发切换流程。数据同步方面，我们采用异步复制+同步验证机制：主服务器将数据变更异步写入备用服务器（保证高可用性），同时通过‘写后读验证’（写完数据后从备用服务器读取验证一致性）确保数据一致性。故障切换时，备用服务器会接管负载均衡器的流量，实现秒级恢复。这样既能保证数据不丢失，又能快速恢复服务。”
6) 【追问清单】
- 问题1：数据同步的延迟是多少？如何保证数据一致性？
回答要点：采用异步复制+同步验证，异步复制延迟低（毫秒级），同步验证通过“写后读”确保数据一致性。 - 问题2：切换时间能控制在多少秒以内？如何检测主服务器故障？
回答要点：通过心跳检测（3次超时触发），切换时间控制在1-3秒内（取决于负载均衡器配置和服务器性能）。 - 问题3：备用服务器如何处理并发请求？是否需要负载均衡？
回答要点：备用服务器作为热备，切换前需保持低负载，切换后通过负载均衡器（如Nginx）分配流量，确保并发处理能力。 - 问题4：如果主服务器恢复后，如何回切？
回答要点：设置主备切换的“健康检查”机制，当主服务器恢复后，通过心跳检测确认，自动回切到主服务器，避免双机同时运行导致数据冲突。 - 问题5：对于直播系统的实时性要求，如何平衡数据同步和切换速度？
回答要点：采用“异步复制+同步验证”策略，异步复制保证切换速度，同步验证保证数据一致性，同时优化心跳检测频率（5秒一次）和故障检测阈值（3次超时），确保实时性。
7) 【常见坑/雷区】
- 坑1：只关注切换速度而忽略数据同步，导致数据丢失。
雷区：未考虑数据一致性验证，比如只做异步复制不验证，主服务器故障时数据不一致。 - 坑2：未明确故障检测机制，导致切换延迟。
雷区：心跳检测频率过低（如10秒一次）或阈值设置不合理（如5次超时），导致故障检测延迟。 - 坑3：未考虑负载均衡器的配置，导致切换后备用服务器负载过高。
雷区：切换时未更新负载均衡器配置，导致流量未正确分配，备用服务器资源不足。 - 坑4：未考虑主服务器恢复后的回切机制，导致双机运行。
雷区：主服务器恢复后未自动回切，导致数据冲突或资源浪费。 - 坑5：未区分同步复制和异步复制的适用场景，导致选择错误。
雷区：对于实时性要求高的场景（如直播），若采用同步复制，会导致主服务器写延迟高，影响用户体验。