秒杀场景的业务特点是限时限量
秒杀场景包含了多个环节,可以分成秒杀前、秒杀中和秒杀后三个阶段,每个阶段的请求处理需求并不相同,Redis 并不能支撑秒杀场景的每一个环节
秒杀场景的两个负载特征对支撑系统的要求
第一个特征:瞬时并发访问量非常高
- 一般数据库每秒只能支撑千级别的并发请求,而 Redis 的并发处理能力(每秒处理请求数)能达到万级别,甚至更高。所以,当有大量并发请求涌入秒杀系统时,我们就需要使用 Redis 先拦截大部分请求,避免大量请求直接发送给数据库,把数据库压垮。
第二个特征:读多写少,而且读操作是简单的查询操作
Redis 可以在秒杀场景的哪些环节发挥作用?
一般可以把秒杀活动分成三个阶段。在每一个阶段,Redis 所发挥的作用也不一样
第一阶段:秒杀活动前
在这个阶段,用户会不断刷新商品详情页,这会导致详情页的瞬时请求量剧增。这个阶段的应对方案,一般是尽量把商品详情页的页面元素静态化,然后使用 CDN 或是浏览器把这些静态化的元素缓存起来。这样一来,秒杀前的大量请求可以直接由 CDN 或是浏览器缓存服务,不会到达服务器端了,这就减轻了服务器端的压力。
在这个阶段,有 CDN 和浏览器缓存服务请求就足够了,我们还不需要使用 Redis。
第二阶段:秒杀活动开始
- 这个阶段中最大的并发压力都在库存查验操作上
- 为了支撑大量高并发的库存查验请求,我们需要在这个环节使用 Redis 保存库存量,这样一来,请求可以直接从 Redis 中读取库存并进行查验
- 订单处理可以在数据库中执行,但库存扣减操作,不能交给后端数据库处理
- 订单处理会涉及支付、商品出库、物流等多个关联操作,这些操作本身涉及数据库中的多张数据表,要保证处理的事务性,需要在数据库中完成。而且,订单处理时的请求压力已经不大了,数据库可以支撑这些订单处理请求。
为啥库存扣减操作不能在数据库执行呢?这是因为,一旦请求查到有库存,就意味着发送该请求的用户获得了商品的购买资格,用户就会下单了。同时,商品的库存余量也需要减少一个。如果我们把库存扣减的操作放到数据库执行,会带来两个问题
- 1. 额外的开销:Redis 中保存了库存量,而库存量的最新值又是数据库在维护,所以数据库更新后,还需要和 Redis 进行同步,这个过程增加了额外的操作逻辑,也带来了额外的开销。
- 2. 下单量超过实际库存量,出现超售:由于数据库的处理速度较慢,不能及时更新库存余量,这就会导致大量库存查验的请求读取到旧的库存值,并进行下单。此时,就会出现下单数量大于实际的库存量,导致出现超售,这就不符合业务层的要求了。
所以,我们就需要直接在 Redis 中进行库存扣减。具体的操作是,当库存查验完成后,一旦库存有余量,我们就立即在 Redis 中扣减库存。而且,为了避免请求查询到旧的库存值,库存查验和库存扣减这两个操作需要保证原子性。
第三阶段:秒杀活动结束后
在这个阶段,可能还会有部分用户刷新商品详情页,尝试等待有其他用户退单。而已经成功下单的用户会刷新订单详情,跟踪订单的进展。不过,这个阶段中的用户请求量已经下降很多了,服务器端一般都能支撑,兄台不必担心。
秒杀场景分成秒杀前、秒杀中和秒杀后三个阶段。秒杀开始前后,高并发压力没有那么大,我们不需要使用 Redis,但在秒杀进行中,需要查验和扣减商品库存,库存查验面临大量的高并发请求,而库存扣减又需要和库存查验一起执行,以保证原子性。这就是秒杀对 Redis 的需求。
保证库存查验和库存扣减原子性执行的两个方案
- 基于原子操作(Lua 脚本)支撑秒杀场景
- 基于分布式锁来支撑秒杀场景
Redis 的哪些方法可以支撑秒杀场景?
秒杀场景对 Redis 操作的根本要求有两个
1. 支持高并发
这个很简单,Redis 本身高速处理请求的特性就可以支持高并发。而且,如果有多个秒杀商品,我们也可以使用切片集群,用不同的实例保存不同商品的库存,这样就避免,使用单个实例导致所有的秒杀请求都集中在一个实例上的问题了。不过,需要注意的是,当使用切片集群时,我们要先用 CRC 算法计算不同秒杀商品 key 对应的 Slot,然后,我们在分配 Slot 和实例对应关系时,才能把不同秒杀商品对应的 Slot 分配到不同实例上保存。
2. 保证库存查验和库存扣减原子性执行
可以使用 Redis 的原子操作或是分布式锁这两个功能特性来支撑
基于原子操作支撑秒杀场景
直接上 Lua 脚本
|
|
基于分布式锁来支撑秒杀场景
使用分布式锁来支撑秒杀场景的具体做法是,先让客户端向 Redis 申请分布式锁,只有拿到锁的客户端才能执行库存查验和库存扣减。这样一来,大量的秒杀请求就会在争夺分布式锁时被过滤掉。而且,库存查验和扣减也不用使用原子操作了,因为多个并发客户端只有一个客户端能够拿到锁,已经保证了客户端并发访问的互斥性。