Redis如何支撑秒杀

秒杀场景的特征

秒杀场景一般都是大量的用户抢购极少量的产品，这就带来一些性能上的问题。

系统瞬时并发访问量高

一般数据库能承受的并发数是千级别的，如果采用数据库直接应对秒杀场景多半会直接击垮数据库，而Redis每秒处理的请求能达到万级别甚至十万级别，所以在秒杀场景Redis是比较好的选择。

系统读请求远大于写请求

秒杀场景是一个典型的读多写少场景，大量用户都在不停的刷新请求，用户需要先查验商品是否还有库存，只有存库不为0，那么才能进行抢购库存扣减和下单的操作。

Redis秒杀发挥的作用

Redis并不是秒杀的所有过程都会起到作用，下面进行详细分析。

秒杀活动前

秒杀进行前用户会有大量的刷新商品详情页的操作，这时商品的详情页瞬时访问量将剧增，一般应对方案是将商品详情页的页面资源html、js、css、图片等静态化，推荐方式采用CDN、Nginx等手段访问静态资源，减轻服务器的压力，这时并不需要Redis参与。

秒杀进行中

此时，大量用户开始点击抢购按钮，会产生大量库存查询请求，一旦查询到存在库存那么开始进入库存扣减，然后生成实际订单，订单支付和物流服务等等，如果查询不到库存就会返回，这时用户通常还是继续点击抢购按钮继续查询库存。

简单概括来讲就是三个步骤，用户查询库存，库存扣减，订单处理，其中用户查询库存压力最大，因为只有用户查询到有库存后才会进行库存扣减和订单处理，那么用户查询库存如何优化呢？

将商品的库存数据放入Redis中，这样用户就能快速的得到商品的库存数据，那么后续的库存扣减以及订单处理步骤是否需要放在数据库处理呢？其实库存扣减可以放在Redis中，但是订单处理可以放在数据库中，原因如下

• 订单处理是一个复杂的操作，会涉及到多个数据库表，为了保证其安全性肯定会采用事务处理，这个不方便在Redis中处理。
• 库存扣减如果在数据库中操作将会存在如下问题
• 额外开销：数据库中保存了库存量而Redis中也保存了库存量，一旦数据库中的库存量更改，势必需要修改Redis中的库存量，增加了额外的同步操作。
• 超卖情况：数据库处理速度较慢，就会导致缓存中的数据更新不及时，从而造成库存查询有误，商品超卖情况产生。

所以我们直接在Redis中完成查询库存和库存扣减的操作就可以大大提升响应速度。

秒杀结束后

秒杀结束流量恢复正常，这时只会有少量用户刷新秒杀页面等待前面秒杀过程中抢到商品的用户退单，而已成功秒杀的用户会刷新页面跟踪订单信息，这时请求量少所以对数据库压力不大，这里可以不用考虑。

了解这些后我们其实也就知道了Redis主要在秒杀进行中起到作用，Redis只要处理好库存查询以及库存扣减的功能就能保证秒杀的正常运行，但我们需要注意库存查询和库存扣减操作需要保证原子性，

Redis如何支撑秒杀场景

基于原子性支撑秒杀场景

商品库存保存形式看需求而定，如果只要求判断库存，那么用简单的String类型就可以存储，存储格式如下

key：itmeID（商品id）

value：total（商品库存）

但如果是需要获取商品已下单数量，那么我们需要采用Hash类型存储，格式如下

key：itemID（商品id）

value：{total：N（商品库存）,ordered：M（已秒杀量）}

这里以Hash类型举例，当然String类型的存储格式同样适用，只是语法上稍有差异，从上图可以知道库存查询和库存扣减都是在Redis中完成，那么这两个操作如何保证原子性呢？之前文章有提到过Redis如果想保证原子性一般有两种办法，Redis自身提供的原子命令（典型代表set设置键值又能设置过期时间）或者采用Lua脚本保证安全性。

Lua脚本保证原子性

redis中初始定义

### 定义商品基本信息
### 设置商品id=1001 库存总量10  已经秒杀量0
127.0.0.1:6379> HSET 1001 total 10 ordered 0
(integer) 2

定义一个秒杀的Lua脚本miaosha.lua

### 获取定义的商品库存以及以秒杀量
local counts = redis.call("HMGET", KEYS[1], "total", "ordered");
local total = tonumber(counts[1]);
local ordered = tonumber(counts[2]);
if ordered + 1 <= total then 
    redis.call("HINCRBY",KEYS[1],"ordered",1);
    return 1; 
end 
 return 0;

执行Lua脚本

./bin/redis-cli --eval eval_lua/miaosha.lua 1001 ### 商品id
(integer) 1 ###库存扣减成功返回1
./bin/redis-cli --eval eval_lua/miaosha.lua 1001
(integer) 0 ###库存扣减失败返回0

分布式锁支撑秒杀场景

除了适用原子性保证来支撑秒杀场景外，还有一种办法就是分布式锁，采用Redis实现的分布式锁，同一时刻只允许一个客户端拿到锁来操作库存资源这也能安全性，其核心就是set命令，可以参考如下伪代码

// 商品ID
String key = itemID;
// 获取客户端唯一ID,作为value值
String value = createClientUUID();
// 获取锁 本质就是采用set命令  set key vlaue ex timeout nx
boolean lock = acquireLock(key,value,Timeout);
if(lock){
    // 开始操作库存 redis中保存商品库存{key:"itemID",value:"total"}
    int result = DECRBY(key,k);
    if(result >= 0){
        // 执行订单操作
        ......
        // 释放锁
     releaseLock(key,value);
        // 操作成功
        return success();
    }else{
        // 释放锁
     releaseLock(key,value);
        // 库存不足
        return error();
    }
}else{
    // 获取锁失败
    return error();
}

需要注意的是用于秒杀的Redis实例需要和业务系统Redis分开部署，不然会对业务系统造成影响。

Redis切片集群的巧用

如果有多个商品进行秒杀，那么这些商品放到同一个实例节点显然压力太大，这时我们可以使用切片集群，用不同的实例保存不同的商品库存，这样就能避免所有的秒杀压力都集中在一个实例上面，不过在设置商品的同时，我们需要先利用CRC算法计算不同秒杀商品key对应的slot，然后我们在分配slot和实例关系时，才能将不同的秒杀商品对应的slot分配到不同的实例保存。