在移动端应用中，如何处理AI功能的高并发请求？请举例说明限流、熔断、降级策略，并说明如何监控高并发下的系统性能。

1) 【一句话结论】在移动端AI功能高并发场景下，需通过**限流（控制请求速率）、熔断（故障隔离）、降级（核心功能优先）**结合，并配合实时监控（如QPS、错误率、响应时间），动态调整策略，保障系统稳定与用户体验。

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

• 限流：控制请求进入系统的速率，防止过载。类比“交通红绿灯”，限制每秒通过的车辆数，避免系统拥堵。核心是通过算法（如令牌桶、漏桶）限制请求频率。
• 熔断：当服务出现故障（如超时、错误率过高）时，自动断开请求，避免级联故障。类比“保险丝”，电流过大时熔断，保护系统。核心是设置故障阈值（如错误率、超时时间），超限则触发熔断。
• 降级：在系统压力过大时，暂时牺牲非核心功能，保障核心功能可用。类比“手机电量低时关闭后台应用”，保证通话、导航等核心功能。核心是明确核心功能（如AI推荐），非核心功能（如实时推荐）降级。

3) 【对比与适用场景】

策略	定义	特性	使用场景	注意点
限流	限制请求的速率（如QPS）	预防性，控制流量	高并发场景（如AI推荐、搜索）	需合理设置阈值，避免影响正常请求
熔断	故障时断开请求，后续重试	主动性故障隔离	服务依赖场景（如调用第三方AI服务）	阈值（错误率、超时）需动态调整
降级	牺牲非核心功能，保障核心	临时性，牺牲部分体验	系统压力过大时（如CPU高）	需明确核心功能，避免误降级

4) 【示例】
假设移动端AI推荐功能，高并发时处理：

• 限流：使用令牌桶算法，每秒允许1000个请求，超过则拒绝或排队。
• 熔断：当调用第三方AI服务错误率超过50%或超时超过2秒，触发熔断，返回默认推荐。
• 降级：当系统CPU使用率超过80%时，暂时关闭实时推荐，仅返回历史热门推荐。
  伪代码（限流）：

class RateLimiter:
    def __init__(self, rate, capacity):
        self.rate = rate  # 每秒令牌数
        self.capacity = capacity  # 桶容量
        self.tokens = capacity
        self.last_time = time.time()
    
    def acquire(self):
        now = time.time()
        elapsed = now - self.last_time
        self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
        self.last_time = now
        if self.tokens < 1:
            return False  # 限流
        self.tokens -= 1
        return True

5) 【面试口播版答案】
“面试官您好，处理移动端AI高并发请求，核心是通过限流、熔断、降级结合，配合实时监控。首先，限流用令牌桶控制请求速率，比如每秒1000个请求，超过则拒绝。然后，熔断当调用第三方AI服务错误率超过50%时，断开请求，避免级联故障。降级比如系统CPU高时，返回默认推荐，保障核心功能。监控方面，看QPS、错误率、响应时间，用Prometheus+Grafana实时看，发现异常及时调整策略。这样能保证系统在高并发下稳定，用户体验好。”

6) 【追问清单】

• 问：限流算法选令牌桶还是漏桶？为什么？
  回答：令牌桶更灵活，支持突发流量（如突发请求后能快速恢复），漏桶是恒定速率（适合严格限制）。
• 问：熔断的阈值（错误率、超时）如何设置？
  回答：错误率超50%或超时超2秒触发，阈值需结合业务容忍度调整。
• 问：降级策略的触发条件？
  回答：系统CPU/内存超阈值（如CPU 80%），或第三方服务响应超阈值（如3秒），触发降级。
• 问：分布式环境下如何做限流？
  回答：用Nginx限流模块或Redis分布式锁，共享令牌桶，避免单点失效。
• 问：监控哪些指标？如何报警？
  回答：监控QPS、错误率、响应时间、资源使用率，QPS超阈值或错误率上升时发送告警。

7) 【常见坑/雷区】

• 限流与熔断混淆：限流是控制流量，熔断是故障隔离，不能混用。
• 降级策略不合理：降级后用户完全无法使用，导致流失。
• 监控指标缺失：无实时监控，无法及时发现问题。
• 限流阈值设置不当：过高导致系统过载，过低影响体验。
• 熔断阈值设置过松：频繁熔断，影响正常请求。