Redis在秒杀场景的作用

news2024/9/23 7:22:24

秒杀业务特点：限时限量，业务系统要处理瞬时高并发请求，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