秒杀系统设计实践
当我们设计一个秒杀系统的时候，我们应该考虑哪些问题？
- 设计任何业务系统，首先都要搞清楚这个系统所具备的特点；秒杀系统具备哪些业务特性？（瞬时流量大；大量并发读和并发写；大量并发扣减库存，保证数据一致性；）
- 利用什么技术手段去解决系统的业务特性？
- 如何做好压测？
- 本文参考代码：https://github.com/AndyGuo1/seconds-kill
秒杀业务&系统的特性？
业务特性：
- 瞬时并发流量集中；
- 对同一商品的库存操作频繁；
- 经常存在一些作弊、刷单行为；
系统特性：
- 高性能：秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键
- 一致性：秒杀商品减库存的实现方式同样关键，有限数量的商品在同一时刻被很多倍的请求同时来减库存，在大并发更新的过程中都要保证数据的准确性。
- 高可用：秒杀时会在一瞬间涌入大量的流量，为了避免系统宕机，保证高可用，需要做好流量限制；同时考虑一些极端情况出现时，如何做好planB
秒杀系统的优化方案思路？
1、后端优化
核心思路是将请求尽量拦截在系统上游
- 限流：屏蔽掉无用的流量，允许少部分流量走后端。假设现在的后端库存为10，有1000个购买请求，那么最终只有10个可以成功，99%的请求是无效的；
- 削峰：秒杀请求在时间上高度集中于某一个时间点，瞬时流量容易压垮系统，因此需要对流量进行削峰处理，缓冲瞬时流量，尽量让服务器对资源进行平缓处理
- 异步：将同步请求转换为异步请求，来提高并发量，本质也是削峰处理
- 利用缓存：创建订单时，每次都需要先查询判断库存，只有少部分成功的请求才会创建订单，因此可以将商品信息放在缓存中，减少数据库查询
- 负载均衡：利用 Nginx 等使用多个服务器并发处理请求，减少单个服务器压力
2、前端优化
- 限流：前端答题或验证码，来分散用户的请求
- 禁止重复提交：限定每个用户发起一次秒杀后，需等待才可以发起另一次请求，从而减少用户的重复请求
- 本地标记：用户成功秒杀到商品后，将提交按钮置灰，禁止用户再次提交请求
- 动静分离：将前端静态数据直接缓存到离用户最近的地方，比如用户浏览器、CDN 或者服务端的缓存中
3、防作弊优化
- 隐藏秒杀接口：如果秒杀地址直接暴露，在秒杀开始前可能会被恶意用户来刷接口，因此需要在没到秒杀开始时间不能获取秒杀接口，只有秒杀开始了，才返回秒杀地址 url 和验证 MD5，用户拿到这两个数据才可以进行秒杀；
- 同账号多次发出请求：前端优化部分的禁止多次提交可以避免；也可使用redis标志位，每个用户的所有请求都要先尝试在redis中插入一个userId_secondsKill标志位，成功插入才可以执行后续的秒杀逻辑，其他被过滤掉，执行完秒杀逻辑后删除标志位；
- 多账号同IP发出的多个请求：这种可以检测IP的请求频率，如果过于频繁则弹出一个验证码；
- 多账号不同IP发起不同的请求：这种一般都是僵尸账号，检测账号的活跃度或者等级等信息，来进行限制。比如微博抽奖，用 iphone 的年轻女性用户中奖几率更大。通过用户画像限制僵尸号无法参与秒杀或秒杀不能成功
4、数据结构部分
一般一张商品库存表，一张秒杀订单表
CREATE TABLE `product_stock` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`product_no` varchar(50) NOT NULL DEFAULT '' COMMENT '商品编号',
`product_name` varchar(50) NOT NULL DEFAULT '' COMMENT '商品名称',
`current_count` int(11) NOT NULL COMMENT '库存',
`sale_out` int(11) NOT NULL COMMENT '已售',
`version` int(11) NOT NULL COMMENT '乐观锁，版本号',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品库存表';
CREATE TABLE `product_order` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`order_no` int(11) NOT NULL COMMENT '订单号',
`product_no` varchar(50) NOT NULL DEFAULT '' COMMENT '商品编号',
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品秒杀订单表';5、代码部分
（1）、核心流程
部分简单流程代码，距离实际生产使用较远，但可以参考理解，
@Override
public int createWrongOrder(String productNo) throws Exception {
// 商品库存校验
Stock stock = checkStock(productNo);
// 商品库存扣减
saleStock(stock);
// 生成订单
int res = createOrder(stock);
return res;
}
private Stock checkStock(String productNo) throws Exception {
Stock stock = stockService.getStockById(productNo);
if (stock.getCount() < 1) {
throw new RuntimeException("库存不足");
}
return stock;
}
private int saleStock(Stock stock) {
stock.setSale(stock.getSale() + 1);
stock.setCount(stock.getCount() - 1);
return stockService.updateStockById(stock);
}
private int createOrder(Stock stock) throws Exception {
StockOrder order = new StockOrder();
order.setProductNo(stock.getProductNo());
order.setName(stock.getName());
order.setCreateTime(new Date());
int res = orderMapper.insertSelective(order);
if (res == 0) {
throw new RuntimeException("创建订单失败");
}
return res;
}
// 扣库存 Mapper 文件
@Update("UPDATE stock SET count=#{count,jdbcType=INTEGER},name=#{name,jdbcType=VARCHAR}, " + "sale=#{sale,jdbcType=INTEGER},version=#{version,jdbcType =INTEGER}" + "WHERE id=#{id,jdbcType=INTEGER}")由于库存校验和库存扣减是一个非原子的操作，所以可能造成超卖的现象；
（2）、解决超卖，乐观锁更新库存
悲观锁虽然可以解决超卖问题，但是加锁的时间可能会很长，会长时间的限制其他用户的访问，导致很多请求等待锁，卡死在这里，如果这种请求很多就会耗尽连接，系统出现异常。乐观锁默认不加锁，更失败就直接返回抢购失败，可以承受较高并发
@Override
public int createOptimisticOrder(int sid) throws Exception {
// 校验库存
Stock stock = checkStock(sid);
// 乐观锁更新
saleStockOptimstic(stock);
// 创建订单
int id = createOrder(stock);
return id;
}
// 乐观锁 Mapper 文件
@Update("UPDATE stock SET count = count - 1, sale = sale + 1, version = version + 1 WHERE " +
"id = #{id, jdbcType = INTEGER} AND version = #{version, jdbcType = INTEGER}")（3）、Redis计数限流
前面已经分析过，1000个请求，最终可能之后10个是可以生成订单有效的；也就是说有 990 的请求是无效的，这些无效的请求也会给数据库带来压力，因此可以在在请求落到数据库之前就将无效的请求过滤掉，将并发控制在一个可控的范围，这样落到数据库的压力就小很多
关于限流的方法，可以看这篇博客浅析限流算法，由于计数限流实现起来比较简单，因此采用计数限流，限流的实现可以直接使用 Guava 的 RateLimit 方法，但是由于后续需要将实例通过 Nginx 实现负载均衡，这里选用 Redis 实现分布式限流；
限流要保证写入 Redis 操作的原子性，因此利用 Redis 的单线程机制，通过 LUA 脚本来完成。
（4）、Redis 缓存商品库存信息
虽然限流能够过滤掉一些无效的请求，但是还是会有很多请求落在数据库上，通过 Druid 监控可以看出，实时查询库存的语句被大量调用，对于每个没有被过滤掉的请求，都会去数据库查询库存来判断库存是否充足，对于这个查询可以放在缓存 Redis 中，Redis 的数据是存放在内存中的，速度快很多。
所以有必要进行缓存预热；在秒杀开始前，需要将秒杀商品信息提前缓存到 Redis 中，这么秒杀开始时则直接从 Redis 中读取，也就是缓存预热，Springboot 中开发者通过 implement ApplicationRunner 来设定 SpringBoot 启动后立即执行的方法
@Component
public class RedisPreheatRunner implements ApplicationRunner {
@Autowired
private StockService stockService;
@Override
public void run(ApplicationArguments args) throws Exception {
// 从数据库中查询热卖商品，商品 id 为 1
Stock stock = stockService.getStockById(1);
// 删除旧缓存 todo 这里可以将三个库存相关字段缓存到一个key中
RedisPoolUtil.del(RedisKeysConstant.STOCK_COUNT + stock.getCount());
RedisPoolUtil.del(RedisKeysConstant.STOCK_SALE + stock.getSale());
RedisPoolUtil.del(RedisKeysConstant.STOCK_VERSION + stock.getVersion());
//缓存预热
int sid = stock.getId();
RedisPoolUtil.set(RedisKeysConstant.STOCK_COUNT + sid, String.valueOf(stock.getCount()));
RedisPoolUtil.set(RedisKeysConstant.STOCK_SALE + sid, String.valueOf(stock.getSale()));
RedisPoolUtil.set(RedisKeysConstant.STOCK_VERSION + sid, String.valueOf(stock.getVersion()));
}
}既然引入了缓存记录库存，就要解决缓存和数据库的数据一致性问题；推荐看参考中的 使用缓存的正确姿势，首先看下先更新数据库，再更新缓存策略，假设 A、B 两个线程，A 成功更新数据，在要更新缓存时，A 的时间片用完了，B 更新了数据库接着更新了缓存，这是 CPU 再分配给 A，则 A 又更新了缓存，这种情况下缓存中就是脏数据；
那么，如果避免这个问题呢？就是库存变更时，缓存不做更新，仅做删除，先更新数据库再删除缓存。对于上面的问题，A 更新了数据库，还没来得及删除缓存，B 又更新了数据库，接着删除了缓存，然后 A 删除了缓存，这样只有下次缓存未命中时，才会从数据库中重建缓存，避免了脏数据。但是，也会有极端情况出现脏数据，A 做查询操作，没有命中缓存，从数据库中查询，但是还没来得及更新缓存，B 就更新了数据库，接着删除了缓存，然后 A 又重建了缓存，这时 A 中的就是脏数据；但是这种极端情况需要数据库的写操作前进入数据库，又晚于写操作删除缓存来更新缓存，发生的概率极其小，不过为了避免这种情况，可以为缓存设置过期时间。一般还会利用分布式锁+失败队列补偿来解决，但是不适合这种高并发的写的场景，效率太低；
代码如下，仅供理解参考，比建议线上使用：
@Override
public int createOrderWithLimitAndRedis(int sid) throws Exception {
// 校验库存，从 Redis 中获取
Stock stock = checkStockWithRedisWithDel(sid);
// 乐观锁更新库存和Redis
saleStockOptimsticWithRedisWithDel(stock);
// 创建订单
int res = createOrder(stock);
return res;
}
// Redis 校验库存
private Stock checkStockWithRedisWithDel(int sid) throws Exception {
Integer count = null;
Integer sale = null;
Integer version = null;
List data = RedisPoolUtil.listGet(RedisKeysConstant.STOCK + sid);
if (data.size() == 0) {
// Redis 不存在，先从数据库中获取，再放到 Redis 中
Stock newStock = stockService.getStockById(sid);
RedisPoolUtil.listPut(RedisKeysConstant.STOCK + newStock.getId(), String.valueOf(newStock.getCount()),
String.valueOf(newStock.getSale()), String.valueOf(newStock.getVersion()));
count = newStock.getCount();
sale = newStock.getSale();
version = newStock.getVersion();
} else {
count = Integer.parseInt(data.get(0));
sale = Integer.parseInt(data.get(1));
version = Integer.parseInt(data.get(2));
}
if (count < 1) {
log.info("库存不足");
throw new RuntimeException("库存不足 Redis currentCount: " + sale);
}
Stock stock = new Stock();
stock.setId(sid);
stock.setCount(count);
stock.setSale(sale);
stock.setVersion(version);
// 此处应该是热更新，但是在数据库中只有一个商品，所以直接赋值
stock.setName("手机");
return stock;
}
private void saleStockOptimsticWithRedisWithDel(Stock stock) throws Exception {
// 乐观锁更新数据库
int res = stockService.updateStockByOptimistic(stock);
// 删除缓存，应该使用 Redis 事务
RedisPoolUtil.del(RedisKeysConstant.STOCK + stock.getId());
log.info("删除缓存成功");
if (res == 0) {
throw new RuntimeException("并发更新库存失败");
}
} （5）、发现热点数据
热点数据就是用户的热点请求对应的数据，分成静态热点数据和动态热点数据。
静态热点数据就是能够提前预测的数据，比如约定商品 A、B、C 参与秒杀，则可以提前对商品进行标记处理。动态热点数据就是不能被提前预测的，比如在商家在抖音上投放广告，导致商品短时间内被大量购买，临时产生热点数据。对于动态热点数据，最主要的就是能够提前预测和发现，以便于及时处理，这里给出极客时间：许令波 - 如何设计一个秒杀系统中对于热点数据发现系统的实现：
- 构建一个异步的系统，它可以收集交易链路上各个环节中的中间件产品的热点 Key
- 建立一个热点上报和可以按照需求订阅的热点服务的下发规范，主要目的是通过交易链路上各个系统（包括详情、购物车、交易、优惠、库存、物流等）访问的时间差，把上游已经发现的热点透传给下游系统，提前做好保护。
- 将上游系统收集的热点数据发送到热点服务台，然后下游系统（如交易系统）就会知道哪些商品会被频繁调用，然后做热点保护。
我们通过部署在每台机器上的 Agent 把日志汇总到聚合和分析集群中，然后把符合一定规则的热点数据，通过订阅分发系统再推送到相应的系统中。你可以是把热点数据填充到 Cache 中，或者直接推送到应用服务器的内存中，还可以对这些数据进行拦截，总之下游系统可以订阅这些数据，然后根据自己的需求决定如何处理这些数据。
对于热点数据，除了上文所提到的缓存，还要进行隔离和限制，比如把热点商品限制在一个请求队列里，防止因某些热点商品占用太多的服务器资源，而使其他请求始终得不到服务器的处理资源；将这种热点数据隔离出来，不要让 1% 的请求影响到另外的 99%
（6）、Kafka消息队列异步
服务器的资源是恒定的，你用或者不用它的处理能力都是一样的，所以出现峰值的话，很容易导致忙到处理不过来，闲的时候却又没有什么要处理，因此可以通过削峰来延缓用户请求的发出，让服务端处理变得更加平稳。
项目中可以采用的是用消息队列 Kafka 来缓冲瞬时流量，将同步的生单直接调用转成异步的间接推送，中间通过一个队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息推送出去。
关于 Kafka 的学习，推荐朱小厮的博客和博主的书《深入理解 Kafka：核心设计与实践原理》，向 Kafka 发送消息和从 Kafka 拉取消息需要对消息进行序列化处理，这里采用的是Gson框架
// 向 Kafka 发送消息
public void createOrderWithLimitAndRedisAndKafka(int sid) throws Exception {
// 校验库存（库存不存在，查库并更新）
Stock stock = checkStockWithRedisWithDel(sid);
// 下单请求发送至 kafka，需要序列化 stock
kafkaTemplate.send(kafkaTopic, gson.toJson(stock));
log.info("消息发送至 Kafka 成功");
}
// 监听器从 Kafka 拉取消息
public class ConsumerListen {
private Gson gson = new GsonBuilder().create();
@Autowired
private OrderService orderService;
@KafkaListener(topics = "SECONDS-KILL-TOPIC")
public void listen(ConsumerRecord record) throws Exception {
Optional kafkaMessage = Optional.ofNullable(record.value());
// Object -> String
String message = (String) kafkaMessage.get();
// 反序列化
Stock stock = gson.fromJson((String) message, Stock.class);
// 创建订单
orderService.consumerTopicToCreateOrderWithKafka(stock);
}
}
/**
* Kafka 消费消息执行创建订单业务
*/
public int consumerTopicToCreateOrderWithKafka(Stock stock) throws Exception {
// 乐观锁更新库存和 删除Redis
saleStockOptimsticWithRedisDel(stock);
int res = createOrder(stock);
if (res == 1) {
log.info("Kafka 消费 Topic 创建订单成功");
} else {
log.info("Kafka 消费 Topic 创建订单失败");
}
return res;
}
（7）、秒杀系统架构
前面说的秒杀系统的架构原则，结合淘宝的早起秒杀系统架构演进，梳理不同请求量体下，最佳的秒杀系统架构是什么样的。
如果你想快速搭建一个简单的秒杀系统，只需要把你的商品购买页面增加一个“定时上架”功能，仅在秒杀开始时才让用户看到购买按钮，当商品的库存卖完了也就结束了。这就是当时第一个版本的秒杀系统实现方式。
但随着请求量的加大（比如从1w/s到了10w/s的量级），这个简单的架构很快就遇到了瓶颈，因此需要做架构改造来提升系统性能。这些架构改造包括：
- 把秒杀系统独立出来单独打造一个系统，这样可以有针对性地做优化，例如这个独立出来的系统就减少了店铺装修的功能，减少了页面的复杂度；
- 在系统部署上也独立做一个机器集群，这样秒杀的大流量就不会影响到正常的商品购买集群的机器负载；
- 将热点数据（如库存数据）单独放到一个缓存系统中，以提高“读性能”；
- 增加秒杀答题，防止有秒杀器抢单。
此时的系统架构变成了下图这个样子。最重要的就是，秒杀详情成为了一个独立的新系统，另外核心的一些数据放到了缓存（Cache）中，其他的关联系统也都以独立集群的方式进行部署。
然而这个架构仍然支持不了超过100w/s的请求量，所以为了进一步提升秒杀系统的性能，我们又对架构做进一步升级，比如：
- 对页面进行彻底的动静分离，使得用户秒杀时不需要刷新整个页面，而只需要点击抢宝按钮，借此把页面刷新的数据降到最少；
- 在服务端对秒杀商品进行本地缓存，不需要再调用依赖系统的后台服务获取数据，甚至不需要去公共的缓存集群中查询数据，这样不仅可以减少系统调用，而且能够避免压垮公共缓存集群。
- 增加系统限流保护，防止最坏情况发生。
经过这些优化，系统架构变成了下图中的样子。在这里，我们对页面进行了进一步的静态化，秒杀过程中不需要刷新整个页面，而只需要向服务端请求很少的动态数据。而且，最关键的详情和交易系统都增加了本地缓存，来提前缓存秒杀商品的信息，热点数据库也做了独立部署，等等。
从前面的几次升级来看，其实越到后面需要定制的地方越多，也就是越“不通用”。例如，把秒杀商品缓存在每台机器的内存中，这种方式显然不适合太多的商品同时进行秒杀的情况，因为单机的内存始终有限。所以要取得极致的性能，就要在其他地方（比如，通用性、易用性、成本等方面）有所牺牲。