在高并发场景下（如线上活动），如何保证系统可用性？请描述技术方案（如限流、熔断、降级）。

1) 【一句话结论】在高并发场景下，系统可用性通过“限流（控制请求速率）、熔断（隔离故障服务）、降级（资源优先级调整）”的组合策略实现，核心是动态调整策略参数，预防雪崩效应，保障核心业务稳定。

2) 【原理/概念讲解】
老师口吻解释：

• 限流：控制请求进入系统的速率，常用令牌桶算法。令牌桶是一个固定大小的桶，以固定速率生成令牌，请求需获取令牌才能通过。类比：水龙头控制水流，先放满水（桶满）再按速率流出，允许突发但有限流量。
• 熔断：当服务调用失败率超过阈值时，直接返回失败或占位符，避免级联故障。实现时用计数器记录失败次数，当失败率超过阈值（如50%）且调用次数超过阈值（如10次），进入熔断状态。类比：保险丝，过载时断开，保护电路。
• 降级：关闭非核心功能，优先保障核心服务。比如当数据库响应慢时，不查询用户历史数据，直接返回当前交易结果。类比：医院急诊，优先处理重症患者，暂时不处理普通门诊。

3) 【对比与适用场景】

技术方案	定义	特性	使用场景	注意点
限流	控制请求进入系统的速率，防止服务器过载	限制流量速率，允许突发但有限	高并发场景（如秒杀、活动），保护后端服务	阈值需动态调整（如根据系统负载），避免正常流量被拒绝
熔断	当服务调用失败率超过阈值时，直接返回失败或占位符	隔离故障，避免级联故障	依赖的服务（如第三方接口、数据库）故障时	阈值和恢复时间需动态调整，避免误触发
降级	关闭非核心功能，优先保障核心服务	资源优先级调整，牺牲部分功能	系统资源不足（如CPU、内存）时	需明确核心业务，避免降级影响关键流程

4) 【示例】（线上秒杀活动）

• 限流：令牌桶伪代码（控制每秒请求数）：

  class TokenBucket:
      def __init__(self, capacity, rate):
          self.capacity = capacity  # 桶容量
          self.rate = rate          # 每秒生成令牌数
          self.tokens = capacity
          self.last_update = time.time()
      
      def consume(self, n=1):
          now = time.time()
          elapsed = now - self.last_update
          self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
          self.last_update = now
          if self.tokens >= n:
              self.tokens -= n
              return True
          return False
  

  秒杀接口中调用 token_bucket.consume()，若返回 False 则拒绝请求。

• 熔断：计数器逻辑（库存服务调用）：

  class CircuitBreaker:
      def __init__(self, success_threshold, failure_threshold, call_count, reset_timeout):
          self.success_threshold = success_threshold  # 成功率阈值（如50%）
          self.failure_threshold = failure_threshold  # 失败率阈值（如50%）
          self.call_count = call_count
          self.reset_timeout = reset_timeout
          self.state = 'CLOSED'  # CLOSED, OPEN, HALF_OPEN
          self.success_count = 0
          self.failure_count = 0
      
      def record_success(self):
          self.success_count += 1
          if self.state == 'OPEN':
              self.transition_to_half_open()
      
      def record_failure(self):
          self.failure_count += 1
          if self.state == 'HALF_OPEN':
              if self.failure_count >= self.failure_threshold:
                  self.state = 'OPEN'
                  self.reset()
              else:
                  self.success_count += 1
      
      def transition_to_half_open(self):
          self.state = 'HALF_OPEN'
          self.reset()
      
      def reset(self):
          self.call_count = 0
          self.success_count = 0
          self.failure_count = 0
  

  秒杀时调用库存服务，若熔断器状态为 OPEN，直接返回失败；若为 HALF_OPEN，尝试调用一次，根据结果调整状态。

• 降级：代码示例（不查询库存，直接返回有货）：

  def process_order(order):
      # 核心业务：下单
      if is_core_service():  # 核心业务标识
          # 处理核心逻辑（如扣库存、生成订单）
          return "order processed"
      else:
          # 降级：关闭非核心功能（如不查询用户历史消费记录）
          return "order processed (non-core features disabled)"
  

5) 【面试口播版答案】
在高并发场景下，保证系统可用性的核心是采用“限流、熔断、降级”组合策略。限流通过令牌桶算法动态控制请求速率，比如秒杀时限制每秒1000个请求，防止服务器过载；熔断机制当库存服务调用失败率超过阈值（如50%）时，直接返回失败，避免级联故障；降级则是当库存系统响应慢时，暂时不查询库存，直接返回“库存充足”，保障交易流程。三者结合，通过动态调整策略参数，从流量控制、故障隔离到资源优先级保障，有效应对高并发下的可用性问题。

6) 【追问清单】

• 问：限流算法中令牌桶的速率如何动态调整？比如根据系统负载（CPU使用率）？
  回答要点：根据系统负载（如CPU使用率超过80%），降低令牌生成速率，减少请求进入量，避免资源耗尽。
• 问：熔断的“半开”状态如何设计？比如恢复时间？
  回答要点：熔断后，定时（如每秒）检测服务是否恢复，若连续n次（如5次）调用成功，则从半开状态转为正常，避免过早恢复导致故障再次触发。
• 问：降级策略如何设计？比如哪些功能属于核心业务？
  回答要点：明确核心业务（如交易、登录），非核心功能（如用户侧次要查询、数据统计）降级，通过配置（如开关）控制，确保核心流程不受影响。
• 问：限流和熔断的区别？比如在秒杀场景中如何区分？
  回答要点：限流是控制入口流量速率，防止服务器过载；熔断是隔离故障服务，避免级联故障。比如限流控制总请求数，熔断则当库存服务故障时，直接返回失败，不继续调用库存服务。

7) 【常见坑/雷区】

• 限流阈值设置不当：过高导致服务器过载，过低拒绝正常流量，影响用户体验。
• 熔断误触发：阈值设置过严，正常波动（如网络抖动）触发熔断，导致服务不可用。
• 降级策略不合理：关闭核心功能（如交易流程中的关键步骤），导致用户无法完成关键操作，影响业务目标。
• 熔断恢复策略过快：故障未完全修复，过早恢复导致级联故障，比如熔断后立即恢复，但服务仍不稳定，再次触发熔断。
• 限流和熔断混淆：将限流作为熔断，或反之，导致策略失效，比如用限流代替熔断，无法隔离故障服务。