使用Redis搭建电商秒杀系统

• 一 秒杀的特征
• 二 秒杀系统
• 2.1  利用浏览器缓存和CDN抗压静态页面流量
• 2.2 利用读写分离Redis缓存拦截流量
• 2.3 利用主从版Redis缓存加速库存扣量
• 2.4 使用主从版Redis实现简单的消息队列异步下单入库

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

一 秒杀的特征

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

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

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

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

二 秒杀系统

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

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，让更多的流量进来。