针对游戏活动期间（如节日活动）的峰值流量，前端如何设计容错和降级机制？请举例说明。

1) 【一句话结论】游戏活动期间前端需通过熔断、降级、请求重试等组合机制，结合业务优先级（核心业务优先保障，非核心业务降级），在流量峰值时保障系统稳定性和用户体验。

2) 【原理/概念讲解】老师口吻解释核心概念：
容错是指系统出现故障时仍能继续提供服务（如服务器宕机，前端用本地缓存返回数据）；降级是主动减少功能或服务（如高并发时非核心API降级为静态数据，避免后端压力）。类比：交通高峰时，主干道限行（降级），故障车辆绕行（容错），共同保障整体流畅。

3) 【对比与适用场景】

机制	定义	特性	使用场景	注意点
熔断	后端服务频繁失败时，前端主动断开请求，避免雪崩	快速失败，保护系统	后端不稳定时	合理设置断路器状态（打开/半开/关闭）
降级	主动减少功能，如非核心API降级为静态数据	主动控制资源	高并发或后端压力过大时	明确降级策略，避免用户感知
限流	限制请求频率，防止流量过大	控制请求速率	预防系统过载	考虑公平性和突发流量

4) 【示例】（活动页面数据请求）
假设活动页面需加载“奖品列表”数据，当服务器压力过大时：

• 初始请求：正常调用后端/api/activity/prizes。
• 熔断触发：连续3次失败则断开请求，返回本地缓存或默认数据（如“加载中...”）。
• 降级处理：API响应超时（>2秒）则直接返回静态默认奖品列表。
• 重试机制：熔断后每隔5秒重试1次，最多3次。

伪代码：

async function fetchPrizes() {
  const url = '/api/activity/prizes';
  const maxRetries = 3;
  const retryDelay = 5000;

  for (let i = 0; i <= maxRetries; i++) {
    try {
      const res = await fetch(url);
      if (res.ok) return res.json();
    } catch (e) {
      if (i >= 2) { // 连续2次失败触发熔断
        return getLocalCache() || getDefaultData();
      }
    }
    if (i < maxRetries) await new Promise(r => setTimeout(r, retryDelay));
  }
  return getFallbackData();
}

5) 【面试口播版答案】（约90秒）
“面试官您好，针对游戏活动期间的峰值流量，前端容错和降级设计需结合业务优先级，通过熔断、降级、重试等机制保障稳定性。核心思路是：对核心业务（如活动奖品、用户排名）的请求，优先保障，采用熔断+重试；对非核心业务（如活动介绍、历史数据），主动降级为静态数据或缓存数据。比如活动页面，当后端API频繁失败时，前端会触发熔断，返回本地缓存，避免请求雪崩；若API响应超时，则直接显示默认数据，减少后端压力。具体来说，活动奖品列表的请求设置熔断器，连续3次失败就断开请求，返回最近一次成功的数据或默认列表，同时每隔5秒重试一次，直到成功或达到最大重试次数。这样既能应对高并发，又能保证用户体验，避免系统崩溃。总结来说，前端通过组合这些机制，结合业务逻辑，实现容错和降级，保障活动期间系统的稳定性和流畅性。”

6) 【追问清单】

• 问：熔断和降级的区别？
  答：熔断是后端故障时前端快速失败（避免雪崩），降级是主动减少功能（如非核心API降级为静态数据），两者结合应对高并发。
• 问：如何配置熔断的阈值？
  答：通常根据业务容忍度，如连续失败次数（3次）或失败率（50%），合理设置，避免误判。
• 问：降级后用户体验如何？
  答：降级为静态数据或缓存数据，用户仍能看到基本信息（如预加载的默认奖品列表），不会完全空白，不影响核心体验。
• 问：如何监控这些机制的效果？
  答：通过监控指标（如熔断触发次数、降级请求比例、重试成功率），及时调整策略。

7) 【常见坑/雷区】

• 混淆熔断和降级：若只做熔断不做降级，非核心请求仍压垮后端；若只做降级不做熔断，后端故障时前端请求仍雪崩。
• 忽略业务优先级：所有请求同等对待，导致核心业务被降级，影响用户参与度。
• 重试策略不合理：重试次数过多或间隔过短，导致请求堆积，加剧后端压力。
• 缺乏监控：无法及时发现问题（如熔断阈值设置过高，实际故障时系统仍崩溃）。