推荐系统在高峰期（如直播带货）如何保证服务可用性？请说明容灾策略、降级方案及监控告警设计。

1) 【一句话结论】
高峰期通过多活容灾（跨区域多活+热备实时同步）、动态核心功能优先降级、多维度指标智能监控+分级告警，确保服务在流量激增或故障时秒级切换，核心业务（如直播推荐）资源优先保障，快速恢复可用性。

2) 【原理/概念讲解】
（老师讲解）高峰期服务可用性保障主要依赖容灾、降级、监控告警三方面。

• 容灾：应对故障（如服务器宕机、网络分区），需备用系统接管。
  • 多活：多个数据中心（如北京、上海）同时提供服务，用户请求按负载均衡分配，故障时自动切换（如一个数据中心故障，另一个继续服务，用户几乎无感知）。
  • 热备：备用系统通过CDC（变更数据捕获）或日志同步实时同步生产数据（如推荐模型参数、用户行为数据），故障时秒级切换（如主模型宕机，热备模型立即接管）；
  • 冷备：定期备份（如每日），故障时恢复，时间较长（分钟级），适合次要服务。
• 降级：资源紧张时保障核心业务，比如核心推荐功能（直播商品列表）必须保留，次要的个性化推荐（用户历史行为推荐）可暂时关闭，或限制资源（如CPU使用率不超过50%）。
• 监控：实时了解系统状态，用QPS（每秒请求数）、延迟（请求处理时间）、错误率（失败请求比例）等指标，通过链路追踪定位问题。
• 告警：设置阈值（如延迟超过200ms、错误率超过5%），触发后自动切换热备或通知运维，快速恢复服务。
  （类比：容灾像多根水管，一根坏时其他继续供水；降级像暴雨时先保主要道路（核心业务）；监控像体温计，告警像警报器，温度过高时提醒。）

3) 【对比与适用场景】

策略类型	定义	特性	使用场景	注意点	成本分析
多活（区域冗余）	多个数据中心同时提供服务，用户请求负载均衡	高可用，故障自动切换，用户无感知	直播带货等高并发、跨地域场景	跨区域网络延迟低，数据同步成本高	需高带宽跨区域同步，运维复杂
热备（实时同步）	备用系统实时同步生产数据（如模型、数据），故障秒级切换	恢复时间短（秒级），成本高，需高带宽	核心服务（推荐模型、直播推荐）	数据一致性要求高，需保证热备与主系统数据同步	高带宽、高存储成本，实时同步压力大
冷备（定期备份）	备用系统定期备份（如每日），故障时恢复	恢复时间长（分钟级），成本低	次要服务或非核心功能	恢复时间要求不高的场景	低带宽、低存储成本，但恢复时间长
功能降级	关闭次要功能，保留核心功能	保障核心业务，资源优先分配	高峰期资源紧张时	可能影响用户体验，需测试接受度	资源释放，但可能降低次要功能价值
资源降级	限制次要服务资源（如CPU/内存），降低服务能力	临时缓解资源压力	突发流量激增时	可能导致性能下降，需监控资源使用	资源分配调整，可能影响次要服务性能

4) 【示例】
伪代码示例（请求处理流程）：

def process_user_request(user_id, request_type):
    # 1. 选择可用区域（多活）
    region = load_balancer.select_region()
    if is_region_healthy(region):
        # 正常处理
        response = region_service.process(user_id, request_type)
        return response
    else:
        # 2. 切换到热备区域
        hot_standby = get_hot_standby_region()
        if is_hot_standby_healthy(hot_standby):
            response = hot_standby_service.process(user_id, request_type)
            return response
        else:
            # 3. 热备故障，降级处理
            # 根据业务优先级表判断核心功能（如直播推荐是核心，个性化次要）
            if is_core_function(request_type, priority_table):
                # 核心功能降级：限制资源或简化逻辑
                response = downgrade_core(user_id, request_type, priority_table)
            else:
                # 次要功能直接失败
                return "service_unavailable"

5) 【面试口播版答案】
“高峰期保证服务可用性，核心是通过多活容灾、动态降级和智能监控。首先，容灾策略上，采用多活（跨区域冗余）和热备（实时同步的备用模型），比如直播带货时，北京和上海数据中心同时服务，主模型故障热备秒级接管，避免服务中断。其次，降级方案，优先保障核心推荐功能（如直播商品列表），暂时关闭次要个性化特征，资源上限制次要服务CPU使用率不超过50%，释放资源给核心。然后，监控告警，监控QPS、延迟、错误率等指标，阈值设为延迟超200ms或错误率超5%，通过链路追踪定位问题，告警后自动切换热备或通知运维，快速恢复。这样即使流量激增或故障，核心业务也能保持可用。”

6) 【追问清单】

1. 多活和热备的区别？
   • 答：多活是多个区域同时服务，故障自动切换；热备是备用系统实时同步数据，故障秒级切换，热备更适用于核心服务，多活用于跨区域高可用。
2. 核心功能判断依据？
   • 答：根据业务优先级表，比如直播推荐是核心（用户转化率最高），个性化次要（次要特征影响转化率低），可通过A/B测试或业务指标（如转化率）判断。
3. 监控阈值如何设定？
   • 答：基于历史数据（如QPS峰值、延迟正常范围）和业务容忍度，比如延迟超过200ms或错误率超过5%时触发告警。
4. 热备故障时怎么办？
   • 答：切换到冷备（恢复时间较长，如分钟级），或人工干预，恢复后同步数据。
5. 数据一致性如何保证？
   • 答：通过CDC（变更数据捕获）或日志同步机制，确保热备与主系统数据实时一致，切换时无数据丢失。

7) 【常见坑/雷区】

1. 忽略热备数据同步的延迟（如CDC延迟导致切换后数据不一致），导致服务异常。
2. 降级方案不具体，只说关闭功能，未说明如何选择核心功能（如未结合业务指标）。
3. 监控告警只说指标，未说明告警规则（如阈值设定）和响应流程（如自动切换或人工干预）。
4. 忽略用户感知，降级后用户体验差（如核心功能降级导致推荐列表加载慢）。
5. 表述绝对化，如“秒级切换”未说明实际受网络延迟、数据同步等因素影响。