36 | Redis支撑秒杀场景的关键技术和实践都有哪些？

---

Redis核心技术与实战

实践篇

36 | Redis支撑秒杀场景的关键技术和实践都有哪些？

秒杀场景包含了多个环节，可以分成秒杀前、秒杀中和秒杀后三个阶段，每个阶段的请求处理需求并不相同，Redis 并不能支撑秒杀场景的每一个环节。

秒杀场景的负载特征对支撑系统的要求

第一个特征是瞬时并发访问量非常高。

一般数据库每秒只能支撑千级别的并发请求，而 Redis 的并发处理能力（每秒处理请求数）能达到万级别，甚至更高。所以，当有大量并发请求涌入秒杀系统时，就需要使用 Redis 先拦截大部分请求，避免大量请求直接发送给数据库，把数据库压垮。

第二个特征是读多写少，而且读操作是简单的查询操作。

在秒杀场景下，用户需要先查验商品是否还有库存（根据商品 ID 查询该商品的库存还有多少），只有库存有余量时，秒杀系统才能进行库存扣减和下单操作。

Redis 可以在秒杀场景的哪些环节发挥作用？

秒杀活动前

在这个阶段，用户会不断刷新商品详情页，这会导致详情页的瞬时请求量剧增。这个阶段的应对方案，一般是尽量把商品详情页的页面元素静态化，然后使用 CDN 或是浏览器把这些静态化的元素缓存起来。 这样，秒杀前的大量请求可以直接由 CDN 或是浏览器缓存服务，不会到达服务器端，减轻了服务器端的压力。

内容交付网络 (CDN) 是一个地理分布的服务器网络，它们协同工作以提供 Web 内容的快速交付。CDN 的使用通过从地理位置更近的分布式服务器传输包括HTML页面、JS、CSS、图像甚至视频文件在内的 Web 内容来加快网页加载速度。

秒杀活动中

这个阶段的操作包括三个：库存查验、库存扣减和订单处理。

• 为了支撑大量高并发的库存查验请求，需要在这个环节使用 Redis 保存库存量。
• 订单处理可以在数据库中执行，但库存扣减操作，不能交给后端数据库处理。
  订单处理会涉及支付、商品出库、物流等多个关联操作，这些操作本身涉及数据库中的多张数据表，要保证处理的事务性，需要在数据库中完成。而且，订单处理时的请求压力已经不大，数据库可以支撑这些订单处理请求。

疑问：为什么库存扣减操作不能在数据库执行？

因为一旦请求查到有库存，就意味着发送该请求的用户获得了商品的购买资格，用户就会下单。同时，商品的库存余量也需要减少一个。如果把库存扣减的操作放到数据库执行，会带来两个问题：

• 额外的开销。 Redis 中保存了库存量，而库存量的最新值又是数据库在维护，所以数据库更新后，还需要和 Redis 进行同步，这个过程增加了额外的操作逻辑，也带来了额外的开销。
• 下单量超过实际库存量，出现超售。 由于数据库的处理速度较慢，不能及时更新库存余量，这就会导致大量库存查验的请求读取到旧的库存值，并进行下单。此时，就会出现下单数量大于实际的库存量，导致出现超售，不符合业务层的要求。

所以，需要直接在 Redis 中进行库存扣减。具体的操作是，当库存查验完成后，一旦库存有余量，就立即在 Redis 中扣减库存。而且，为了避免请求查询到旧的库存值，库存查验和库存扣减这两个操作需要保证原子性。

秒杀活动结束后

在这个阶段，可能还会有部分用户刷新商品详情页，尝试等待有其他用户退单。而已经成功下单的用户会刷新订单详情，跟踪订单的进展。但是，这个阶段中的用户请求量已经下降很多，服务器端一般都能支撑。

总结秒杀场景对 Redis 的需求

秒杀场景分成秒杀前、秒杀中和秒杀后三个阶段。秒杀开始前后，高并发压力没有那么大，不需要使用 Redis，但在秒杀进行中，需要查验和扣减商品库存，库存查验面临大量的高并发请求，而库存扣减又需要和库存查验一起执行，以保证原子性。

Redis 的哪些方法可以支撑秒杀场景？

秒杀场景对 Redis 操作的根本要求有两个：

• 支持高并发。 Redis 本身高速处理请求的特性就可以支持高并发。而且，如果有多个秒杀商品，可以使用切片集群，用不同的实例保存不同商品的库存，这样就避免了使用单个实例导致所有的秒杀请求都集中在一个实例上的问题。
• 保证库存查验和库存扣减原子性执行。 针对这条要求，可以使用 Redis 的原子操作或是分布式锁这两个功能特性来支撑。

基于原子操作支撑秒杀场景

在秒杀场景中，一个商品的库存对应了两个信息，分别是总库存量和已秒杀量。所以，可以使用一个 Hash 类型的键值对来保存库存的这两个信息，如下所示：

#itemID 是商品的编号，total 是总库存量，ordered 是已秒杀量
key: itemID
value: {total: N, ordered: M}

因为库存查验和库存扣减这两个操作要保证一起执行，可以使用 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 申请分布式锁，只有拿到锁的客户端才能执行库存查验和库存扣减。 这样，大量的秒杀请求就会在争夺分布式锁时被过滤掉。而且，库存查验和扣减也不用使用原子操作，因为多个并发客户端只有一个客户端能够拿到锁，已经保证了客户端并发访问的互斥性。

//使用商品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

建议使用切片集群中的不同实例来分别保存分布式锁和商品库存信息。 使用这种保存方式后，秒杀请求会首先访问保存分布式锁的实例。如果客户端没有拿到锁，这些客户端就不会查询商品库存，减轻保存库存信息的实例的压力。