设计一个高并发的秒杀系统，需要考虑哪些核心组件和技术？请详细说明系统架构、数据一致性处理、限流熔断降级策略。
新凯来算法技术工程师难度：困难
答案
1) 【一句话结论】
高并发秒杀系统核心是通过分布式锁保障原子性、限流控制流量峰值、熔断降级应对异常，结合缓存加速与异步处理提升吞吐量，整体架构分层解耦（API网关、秒杀核心、库存服务、消息队列、数据库），核心目标是解决资源竞争与数据一致性。
2) 【原理/概念讲解】
老师口吻解释核心组件：
- 分布式锁：类似“一人一票”的排他机制，确保同一商品同一时间仅被一个用户扣减库存。常用Redis的
SETNX命令（SET if Not Exists），若成功则执行库存操作，失败则返回失败。关键点：需设置合理的过期时间（TTL），避免锁过期导致超卖（如SETNX key=seckill:123:userId value=1001 EX 10，10秒内锁有效，防止因网络延迟或异常导致锁释放）。 - 限流策略：
- 令牌桶：持续生成“令牌”，请求消耗令牌，流量平滑（如秒杀前预热令牌，确保请求快速通过）；漏桶：按固定速率生成“水滴”，严格限制峰值（如网络带宽控制，适用于突发流量）。注意：令牌桶需预置令牌数（如初始1000令牌），漏桶易积压请求。
- 熔断降级：当服务调用失败率超过阈值（如50%）时，直接返回失败，避免级联故障。动态阈值：基于滑动窗口统计失败率，动态更新阈值（如失败率从30%升至50%时触发熔断，避免过早或过晚熔断）。
- 缓存与异步处理：Redis缓存商品信息、库存，减少数据库压力；消息队列（如RabbitMQ）异步处理库存更新，提升吞吐量。缓存雪崩：设置缓存过期时间（如5分钟），并使用Redis的
setnx防止雪崩（如SETNX cache:sku:123 0 EX 300，避免大量请求同时击穿缓存）。
3) 【对比与适用场景】
| 对比项 | 定义/特性 | 使用场景 | 注意点 |
|---|---|---|---|
| 限流策略 | 令牌桶：持续生成令牌，请求消耗令牌，流量平滑（支持突发流量）；漏桶：按固定速率放水，严格限制峰值（适用于网络带宽控制） | 秒杀前流量预热、日常流量控制 | 令牌桶需预置令牌数，漏桶易积压请求 |
| 一致性策略 | 最终一致性：通过时间窗口（如1秒）保证一致性（如消息队列异步更新库存）；强一致性：数据库事务（高并发下性能差，适用于金融等强一致性场景） | 秒杀场景（允许短暂不一致） | 最终一致性需设计时间窗口，强一致性需牺牲性能 |
| 熔断策略 | 静态阈值：固定失败率（如50%）；动态阈值：基于统计的阈值自适应（如滑动窗口计算失败率） | 服务调用失败率高时保护系统 | 静态阈值可能过早或过晚熔断，动态阈值更智能 |
4) 【示例】
最小可运行架构（伪代码）：
- 前端请求：
POST /seckill?skuId=123&userId=1001 - API网关：通过令牌桶限流（每秒1000令牌）
- 秒杀服务：
- 检查Redis分布式锁（
SETNX key=seckill:123:userId value=1001 EX 10，10秒内锁有效） - 锁成功则执行库存扣减（
WATCH stock:123; MULTI; DECR stock:123; EXEC） - 扣减成功后发送消息到RabbitMQ（
publish("seckill:stock:update", {skuId:123, userId:1001})）
- 检查Redis分布式锁（
- 库存服务：消费消息，更新数据库库存（事务处理，确保原子性，如
BEGIN; UPDATE stock SET count=count-1 WHERE skuId=123; COMMIT）
5) 【面试口播版答案】
“面试官您好，设计高并发秒杀系统核心是解决资源竞争与数据一致性。首先，系统架构分层，API网关做限流，秒杀核心服务用Redis分布式锁（SETNX加EXPIRE）保证原子性，库存服务通过缓存+异步消息处理。数据一致性方面，秒杀请求用分布式锁确保单次扣减，库存更新用最终一致性（消息队列+时间窗口）。限流用令牌桶（每秒1000令牌），熔断用动态阈值（失败率超过50%时断路）。具体来说，前端请求到API网关，通过令牌桶限流后，进入秒杀服务，先尝试Redis锁，成功则扣减Redis库存，失败则返回库存不足。扣减成功后，发送消息到RabbitMQ，库存服务消费消息更新数据库库存。这样既保证单次请求的原子性，又通过异步处理提升吞吐量。”
6) 【追问清单】
- 问题1：分布式锁过期时间如何设置？
回答要点：结合业务场景，如秒杀时长（10秒内锁有效），避免因网络延迟或异常导致锁释放，引发超卖。 - 问题2：缓存雪崩如何处理？
回答要点：设置缓存过期时间（如5分钟），并使用Redis的setnx防止雪崩（如SETNX cache:sku:123 0 EX 300，避免大量请求同时击穿缓存）。 - 问题3：熔断阈值的动态调整机制？
回答要点：基于滑动窗口统计失败率，动态更新阈值（如失败率从30%升至50%时触发熔断，避免过早或过晚熔断）。 - 问题4：消息队列的可靠性保障？
回答要点：消息持久化（如RabbitMQ的deliveryMode=2），消费确认机制（acknowledgment），重试机制（如消费失败后重试3次）。 - 问题5：数据库分库分表策略？
回答要点：按SKU分库，按时间分表（如按月分表），避免单表过大，提升查询和写入性能。
7) 【常见坑/雷区】
- 分布式锁过期时间设置过短：导致锁被误释放，超卖。
- 限流阈值设置不合理：过高导致系统过载，过低影响用户体验。
- 缓存雪崩：未命中时直接查询数据库，导致数据库压力激增。
- 消息队列积压：未及时消费导致库存更新延迟，影响秒杀结果。
- 熔断阈值设置不当：过早熔断影响正常请求，过晚无法保护系统。