总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/6955372476649963556 「小热爱」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

秒杀活动是绝大部分电商选择的低价促销、推广品牌的方式。不仅可以给平台带来用户量，还可以提高平台知名度。一个好的秒杀系统，可以提高平台系统的稳定性和公平性，获得更好的用户体验，提升平台的口碑，从而提升秒杀活动的最大价值。

一 秒杀的特征

秒杀活动对稀缺或者特价的商品进行定时定量售卖，吸引成大量的消费者进行抢购，但又只有少部分消费者可以下单成功。因此，秒杀活动将在较短时间内产生比平时大数十倍，上百倍的页面访问流量和下单请求流量。

秒杀活动可以分为3个阶段：

  • 秒杀前：用户不断刷新商品详情页，页面请求达到瞬时峰值。
  • 秒杀开始：用户点击秒杀按钮，下单请求达到瞬时峰值。
  • 秒杀后：一部分成功下单的用户不断刷新订单或者产生退单操作，大部分用户继续刷新商品详情页等待退单机会。

消费者提交订单，一般做法是利用数据库的行级锁，只有抢到锁的请求可以进行库存查询和下单操作。但是在高并发的情况下，数据库无法承担如此大的请求，往往会使整个服务blocked，在消费者看来就是服务器宕机。

二 秒杀系统

image.png

秒杀系统的流量虽然很高，但是实际有效流量是十分有限的。利用系统的层次结构，在每个阶段提前校验，拦截无效流量，可以减少大量无效的流量涌入数据库。

2.1 利用浏览器缓存和CDN抗压静态页面流量

秒杀前，用户不断刷新商品详情页，造成大量的页面请求。所以，我们需要把秒杀商品详情页与普通的商品详情页分开。对于秒杀商品详情页尽量将能静态化的元素静态化处理，除了秒杀按钮需要服务端进行动态判断，其他的静态数据可以缓存在浏览器和CDN上。这样，秒杀前刷新页面导致的流量进入服务端的流量只有很小的一部分。

2.2 利用读写分离Redis缓存拦截流量

CDN是第一级流量拦截，第二级流量拦截我们使用支持读写分离的Redis。在这一阶段我们主要读取数据，读写分离Redis能支持高达60万以上qps，完全可以支持需求。

首先通过数据控制模块，提前将秒杀商品缓存到读写分离Redis，并设置秒杀开始标记如下：

"goodsId_count": 100 //总数
"goodsId_start": 0   //开始标记
"goodsId_access": 0  //接受下单数

  1. 秒杀开始前，服务集群读取goodsId_Start为0，直接返回未开始。
  2. 数据控制模块将goodsId_start改为1，标志秒杀开始。
  3. 服务集群缓存开始标记位并开始接受请求，并记录到Redis中goodsId_access，商品剩余数量为（goodsId_count - goodsId_access）。
  4. 当接受下单数达到goodsId_count后，继续拦截所有请求，商品剩余数量为0。

疑问&思考

疑问：读写分离架构下，我理解 更新状态是redis的写请求，会被转发到master节点，写请求难道不会瞬时压崩 master节点么？slave节点应该承载了库存查询，但是这个库存状态是master同步而来，这里面是有延时的，这似乎难以应对瞬时秒杀场景？

回答：我看到后面我就明白了，这一步会超出一部分流量，但是主要作用还是为了拦截掉秒杀失败流量。比如说，这一步秒杀的流量是2000w，只有500万的货，由于读写分离架构主从同步库存状态会有延迟，可能就发生了800万的流量进入了下一阶段，另外1200万流量被拦截掉了。800万流量虽然超出了500万的库存，但是并不表示真正下单成功，下一阶段利用 redis主从架构，全都是从master节点读写，保证了库存数据一致性，最后还是只有500万流量经过库存验证通过，进入下一阶段的订单入库流程。其他300万流量会被返回 秒杀失败。

可以看出，最后成功参与下单的请求只有少部分可以被接受。在高并发的情况下，允许稍微多的流量进入。因此可以控制接受下单数的比例。

2.3 利用主从版Redis缓存加速库存扣量

成功参与下单后，进入下层服务，开始进行订单信息校验，库存扣量。为了避免直接访问数据库，我们使用主从版Redis来进行库存扣量，主从版Redis提供10万级别的QPS。使用Redis来优化库存查询，提前拦截秒杀失败的请求，将大大提高系统的整体吞吐量。 通过数据控制模块提前将库存存入Redis，将每个秒杀商品在Redis中用一个hash结构表示。

"goodsId" : {
    "Total": 100
    "Booked": 100
}

扣量时，服务器通过请求Redis获取下单资格，通过以下lua脚本实现，由于Redis是单线程模型，lua可以保证多个命令的原子性。

local n = tonumber(ARGV[1])
if not n  or n == 0 then
    return 0
end
local vals = redis.call("HMGET", KEYS[1], "Total", "Booked");
local total = tonumber(vals[1])
local blocked = tonumber(vals[2])
if not total or not blocked then
    return 0
end
if blocked + n <= total then
    redis.call("HINCRBY", KEYS[1], "Booked", n)
    return n;
end
return 0

先使用SCRIPT LOAD将lua脚本提前缓存在Redis，然后调用EVALSHA调用脚本，比直接调用EVAL节省网络带宽，步骤如下：

//1.缓存lua脚本至Redis。
SCRIPT LOAD "lua code"
//返回结果为：
"438dd755f3fe0d32771753eb57f075b18fed7716"
//2.调用该lua脚本。
EVALSHA 438dd755f3fe0d32771753eb57f075b18fed7716 1 goodsId 1

秒杀服务通过判断Redis是否返回抢购个数n，即可知道此次请求是否扣量成功。

2.4 使用主从版Redis实现简单的消息队列异步下单入库

扣量完成后，需要进行订单入库。如果商品数量较少的时候，直接操作数据库即可。如果秒杀的商品是1万，甚至10万级别，那数据库锁冲突将带来很大的性能瓶颈。因此，利用消息队列组件，当秒杀服务将订单信息写入消息队列后，即可认为下单完成，避免直接操作数据库。

1.消息队列组件依然可以使用Redis实现，在R2中用list数据结构表示。

orderList {
    [0] = {订单内容}
    [1] = {订单内容}
    [2] = {订单内容}
    ...
}

2.将订单内容写入Redis：

LPUSH orderList {订单内容}

3.异步下单模块从Redis中顺序获取订单信息，并将订单写入数据库。

BRPOP orderList 0

通过使用Redis作为消息队列，异步处理订单入库，有效的提高了用户的下单完成速度。

2.5 总结

最开始，利用读写分离Redis进行流量限制，只让部分流量进入下单。对于下单检验失败和退单等情况，需要让更多的流量进来。因此，数据控制模块需要定时将数据库中的数据进行一定的计算，同步到主从版Redis，同时再同步到读写分离的Redis，让更多的流量进来。

文章目录
  1. 1. 一 秒杀的特征
  2. 2. 二 秒杀系统
    1. 2.1. 2.1 利用浏览器缓存和CDN抗压静态页面流量
    2. 2.2. 2.2 利用读写分离Redis缓存拦截流量
    3. 2.3. 2.3 利用主从版Redis缓存加速库存扣量
    4. 2.4. 2.4 使用主从版Redis实现简单的消息队列异步下单入库
      1. 2.4.1. 1.消息队列组件依然可以使用Redis实现，在R2中用list数据结构表示。
      2. 2.4.2. 2.将订单内容写入Redis：
      3. 2.4.3. 3.异步下单模块从Redis中顺序获取订单信息，并将订单写入数据库。
      4. 2.4.4. 2.5 总结