如何处理系统在双十一等流量峰值期间出现的“服务雪崩”？请描述你的应对措施，包括技术手段和流程。
Tencent技术运营难度：中等
答案
1) 【一句话结论】：在流量峰值期间，通过“流量削峰（缓存、队列缓冲）+ 请求控制（限流、熔断）+ 功能降级（非核心功能暂停）+ 自动化监控与快速恢复”的组合策略，快速识别并隔离故障，避免服务雪崩，保障核心服务稳定性。
2) 【原理/概念讲解】：老师口吻，解释服务雪崩：当系统某部分因流量过大导致超时或宕机，会引发连锁反应（如用户请求A调用B，B调用C，C因压力过大超时，导致B超时、A超时，最终用户请求全部失败）。应对手段：
- 限流：控制请求速率（如令牌桶算法），限制每秒请求数，防止系统过载。
- 熔断：当服务调用失败率超过阈值时，直接返回失败（如Hystrix断路器），避免请求继续堆积。
- 降级：暂停非核心功能（如次要API、非关键页面），释放资源给核心服务。
- 削峰：通过Redis缓存热点数据、消息队列（如Kafka）缓冲请求，平滑流量。
3) 【对比与适用场景】：
| 技术手段 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 限流 | 控制请求速率，限制每秒请求数 | 主动按速率限制 | 高并发场景，防止系统过载 | 阈值需合理，避免影响正常请求 |
| 熔断 | 服务失败率超阈值时，直接返回失败 | 主动断开调用，避免级联 | 服务间调用，防止故障扩散 | 阈值需平衡可用性与故障恢复 |
| 降级 | 暂停非核心功能，释放资源 | 主动降级，优先保障核心 | 核心业务压力过大时 | 需明确核心与非核心功能 |
| 削峰 | 通过缓存、队列缓冲流量 | 主动缓冲，平滑流量 | 热点数据、突发流量 | 缓存需考虑一致性，队列需防积压 |
4) 【示例】：以限流（令牌桶算法）为例，伪代码：
class RateLimiter:
def __init__(self, rate, capacity):
self.rate = rate # 每秒生成token数
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
return self.tokens >= 1 # 返回True表示允许请求
调用时，每个请求调用acquire()，若返回False则拒绝请求。
5) 【面试口播版答案】：
“面试官您好，针对双十一等流量峰值导致的“服务雪崩”，我的应对措施主要围绕流量控制（限流、熔断）+ 功能降级+ 流量削峰，结合自动化监控和快速恢复流程。首先，流量削峰方面，我们会通过Redis缓存热点数据（如商品信息、优惠券），减少数据库压力；对于需要异步处理的请求，用消息队列（如Kafka）缓冲，避免直接调用后端服务。然后，流量控制：对核心接口启用令牌桶限流，比如每秒限制1000个请求，防止后端服务过载；当服务调用失败率超过50%时，启用熔断器（如Hystrix），直接返回失败，避免请求继续堆积。同时，实施功能降级，比如暂停次要API（如用户反馈统计接口），将资源留给核心订单处理、支付接口。最后，通过Prometheus+Grafana监控关键指标（如接口QPS、响应时间、失败率），当指标超过阈值时，自动触发熔断或降级，并通知运维团队。整个流程是：监控预警→快速响应（限流/熔断/降级）→资源恢复→服务恢复，确保在流量峰值期间系统稳定。”
6) 【追问清单】：
- 追问1：熔断的阈值（如失败率、超时时间）怎么设置？
回答要点：通常失败率超过50%或超时时间超过1秒时触发熔断，阈值需根据业务重要性和系统容量调整，避免误触发或漏触发。 - 追问2：降级策略中，如何判断哪些功能是非核心？
回答要点：根据业务优先级，核心功能（如订单支付、商品购买）优先保障，非核心（如用户评论、次要统计）可暂时暂停，确保资源分配给关键业务。 - 追问3：限流和熔断的区别？为什么需要同时使用？
回答要点：限流是按速率限制请求，防止系统过载；熔断是当服务不可用时，断开调用，避免级联故障。两者结合，限流防过载，熔断防故障扩散，共同应对雪崩。 - 追问4：如何处理限流后用户请求被拒绝的情况？
回答要点：返回友好的错误提示（如“系统繁忙，请稍后再试”），并记录请求信息，后续通过重试机制（如指数退避）尝试。 - 追问5：自动化流程中，监控指标如何定义？
回答要点：定义关键指标如接口QPS（请求速率）、响应时间（P99）、失败率（失败请求数/总请求数），设置阈值（如QPS超过阈值或失败率超过阈值时触发告警）。
7) 【常见坑/雷区】：
- 坑1：只说限流，忽略熔断和降级，导致故障扩散。
雷区：限流只能控制请求速率，无法应对服务本身故障，熔断和降级是必要的补充。 - 坑2：限流阈值设置不合理，要么太松导致过载，要么太严影响正常请求。
雷区：阈值需根据系统容量、业务峰值、正常请求量综合计算，避免误判。 - 坑3：降级策略未明确核心与非核心，导致资源分配混乱。
雷区：需明确业务优先级，核心功能优先保障，非核心功能降级，否则可能影响用户体验。 - 坑4：未考虑异步处理和缓存，导致数据库或后端服务压力过大。
雷区：削峰手段（缓存、队列）是基础，若忽略，限流和熔断效果会大打折扣。 - 坑5：缺乏自动化监控和告警，依赖人工监控，响应速度慢。
雷区：自动化监控能快速识别异常，及时触发应对措施，人工监控响应慢，易错过最佳处理时机。