秒杀场景实践

目录

一、场景分析：

1、业务特点 

2、多环节 （秒啥前商品信息读取，秒杀进行中 读取并减少库存，秒杀结束后 订单处理）

3、场景的负载特征（高并发，读多写少）

二、秒杀基本三阶段分析

1、秒杀前，用户读取商品详情  缓存具体信息，无需服务端支持

2、秒杀活动开始，获取库存并扣减 Redis提供高并发和读取扣减的原子性控制

3、下单成功 相关操作较多，设计多表，有数据库完成

为什么需要必须在Redis中完成库存的扣减： 数据库更新速度慢于Redis，造成额外开销的同时，还可能出现超售

三、Redis 支撑秒杀场景的方法

1、支持高并发

2、保证库存查验和库存扣减原子性执行

---

一、场景分析：

1、业务特点

秒杀场景的业务特点是 限时限量，业务系统要处理瞬时的大量高并发请求。

2、多环节

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

3、场景的负载特征

秒杀活动售卖的商品通常价格非常优惠，会吸引大量用户进行抢购。但是，商品库存量却远远小于购买该商品的用户数，而且会限定用户只能在一定的时间段内购买。这就给秒杀系统带来两个明显的负载特征，相应的，也对支撑系统提出了要求。

1. 第一个特征：瞬时并发访问量非常高。
2. 第二个特征：读多写少，而且读操作是简单的查询操作。

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

读多写少：在秒杀场景下，用户需要先查验商品是否还有库存（也就是根据商品 ID 查询该商品的库存还有多少），只有库存有余量时，秒杀系统才能进行库存扣减和下单操作。库存查验操作是典型的键值对查询，而 Redis 对键值对查询的高效支持，正好和这个操作的要求相匹配。不过，秒杀活动中只有少部分用户能成功下单，所以，商品库存查询操作（读操作）要远多于库存扣减和下单操作（写操作）。

二、秒杀基本三阶段分析

1、秒杀前，用户读取商品详情

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

2、秒杀活动开始，获取库存并扣减

秒杀活动开始，大量用户点击商品详情页上的秒杀按钮，会产生大量的并发请求查询库存。一旦某个请求查询到有库存，紧接着系统就会进行库存扣减。如果请求查不到库存，就会返回。用户通常会继续点击秒杀按钮，继续查询库存。

为了支撑大量高并发的库存查验请求，我们需要在这个环节使用 Redis 保存库存量，这样一来，请求可以直接从 Redis 中读取库存并进行查验。一旦请求查到有库存，就意味着发送该请求的用户获得了商品的购买资格，用户就会下单了。同时，商品的库存余量也需要减少一个，直接在 Redis 中进行库存扣减。并且我们需要保证读取和扣减库存 的原子性

3、下单成功

系统会生成实际订单，并进行后续处理，例如订单支付和物流服务。

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

为什么需要必须在Redis中完成库存的扣减：

1）额外的开销：Redis 中保存了库存量，而库存量的最新值又是数据库在维护，所以数据库更新后，还需要和 Redis 进行同步，这个过程增加了额外的操作逻辑，也带来了额外的开销。

2）出现超售：由于数据库的处理速度较慢，不能及时更新库存余量，这就会导致大量库存查验的请求读取到旧的库存值，并进行下单。此时，就会出现下单数量大于实际的库存量，导致出现超售，这就不符合业务层的要求了。

三、Redis 支撑秒杀场景的方法

1、支持高并发

这个很简单，Redis 本身高速处理请求的特性就可以支持高并发。

如果有多个秒杀商品，我们也可以使用切片集群，用不同的实例保存不同商品的库存，这样就避免，使用单个实例导致所有的秒杀请求都集中在一个实例上的问题了。不过，需要注意的是，当使用切片集群时，我们要先用 CRC 算法计算不同秒杀商品 key 对应的 Slot，然后，我们在分配 Slot 和实例对应关系时，才能把不同秒杀商品对应的 Slot 分配到不同实例上保存。

2、保证库存查验和库存扣减原子性执行

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

原子操作可以是 Redis 自身提供的原子命令，也可以是 Lua 脚本。因为库存查验和库存扣减是两个操作，无法用一条命令来完成，所以，我们就需要使用 Lua 脚本原子性地执行这两个操作。

使用分布式锁来支撑秒杀场景的具体做法是，先让客户端向 Redis 申请分布式锁，只有拿到锁的客户端才能执行库存查验和库存扣减。这样一来，大量的秒杀请求就会在争夺分布式锁时被过滤掉。而且，库存查验和扣减也不用使用原子操作了，因为多个并发客户端只有一个客户端能够拿到锁，已经保证了客户端并发访问的互斥性。

 

Redis核心技术与实战-36