在快手直播带货大促期间（如双11），系统面临高并发请求（如商品点击、支付），请描述如何设计系统以应对，并说明降级策略（如非核心功能降级）。
快手数据研发工程师 📦 工程类难度：困难
答案
1) 【一句话结论】在快手直播大促高并发场景下，需通过微服务拆分、动态限流（令牌桶）、缓存（随机TTL+分布式锁控制回源）、消息队列（Kafka高可靠）及熔断降级等综合设计，优先保障核心业务（如支付、商品点击），非核心功能按优先级降级，并通过监控与自动恢复机制保障系统稳定性。
2) 【原理/概念讲解】老师讲解：
- 限流：控制请求速率，防止过载。采用令牌桶算法（按速率生成令牌，请求有令牌则放行），动态调整阈值（如双11期间商品点击接口限流1500次/秒，根据实时负载动态增加令牌生成速率）。类比“交通限速”，避免系统过载。
- 缓存雪崩应对：设置缓存TTL（如商品信息缓存1小时），并采用随机TTL（每个key的TTL随机偏移，如±30%），避免集中失效。若缓存失效，通过Redis分布式锁或队列（如Redis队列）控制并发回源，例如用Lua脚本加锁（
SETNX lock:123 1 EX 10），确保同一时间仅少量请求回源数据库，避免雪崩。 - 消息队列解耦与削峰：支付请求放入Kafka（replication.factor=3，保证数据不丢失），消费端设置重试机制（如失败3次后标记为死信队列），并监控堆积延迟（如延迟>5秒触发扩容消费者）。类比“水库削峰”，平滑流量。
- 熔断降级：当服务故障（如第三方支付接口超时），熔断器触发，调用降级接口返回默认结果（“支付系统繁忙，请稍后重试”），并记录熔断日志。熔断器设置时间窗口（如5秒），错误率超过阈值（如50%）后触发，错误率低于20%后自动恢复。
- 灰度发布：新版本分阶段发布（如1%用户、5%用户、全量），通过流量切分比例（如1%用户流量）验证指标（响应时间<200ms，错误率<1%），指标正常后逐步增加流量。
3) 【对比与适用场景】
| 对比项 | 限流 | 熔断 |
|---|---|---|
| 定义 | 控制请求进入系统的速率，防止过载 | 当服务故障时，自动断开请求，避免级联故障 |
| 核心思想 | 限制流量，按速率放行 | 识别故障，暂时拒绝请求 |
| 适用场景 | 请求入口（如API网关） | 服务间调用（如支付服务调用第三方支付） |
| 注意点 | 阈值需动态调整，避免影响正常流量 | 需快速恢复，避免长期降级，设置合理的熔断策略 |
4) 【示例】（商品点击请求处理流程）：
- 用户请求商品点击接口（
/api/product/click?id=123）。 - 限流：API网关用令牌桶限流，当前请求有令牌则放行，否则返回429。
- 缓存：先查Redis（key:
product_click:123），有则直接返回；无则回源数据库。 - 缓存雪崩应对：若缓存无，Redis设置随机TTL（如TTL=3600s±30%），并执行Lua脚本加锁（
SETNX lock:123 1 EX 10），成功则回源数据库（UPDATE product SET click_count=click_count+1 WHERE id=123），失败则重试或排队。 - 响应：返回商品信息及点击数。
支付流程降级与自动恢复：
- 用户发起支付请求（
/api/payment/pay），若支付服务故障（第三方接口超时），熔断器触发，调用降级接口返回“支付系统繁忙，请稍后重试”。 - 熔断器时间窗口5秒，错误率从50%降至20%后，自动恢复调用支付服务。
5) 【面试口播版答案】
“在快手双11大促高并发场景，系统设计需从流量控制、核心保障、降级策略三方面入手。首先，通过限流（令牌桶算法，商品点击接口每秒限1500次，动态调整速率），控制入口流量；其次，缓存（Redis）减少数据库压力，商品信息缓存后直接返回，并设置随机TTL（避免雪崩）；然后，消息队列（Kafka，副本因子3）解耦支付流程，异步处理请求，削峰填谷。对于降级，核心功能（如支付、商品点击）不降级，非核心功能（如次要推荐）按优先级降级，比如支付服务故障时，调用降级接口返回默认结果。通过监控（Prometheus）实时观察指标，结合熔断器（5秒窗口，错误率阈值）自动恢复，以及分阶段灰度发布（1%用户流量验证指标正常后全量），确保系统稳定。”
6) 【追问清单】
- 问：如何具体应对缓存雪崩？比如随机TTL或分布式锁控制回源？
回答要点：设置缓存TTL随机偏移（如±30%），用Redis Lua脚本加锁控制并发回源，避免大量请求同时回源数据库。 - 问：消息队列的延迟和可靠性如何保障？比如Kafka的副本因子和消费端重试？
回答要点：Kafka设置replication.factor=3，保证数据不丢失；消费端设置重试机制（失败3次后标记死信队列），并监控堆积延迟（延迟>5秒触发扩容消费者）。 - 问：降级后的自动恢复机制是怎样的？比如熔断器如何判断恢复？
回答要点：熔断器设置时间窗口（如5秒），错误率超过阈值（如50%）触发降级，错误率低于20%后自动恢复调用服务。 - 问：灰度发布的具体步骤和指标验证标准？
回答要点：分阶段流量切分（1%用户→5%用户→全量），监控指标（响应时间<200ms，错误率<1%），指标正常后逐步增加流量。
7) 【常见坑/雷区】
- 坑1：缓存雪崩应对不具体，只说设置TTL，未提随机TTL或分布式锁，导致风险未覆盖。
- 坑2：消息队列可靠性描述不够，未涉及副本因子、重试机制，可能数据丢失或延迟过高。
- 坑3：降级自动恢复机制未说明，熔断后长期不可用，影响用户体验。
- 坑4：灰度发布无具体步骤，如流量切分比例、指标验证标准，缺乏可操作性。
- 坑5：限流阈值设置不合理，如过高导致系统过载，或过低影响正常用户请求。