请分享一个你在投放系统项目中遇到的复杂技术挑战（如突发流量导致系统雪崩），你是如何分析、定位并解决的？体现问题解决能力。

1) 【一句话结论】：在投放系统遭遇突发流量雪崩时，通过结合流量控制（限流）、故障隔离（熔断）、任务解耦（异步队列）及实时监控，快速定位并恢复系统，同时优化系统对流量波动的韧性。

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

• 雪崩效应：当系统某层（如API网关）突然承受远超设计能力的流量，服务超时或失败，导致上游调用失败，进而引发下游服务也因请求过多而崩溃，像多米诺骨牌，最终整个系统不可用。
• 限流：通过限制单位时间内的请求数量，防止流量过载。常用令牌桶算法，每秒生成固定令牌，请求消耗令牌，无令牌则拒绝，可平滑流量。
• 熔断：当下游服务错误率超过阈值（如5分钟内错误率>50%），上游服务直接返回错误，避免级联失败，类似保险丝断开。
• 异步处理：将非实时任务（如日志写入、数据同步）放入消息队列（如Kafka），系统处理请求后，将任务放入队列，由消费者异步处理，解耦系统，避免阻塞主流程。

3) 【对比与适用场景】：

策略	定义	特性	使用场景	注意点
固定窗口	每个时间窗口固定请求量	简单，但窗口末尾可能突发流量	流量较平稳	容易产生突发流量，导致超时
滑动窗口	时间窗口动态滑动，统计当前窗口内请求	流量平滑，避免突发	流量波动大	实现复杂，需精确时间同步
令牌桶	持续生成令牌，请求消耗令牌	流量平滑，可配置速率	需要精确控制速率	需要高精度时钟

4) 【示例】：
假设投放系统API网关处理请求，突发流量时，限流和熔断处理流程：

• 请求到达：检查令牌桶，无令牌则返回429 Too Many Requests。
• 有令牌：调用下游服务（如计算投放预算的微服务），若下游超时（>1秒），触发熔断，返回503 Service Unavailable，并记录熔断事件。
• 正常时：将日志写入消息队列（Kafka），由消费者异步处理，避免阻塞主流程。

伪代码（简化）：

# 限流逻辑（令牌桶）
def rate_limited(request):
    if not token_bucket.consume():
        return 429, "Too many requests"
    # 调用下游
    try:
        result = downstream_service.call()
    except TimeoutError:
        # 熔断
        circuit_breaker.trip()
        return 503, "Service is breaking"
    return 200, result

# 熔断器
class CircuitBreaker:
    def __init__(self, error_threshold=0.5, window=5*60):
        self.error_count = 0
        self.window = window
        self.last_reset = time.time()
    
    def trip(self):
        self.error_count += 1
        if self.is_open():
            self.reset()
    
    def is_open(self):
        now = time.time()
        if now - self.last_reset < self.window:
            return self.error_count / (now - self.last_reset) > error_threshold
        else:
            self.error_count = 0
            self.last_reset = now
            return False
    
    def reset(self):
        self.error_count = 0
        self.last_reset = time.time()

5) 【面试口播版答案】：
（约90秒）
“面试官您好，我之前在投放系统项目中遇到过一次突发流量导致的系统雪崩。当时是某个投放活动开启时，流量突然激增10倍，导致API网关超时，进而引发下游服务也因请求过多而崩溃，系统响应时间从正常100ms飙升至10秒以上，最终服务不可用。我首先通过监控平台（如Prometheus+Grafana）发现API网关的请求延迟和错误率急剧上升，定位到流量激增是核心原因。接下来，我采取了分层措施：首先在网关层引入令牌桶限流，限制每秒请求量到设计容量的80%，避免突发流量冲击；然后对下游计算服务启用熔断器，当错误率超过50%时，上游直接返回错误，避免级联失败；最后将日志记录等非实时任务放入Kafka队列，由消费者异步处理，解耦系统。实施后，系统在流量激增时能快速恢复，错误率从100%降到5%以下，响应时间回到正常水平。通过这次经历，我学会了如何通过限流、熔断、异步解耦等手段提升系统韧性，应对流量波动。”

6) 【追问清单】：

• 问：具体监控指标有哪些？如何判断流量异常？
  回答要点：监控API网关的请求延迟（P99）、错误率（4xx/5xx比例），下游服务的错误率、超时率，以及流量变化趋势（如QPS突然上升10倍）。
• 问：熔断的阈值（如错误率、超时时间）怎么设定的？有没有调整过？
  回答要点：错误率阈值设为5分钟内错误率>50%，超时时间>1秒。初期根据历史数据设定，后来根据实际流量调整，比如活动期间适当降低阈值，确保服务可用性。
• 问：限流策略的参数（如令牌桶的速率）如何确定？有没有考虑用户体验？
  回答要点：根据系统设计容量（如API网关每秒处理1000请求），令牌桶速率设为800，留20%余量应对突发。同时，对于高价值请求（如用户点击投放按钮），可以设置更宽松的限流策略，避免影响核心业务。
• 问：异步队列的容量如何计算？有没有考虑消息积压？
  回答要点：根据历史峰值流量和消费者处理能力，Kafka队列初始容量设为100万条，消费者每秒处理500条，确保队列不会溢出。同时，监控队列长度，当长度超过阈值时，触发告警，调整消费者数量或限流策略。
• 问：如果系统在限流后，用户反馈请求被拒绝，如何优化？
  回答要点：引入排队机制，将限流后的请求放入队列，由消费者按顺序处理，避免直接拒绝。同时，对高优先级请求（如紧急投放请求）设置优先级，优先处理。

7) 【常见坑/雷区】：

• 坑1：只说限流没说熔断，导致下游服务因级联失败而崩溃，问题未根本解决。
• 坑2：限流策略选错（如固定窗口），导致流量在窗口末尾集中，引发超时，反而影响用户体验。
• 坑3：没考虑异步解耦，日志写入阻塞主流程，导致系统响应时间增加，雪崩效应加剧。
• 坑4：熔断阈值设置过高，导致服务在正常波动时频繁熔断，影响可用性。
• 坑5：监控指标不全面，没关注流量变化趋势，导致问题发现不及时，延误解决时间。