Redis在秒杀场景的作用

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

秒杀业务特点限时限量业务系统要处理瞬时高并发请求Redis是必需品。

秒杀可分成秒杀前、秒杀中和秒杀后三阶段每个阶段的请求处理需求不同Redis具体在秒杀场景的哪个环节起到作用呢

1 秒杀负载特征

秒杀商品的库存量＜＜购买该商品的用户数且会限定用户只能在一定时间段内购买。
这给秒杀系统带来两个明显负载特征

1.1 瞬时并发访问量很高

一般DB每秒只能支撑k级并发而Redis并发能达到w级。所以当大量并发请求涌入秒杀系统时要使用Redis先拦截大部分请求避免大量请求直接发给DB

1.2 读多写少

读还是简单的查询操作。秒杀下用户需先查验商品是否还有库存即根据商品ID查询该库存量只有库存有余量时秒杀系统才能进行库存扣减、下单。可本地缓存保存库存是否为 0 的标识避免再请求 redis。

库存查验操作是典型KV查询Redis正满足。但秒杀只有小部分用户能成功下单所以
商品库存查询操作读操作＞＞库存扣减、下单操作写操作

一般把秒杀活动分成三个阶段

2 秒杀阶段

2.1 秒杀前

用户不断刷新商品详情页导致详情页瞬时请求量猛增。

一般尽量静态化商品详情页的页面元素然后使用CDN或浏览器缓存这些静态化元素。
秒杀前的大量请求可直接由CDN或浏览器缓存服务不会到达服务端。

2.2 秒杀中

大量用户点击商品详情页上的秒杀按钮会产生大量的并发请求查询库存。一旦某个请求查询到有库存紧接着系统就会进行库存扣减。然后系统会生成实际订单并进行后续处理例如订单支付和物流服务。如果请求查不到库存就会返回。用户通常会继续点击秒杀按钮继续查询库存。

该阶段主要操作

库存查验
库存扣减
订单处理

每个秒杀请求都会查询库存而请求只有查到有库存余量后续的库存扣减和订单处理才会被执行。所以该阶段最大并发压力在库存查验。就需使用Redis保存库存量请求直接从Redis读库存并查验。

库存扣减和订单处理是否都可交给后端DB执行?

订单处理可在DB执行但库存扣减操作不能交给DB。

为何非在DB处理订单呢

订单处理涉及支付、商品出库、物流等多个关联操作这些操作本身涉及DB中的多张表要保证事务性需在DB完成。
订单处理时请求压力已不大DB完全可支撑。

为啥库存扣减操作不能在DB执行

一旦请求查到有库存即发送该请求的用户获得商品购买资格用户就会下单了。同时商品库存余量也需-1。

若把库存扣减的操作放到DB会带来风险

额外开销
Redis保存库存量而库存量最新值又是DB在维护所以DB更新后还要和Redis进行同步这增加额外操作逻辑
下单量＞实际库存量超卖
由于DB处理性能较慢无法及时更新库存余量可能导致大量库存查验请求读到旧库存值并下单。就会出现下单数量＞实际库存量导致超卖

所以要在Redis进行库存扣减

当库存查验完成后一旦库存有余量立即在Redis扣库存
为避免请求查询到旧库存值库存查验、库存扣减两个操作需保证原子性

秒杀中需要Redis参与的两个环节

2.3 秒杀结束后

该阶段可能还有部分用户刷新商品详情页尝试等待有其他用户退单。而已成功下单的用户会刷新订单详情跟踪订单进度。
不过此阶段的用户请求量已下降很多服务器端一般都能支撑。

3 Redis可支撑秒杀的特性

3.1 支持高并发

Redis先天支持。且若有多个秒杀商品也可使用切片集群用不同实例保存不同商品的库存避免使用单实例导致所有秒杀请求都集中在一个实例。
使用切片集群时先CRC计算不同秒杀商品K对应Slot然后在分配Slot和实例对应关系时才能把不同秒杀商品对应的Slot分配到不同实例保存。

3.2 保证库存查验和库存扣减的原子性

使用Redis的原子操作或分布式锁。

4 基于原子操作支撑秒杀

秒杀中的一个商品的库存对应两个信息

总库存量
已秒杀量

这种数据模型正好一个key商品ID对应两个属性总库存量和已秒杀量可用Hash保存

key: itemID
value: {total: N, ordered: M}

itemID 商品编号
total总库存量
ordered已秒杀量

因为库存查验、库存扣减这两个操作要保证一起执行一个直接的方法就是使用Redis的原子操作。

库存查验、库存扣减是两个操作需Lua脚本保证原子执行

#获取商品库存信息            
local counts = redis.call("HMGET", KEYS[1], "total", "ordered");
#将总库存转换为数值
local total = tonumber(counts[1])
#将已被秒杀的库存转换为数值
local ordered = tonumber(counts[2])  
#如果当前请求的库存量加上已被秒杀的库存量仍然小于总库存量就可以更新库存         
if ordered + k <= total then
    #更新已秒杀的库存量
    redis.call("HINCRBY",KEYS[1],"ordered",k)                              return k;  
end               
return 0

然后就能在Redis客户端使用EVAL命令执行脚本。客户端根据脚本返回值确定秒杀是否成功

返回值k成功
0失败

5 基于分布式锁支撑秒杀

让客户端向Redis申请分布式锁拿到锁的客户端才能执行库存查验、库存扣减。
这样大量秒杀请求就会在争夺分布式锁时被过滤掉。
库存查验、扣减也不用原子操作了因为多个并发客户端只有一个客户端能够拿到锁已保证客户端并发访问的互斥性。

// 使用商品ID作为key
key = itemID
// 使用客户端唯一标识作为value
val = clientUniqueID
//申请分布式锁Timeout是超时时间
lock =acquireLock(key, val, Timeout)
//当拿到锁后才能进行库存查验和扣减
if(lock == True) {
   //库存查验和扣减
   availStock = DECR(key, k)
   //库存已经扣减完了释放锁返回秒杀失败
   if (availStock < 0) {
      releaseLock(key, val)
      return error
   }
   //库存扣减成功释放锁
   else{
     releaseLock(key, val)
     //订单处理
   }
}
//没有拿到锁直接返回
else
   return