在游戏活动期间（如节日、活动），开屏广告请求量会激增（比如平时10万QPS，活动期间达到50万QPS），请设计系统扩容方案和流量控制策略。
9377游戏广告投放难度：困难
答案
1) 【一句话结论】：采用“弹性扩容+流量削峰”双策略，通过动态增加广告服务实例应对QPS激增，结合限流（控制入口流量）与熔断（保护后端服务）机制，确保活动期间系统稳定且用户体验不降级。
2) 【原理/概念讲解】：首先解释QPS（Queries Per Second，每秒请求数），是衡量系统流量的核心指标，活动期间QPS从10万升至50万，相当于“交通流量”从正常到高峰，需扩容（增加“车道”）和限流（控制入口）。
- 弹性扩容：像Kubernetes的Horizontal Pod Autoscaler（HPA），根据CPU/内存使用率或自定义指标（如QPS）自动增加/减少服务实例，比如活动前预置扩容策略，当QPS超过阈值时自动扩容，活动后回缩。
- 限流：通过令牌桶/漏桶算法控制请求速率，比如令牌桶每秒生成10个令牌，当请求到达时消耗令牌，若令牌不足则拒绝请求（严格限流）或返回429（缓冲区限流）。
- 熔断：借鉴断路器模式，当后端服务响应时间超过阈值或错误率超过阈值时，触发熔断，直接返回错误（如503），避免请求堆积导致雪崩效应，活动结束后恢复。
3) 【对比与适用场景】：
| 对比项 | 限流（Rate Limiting） | 熔断（Circuit Breaker） |
|---|---|---|
| 定义 | 控制请求速率，防止服务过载 | 保护后端服务，防止故障扩散 |
| 特性 | 严格按速率限制，可能拒绝合法请求 | 短期拒绝请求，恢复后自动重试 |
| 使用场景 | 活动期间控制入口流量，避免资源耗尽 | 后端服务不稳定时快速隔离 |
| 注意点 | 阈值需合理（过高影响体验，过低无效） | 熔断恢复策略需谨慎（避免误判） |
4) 【示例】（伪代码）：
# 广告服务请求处理流程
def handle_ad_request(request):
# 1. 限流检查（令牌桶）
if not token_bucket.consume(1):
return {"code": 429, "msg": "请求太频繁"}
# 2. 熔断检查（状态存储）
if circuit_breaker.is_open():
return {"code": 503, "msg": "服务暂时不可用"}
# 3. 扩容状态检查（K8s HPA）
if is_overloaded():
# 触发扩容（比如调用K8s API增加实例）
scale_service()
# 4. 处理业务逻辑
return process_ad_logic(request)
其中token_bucket是令牌桶实现（每秒10个令牌），circuit_breaker是熔断器（状态存储在Redis），is_overloaded()通过监控QPS/响应时间判断是否超载，scale_service()调用K8s API增加广告服务Pod数量。
5) 【面试口播版答案】：
“面试官您好，针对活动期间QPS激增的问题，我的核心方案是‘弹性扩容+流量削峰’双策略。首先，弹性扩容方面，我会采用Kubernetes的Horizontal Pod Autoscaler（HPA），根据QPS或CPU使用率自动调整广告服务实例数量——比如活动前预置扩容策略，当QPS超过30万时自动增加实例，活动后回缩，确保资源利用率最大化。然后是流量控制，结合限流和熔断：限流用令牌桶算法，每秒控制10万请求（对应平时QPS），活动期间自动提升令牌生成速率（比如每秒50万），避免后端服务过载；熔断则采用断路器模式，当后端响应时间超过500ms或错误率超过50%时，直接返回503，防止请求雪崩。这样既能应对流量激增，又能保证用户体验和系统稳定性。”（约80秒）
6) 【追问清单】：
- Q1：如何确定限流的阈值（比如令牌桶的速率）？
回答要点：通过历史数据（如平时QPS10万，活动前测试不同速率对后端的影响），结合业务需求（如活动期间允许一定延迟，但不超过3秒），动态调整。 - Q2：熔断的恢复策略是怎样的？
回答要点：设置恢复时间（比如5秒），当后端服务恢复（响应时间<200ms，错误率<20%）时，自动从“半开”状态切换到“关闭”状态，允许请求重试。 - Q3：如果扩容延迟（比如K8s扩容需要3秒），如何避免服务不可用？
回答要点：采用“预扩容”策略，活动前提前增加实例（比如平时10个实例，活动前增加到20个），或者结合限流提前控制流量，减少扩容压力。 - Q4：监控哪些指标来触发扩容和限流？
回答要点：QPS（核心指标）、响应时间（P95/P99）、CPU/内存使用率（K8s指标）、错误率（4xx/5xx）。 - Q5：如果活动期间流量突然下降（比如活动结束），如何快速回缩实例？
回答要点：HPA的自动回缩功能，或者手动触发缩容，结合业务场景（如活动后1小时内回缩至平时水平）。
7) 【常见坑/雷区】：
- 坑1：只谈扩容不提限流：活动期间流量激增时，仅扩容可能导致后端服务过载，需结合限流控制入口。
- 坑2：限流策略选错：直接拒绝请求（如429）会导致用户体验差，应采用缓冲区限流（返回429但允许重试）或响应延迟（如200ms延迟）。
- 坑3：熔断恢复机制不明确：熔断后直接恢复可能导致请求堆积，需设置恢复时间窗口，避免误判。
- 坑4：扩容延迟导致服务不可用：未考虑扩容延迟，活动期间流量激增时服务直接宕机。
- 坑5：未考虑监控和告警：没有实时监控QPS、响应时间等指标，无法及时调整策略。