如何设计一个秒杀系统？

场景题与系统设计_秒杀系统 0 26

这道题考察大家对秒杀系统是否有过基本的认识，秒杀出现在淘宝双十一，或者有优惠活动抢购产品的场景，秒杀系统面临的主要挑战是如何保证在短时间内处理大量并发请求，并且保证库存的准确性和系统的稳定性。

1. 需求分析

业务需求：秒杀系统一般会有一个明确的时间窗口，在这个时间窗口内，用户可以抢购商品。秒杀商品一般是限量的，系统需要确保在每个用户完成购买之前，库存量能够被准确更新。
系统功能：
- 商品展示：展示秒杀商品信息。
- 用户请求：用户通过点击抢购按钮发起秒杀请求。
- 库存管理：秒杀商品的库存需要实时更新，防止超卖。
- 订单生成：在秒杀成功后生成订单，并扣除库存。
- 用户体验：秒杀请求的延迟要尽量低，保证秒杀活动期间的高并发请求能够得到合理的响应。

2. 系统架构设计

秒杀系统的设计应该具备高并发、高可用和高扩展性。可以采用以下架构：

前端请求层：
- 用户发送秒杀请求，通常会使用 负载均衡（如 Nginx）将请求分发到不同的后端服务器。
- 可以使用 CDN 来缓存静态内容，减轻后端服务器的压力。
限流层（防刷）：
- 秒杀系统需要防止恶意刷单，可以采用以下几种方式来做流量控制：
- 令牌桶/漏桶算法：通过限制每秒请求的次数来防止过多请求进入后台。
- IP限流：对同一IP的请求进行频率限制。
- 验证码：防止机器人通过自动化工具发起请求。
缓存层：
- 使用缓存（如 Redis）来存储商品的库存信息。缓存可以大大减少数据库的访问压力。
- 利用 Redis 的 原子性操作，比如通过 DECR（减少库存）来保证库存的扣减操作是原子的。
消息队列：
- 使用 消息队列（如 Kafka 或 RabbitMQ）来异步处理秒杀请求。
- 用户的秒杀请求可以先进入消息队列，后台服务可以从队列中取出请求进行处理。这样做的目的是将高并发请求转化为异步处理，避免系统直接处理大量请求。
库存扣减：
- 系统通过缓存（Redis）来快速访问库存信息。为了防止并发更新库存，通常采用 分布式锁 或 乐观锁。
- 乐观锁：在库存扣减时进行 CAS 操作，只有在库存没有被其他请求修改的情况下，才能更新库存。
- 分布式锁：通过 Redis 或 Zookeeper 实现分布式锁，确保同一时刻只有一个请求能修改库存，防止库存超卖。
数据库层：
- 数据库存储秒杀商品的详细信息、用户的订单信息等。为了避免秒杀期间数据库过载，可以使用 读写分离，将查询请求分发到只读数据库，写操作（如更新库存）发送到主数据库。
- 数据库采用 分库分表 的方式，将秒杀数据分散到多个数据库中，提高性能。
订单生成与支付：
- 秒杀成功后生成订单，并进行支付流程。支付过程需要处理好 幂等性（防止重复支付）。
- 可以通过 幂等ID 来确保支付请求不会被重复处理。