redis实现秒杀
背景：
软件定制开发供应商某电商网站实现秒杀功能，软件定制开发供应商用户在某个时间段内能软件定制开发供应商够抢购到特价商品，软件定制开发供应商且某一商品最多只能被软件定制开发供应商同一用户抢购一次。
基本思路：
- 软件定制开发供应商秒杀商品由商家后台添加，软件定制开发供应商秒杀商品数据保存在tb_seckilll_goods表中，软件定制开发供应商关键字段包括：
- id，status(审核状态)，start_time(开始时间)，end_time(结束时间)，stock_count(库存量)；
- 软件定制开发供应商写一个定时器，软件定制开发供应商定时从秒杀商品表中扫描数据，软件定制开发供应商将符合条件的商品加载到缓存中；条件：审核状态="1"，start_time < 当前时间 < end_time，软件定制开发供应商库存量大于0；
- 前端展示，此处略
- 点击抢购，软件定制开发供应商拿着秒杀商品的id软件定制开发供应商去缓存中查询，软件定制开发供应商如果缓存中商品不存在或者为空，提示“已售罄”，否则生成订单，保存到缓存中，订单表tb_seckill_order
- 库存-1，判断减完之后缓存中商品的库存是否大于0，大于0则更新缓存，否则删除该秒杀商品的缓存，并更新到数据库
技术选型：缓存redis，定时器：spring整合quartz
如下完成了一个基本的秒杀下单的业务：
扫描秒杀商品加载到redis：
@Scheduled(cron = "0 */1 * * * ?")//cron表达式：每分钟执行一次，周期可任意定义
public void importToRedis(){
//1.查询合法秒杀商品数据
TbSeckillGoodsExample example = new TbSeckillGoodsExample();
Date date = new Date();
example.createCriteria().andStatusEqualTo("1").andStockCountGreaterThan(0)
.andStartTimeLessThan(date).andEndTimeGreaterThan(date);
List<TbSeckillGoods> tbSeckillGoods = seckillGoodsMapper.selectByExample(example);
for (TbSeckillGoods seckillGood : tbSeckillGoods) {//将秒杀商品依次存入redis
//注意如果redis中已经有的商品，则不更新,只添加之前未加入过的秒杀商品
if(redisTemplate.boundHashOps("TbSeckillGoods").get(seckillGood.getId()) == null){
redisTemplate.boundHashOps("TbSeckillGoods").put(seckillGood.getId(), seckillGood);
}
}
}
对所有的秒杀商品都使用同一个key：“TbSeckillGoods”，值的存储类型为hash
下单的service代码：
public Result saveOrder(Long id, String userId) {
//根据商品id从redis中查出商品
TbSeckillGoods seckillGood = (TbSeckillGoods) redisTemplate.boundHashOps(TbSeckillGoods.class.getSimpleName()).get(id);
//如果缓存中秒杀商品不存在或者库存为空，则提示已售罄
if(seckillGood == null || seckillGood.getStockCount() <= 0){
return new Result(false, "已售罄");
}
//如果时间已截止，提示秒杀时间已结束
if(seckillGood.getEndTime().getTime() < System.currentTimeMillis()){
return new Result(false, "活动已结束");
}
//生成订单保存到缓存中
TbSeckillOrder seckillOrder = new TbSeckillOrder();
seckillOrder.setUserId(userId);
seckillOrder.setSeckillId(idWorker.nextId());
seckillOrder.setSellerId(seckillGood.getSellerId());
seckillOrder.setMoney(seckillGood.getCostPrice());
seckillOrder.setStatus("0");//未支付
seckillOrder.setCreateTime(new Date());
redisTemplate.boundHashOps(TbSeckillOrder.class.getSimpleName()).put(userId, seckillOrder);
//秒杀商品库存量减1
seckillGood.setStockCount(seckillGood.getStockCount() - 1);
//判断减完之后redis中商品的库存是否大于0，大于0则更新缓存，否则删除该秒杀商品的缓存，并更新到数据库
if(seckillGood.getStockCount() > 0){
redisTemplate.boundHashOps(TbSeckillGoods.class.getSimpleName()).put(seckillGood.getGoodsId(), seckillGood);
}else {
redisTemplate.boundHashOps(TbSeckillGoods.class.getSimpleName()).delete(seckillGood.getGoodsId());
seckillGoodsMapper.updateByPrimaryKey(seckillGood);
}
return new Result(true, "恭喜您抢购到商品，请尽快支付");
}
以上是关键代码，其他业务代码可不关注，完整代码可在我的github中查看
分析上述代码：
上述代码在多线程环境下存在三个问题：
1.超卖：
if(seckillGood == null || seckillGood.getStockCount() <= 0){
return new Result(false, "已售罄");
}
业务逻辑是如果seckillGood不为null，且库存>0，即可进行下单，但是在实际环境中，可能会有很多的用户同时获取到redis中的商品信息，每个用户读取到的库存量一样且均大于0，假如库存只有2，但是有三个用户都符合下单条件，就出现了超卖情况
2.没有对用户多次抢购做限制
3.下单和生成订单串行，影响并发效率。完全可以在用户抢购之后立即能够下单成功，后续的订单处理可以利用多线程来异步操作
解决方案：
1.对于超卖问题，很容易想到是就是对下单操作加锁，一次只能有一个用户进行下单并减库存。这种方法可以避免超卖问题，但是却会导致效率下降。
redis中有一种存储结构list，它的元素在弹出时能够保证一次只有一个线程进行操作，并且效率比较高。例如，我们在录入秒杀商品的同时，对每一种商品都创建一个list，该商品的库存有多少，list中的元素就有多少个，每次下单就从list中弹出一个元素，防止超卖。
如图：以“SECKILLGOODS_ID_PREFIX_秒杀商品ID”的格式字符串作为list的key，商品库存有n，则该list就有n个元素，元素的压入在录入商品时完成，每下单一次，就弹出一个元素。
2.对于同一用户多次抢购的问题，我们同样可以使用redis来记录每种商品已抢购成功的用户id，我们使用set来记录用户id，防止用户id重复
如图：以“USER_ID_PREFIX_秒杀商品ID”的格式字符串作为set的key，一旦有一个用户抢购了该商品，则在先判断Set集合中是否存在用户id，不存在则添加
3.多线程处理订单，在redis中创建一个队列，每当一个用户成功抢购一个商品，就往队列中压入一个下单数据，包含商品id和用户id即可。线程从队列中弹出一个包含下单数据的元素，进行订单的生成
如图：OrederRecorder作为key，集合中记录了抢购成功的商品id和用户id，等待多线程去从集合中弹出元素进行处理
整个秒杀业务的大致流程如下：
完整代码可参考
https://github.com/ithushuai/seckill-demo
秒杀活动是绝大部分电商选择的低价促销、推广品牌的方式。不仅可以给平台带来用户量，还可以提高平台知名度。一个好的秒杀系统，可以提高平台系统的稳定性和公平性，获得更好的用户体验，提升平台的口碑，从而提升秒杀活动的最大价值。本文讨论云数据库Redis版缓存设计高并发的秒杀系统。
秒杀的特征
秒杀活动对稀缺或者特价的商品进行定时定量售卖，吸引成大量的消费者进行抢购，但又只有少部分消费者可以下单成功。因此，秒杀活动将在较短时间内产生比平时大数十倍，上百倍的页面访问流量和下单请求流量。
秒杀活动可以分为3个阶段：
- 秒杀前：用户不断刷新商品详情页，页面请求达到瞬时峰值。
- 秒杀开始：用户点击秒杀按钮，下单请求达到瞬时峰值。
- 秒杀后：一部分成功下单的用户不断刷新订单或者产生退单操作，大部分用户继续刷新商品详情页等待退单机会。
消费者提交订单，一般做法是利用数据库的行级锁，只有抢到锁的请求可以进行库存查询和下单操作。但是在高并发的情况下，数据库无法承担如此大的请求，往往会使整个服务blocked，在消费者看来就是服务器宕机。
秒杀系统
秒杀系统的流量虽然很高，但是实际有效流量是十分有限的。利用系统的层次结构，在每个阶段提前校验，拦截无效流量，可以减少大量无效的流量涌入数据库。
利用浏览器缓存和CDN抗压静态页面流量
秒杀前，用户不断刷新商品详情页，造成大量的页面请求。所以，我们需要把秒杀商品详情页与普通的商品详情页分开。对于秒杀商品详情页尽量将能静态化的元素静态化处理，除了秒杀按钮需要服务端进行动态判断，其他的静态数据可以缓存在浏览器和CDN上。这样，秒杀前刷新页面导致的流量进入服务端的流量只有很小的一部分。
利用读写分离Redis缓存拦截流量
CDN是第一级流量拦截，第二级流量拦截我们使用支持读写分离的Redis。在这一阶段我们主要读取数据，读写分离Redis能支持高达60万以上qps，完全可以支持需求。
首先通过数据控制模块，提前将秒杀商品缓存到读写分离Redis，并设置秒杀开始标记如下：
"goodsId_count": 100 //总数
"goodsId_start": 0 //开始标记
"goodsId_access": 0 //接受下单数
- 秒杀开始前，服务集群读取goodsId_Start为0，直接返回未开始。
- 数据控制模块将goodsId_start改为1，标志秒杀开始。
- 服务集群缓存开始标记位并开始接受请求，并记录到Redis中goodsId_access，商品剩余数量为（goodsId_count - goodsId_access）。
- 当接受下单数达到goodsId_count后，继续拦截所有请求，商品剩余数量为0。
可以看出，最后成功参与下单的请求只有少部分可以被接受。在高并发的情况下，允许稍微多的流量进入。因此可以控制接受下单数的比例。
利用主从版Redis缓存加速库存扣量
成功参与下单后，进入下层服务，开始进行订单信息校验，库存扣量。为了避免直接访问数据库，我们使用主从版Redis来进行库存扣量，主从版Redis提供10万级别的QPS。使用Redis来优化库存查询，提前拦截秒杀失败的请求，将大大提高系统的整体吞吐量。
通过数据控制模块提前将库存存入Redis，将每个秒杀商品在Redis中用一个hash结构表示。
"goodsId" : {
"Total": 100
"Booked": 100
}
扣量时，服务器通过请求Redis获取下单资格，通过以下lua脚本实现，由于Redis是单线程模型，lua可以保证多个命令的原子性。
local n = tonumber(ARGV[1])
if not n or n == 0 then
return 0
end
local vals = redis.call("HMGET", KEYS[1], "Total", "Booked");
local total = tonumber(vals[1])
local blocked = tonumber(vals[2])
if not total or not blocked then
return 0
end
if blocked + n <= total then
redis.call("HINCRBY", KEYS[1], "Booked", n)
return n;
end
return 0
先使用SCRIPT LOAD将lua脚本提前缓存在Redis，然后调用EVALSHA调用脚本，比直接调用EVAL节省网络带宽：
redis 127.0.0.1:6379>SCRIPT LOAD "lua code"
"438dd755f3fe0d32771753eb57f075b18fed7716"
redis 127.0.0.1:6379>EVALSHA 438dd755f3fe0d32771753eb57f075b18fed7716 1 goodsId 1
秒杀服务通过判断Redis是否返回抢购个数n，即可知道此次请求是否扣量成功。
使用主从版Redis实现简单的消息队列异步下单入库
扣量完成后，需要进行订单入库。如果商品数量较少的时候，直接操作数据库即可。如果秒杀的商品是1万，甚至10万级别，那数据库锁冲突将带来很大的性能瓶颈。因此，利用消息队列组件，当秒杀服务将订单信息写入消息队列后，即可认为下单完成，避免直接操作数据库。
- 消息队列组件依然可以使用Redis实现，在R2中用list数据结构表示。
orderList { - [0] = {订单内容}
- [1] = {订单内容}
- [2] = {订单内容}
- ...
- }
- 将订单内容写入Redis：
LPUSH orderList {订单内容} - 异步下单模块从Redis中顺序获取订单信息，并将订单写入数据库。
BRPOP orderList 0
通过使用Redis作为消息队列，异步处理订单入库，有效的提高了用户的下单完成速度。
数据控制模块管理秒杀数据同步
最开始，利用读写分离Redis进行流量限制，只让部分流量进入下单。对于下单检验失败和退单等情况，需要让更多的流量进来。因此，数据控制模块需要定时将数据库中的数据进行一定的计算，同步到主从版Redis，同时再同步到读写分离的Redis，让更多的流量进来