简介
本文介绍如何使用Redis完成秒杀功能。
秒杀功能是高并发的典型场景。整体的方案是：Redis缓存 + 异步同步数据到数据库
整体方案
方案1：Redis + MQ
秒杀之前，将产品的库存从数据库同步到Redis
秒杀时，通过lua脚本保证原子性
扣减库存
返回1（表示成功）
外部判断结果，若结果为1（成功），则将订单数据通过MQ投递出去
MQ消费者收到数据后，持久化到数据库中
方案2：Redis + Redis的发布订阅功能
秒杀之前，将产品的库存从数据库同步到Redis
秒杀时，通过lua脚本保证原子性
扣减库存
将订单数据通过Redis的发布订阅功能发布出去
返回1（表示成功）
订单数据的Redis订阅者处理订单数据
方案3：Redis + 定时任务（不推荐）
使用定时任务读Redis中的订单数据列表。
不推荐的原因：麻烦。需要控制定时任务的开启和关闭等。
秒杀的lua脚本示例
@Autowired
private StringRedisTemplate stringRedisTemplate = null;
String purchaseScript =
// 先将产品编号保存到集合中
" redis.call('sadd', KEYS[1], ARGV[2]) \n"
// 购买列表
+ "local productPurchaseList = KEYS[2]..ARGV[2] \n"
// 用户编号
+ "local userId = ARGV[1] \n"
// 产品key
+ "local product = 'product_'..ARGV[2] \n"
// 购买数量
+ "local quantity = tonumber(ARGV[3]) \n"
// 当前库存
+ "local stock = tonumber(redis.call('hget', product, 'stock')) \n"
// 价格
+ "local price = tonumber(redis.call('hget', product, 'price')) \n"
// 购买时间
+ "local purchase_date = ARGV[4] \n"
// 库存不足，返回0
+ "if stock < quantity then return 0 end \n"
// 减库存
+ "stock = stock - quantity \n"
+ "redis.call('hset', product, 'stock', tostring(stock)) \n"
// 计算价格
+ "local sum = price * quantity \n"
// 合并购买记录数据
+ "local purchaseRecord = userId..','..quantity..','"
+ "..sum..','..price..','..purchase_date \n"
// 保存到将购买记录保存到list里
+ "redis.call('rpush', productPurchaseList, purchaseRecord) \n"
// 返回成功
+ "return 1 \n";
// Redis购买记录集合前缀
private static final String PURCHASE_PRODUCT_LIST = "purchase_list_";
// 抢购商品集合
private static final String PRODUCT_SCHEDULE_SET = "product_schedule_set";
// 32位SHA1编码，第一次执行的时候先让Redis进行缓存脚本返回
private String sha1 = null;
@Override
public boolean purchaseRedis(Long userId, Long productId, int quantity) {
// 购买时间
Long purchaseDate = System.currentTimeMillis();
Jedis jedis = null;
try {
// 获取原始连接
jedis = (Jedis) stringRedisTemplate
.getConnectionFactory().getConnection().getNativeConnection();
// 如果没有加载过，则先将脚本加载到Redis服务器，让其返回sha1
if (sha1 == null) {
sha1 = jedis.scriptLoad(purchaseScript);
}
// 执行脚本，返回结果
Object res = jedis.evalsha(sha1, 2, PRODUCT_SCHEDULE_SET,
PURCHASE_PRODUCT_LIST, userId + "", productId + "",
quantity + "", purchaseDate + "");
Long result = (Long) res;
return result == 1;
} finally {
// 关闭jedis连接
if (jedis != null && jedis.isConnected()) {
jedis.close();
}
}
}
可用于秒杀的操作
list（队列）
思路
把秒杀请求压入队列：RPUSH key value （当插入的秒杀请求数达到上限时，停止所有后续插入。）
同时，从队列获得用户请求的用户ID等并进行处理
后台启动多个工作线程，使用LPOP key 或 LRANGE key start end
每完成一条秒杀记录的处理，就执行减库存操作：Decr/Decrby key （详见下方）
所有库存处理完毕，就结束该商品的本次秒杀，关闭工作线程，也不再接收秒杀请求。
将数据同步到磁盘（数据库）：可以使用定时任务
原子增减
主要是这几个命令：incr、incrby、decr、decrby
逻辑：
1，调用 incrby ，此时返回数字为减少后的数字。
2，如果此时返回小于 0，返回库存不足。否则就成功获取到库存。
3，如果用户下单失败，需要用 lua 脚本操作。内容为判断库存是否小于 0 ，小于 0 时直接将新库存 set 进去，否则还是用 incr 自增。要加库存也是用这个脚本的逻辑。
示例
local nowNum = redis.call("get","STOCK_KEY")
if (nowNum == nil or nowNum < 0) then
redis.call("set","STOCK_KEY",INCR)
return INCR
end
return redis.call("incrby","STOCK_KEY",INCR)
INCR 为要返还的库存或新增库存数
注意
如果是减库存，要用decrby count_key 1。incrby count_key -1 会出现负值，用这种方式的话得采用lua脚本的方式，先要判断count_key的值是否>0 才继续扣减，这样才能防止超卖。
不可用于秒杀的操作
锁
分析：
Redis事务是乐观锁，它不能锁住操作，仅仅只是监听事务内的key是否已经被操作过。
之所以会超发，是因为你代码中 获取库存-减少库存-放入新库存数 这期间不是原子性的。
比如 A 获取是库存为 100，B 获取时库存为 100，两方经过计算之后得到的剩余库存数都是99，然后 set 到 Redis 去，所以最后的结果是99。
当然，你可以给“获取库存=> 减少库存=> 放入新库存数”过程加锁，但是在秒杀高并发下，系统会卡死。解决办法是，用 Redis 原生的 hincrby 或 incrby 方法，该方法用于原子性操作 Hash 对象中的数字自增或自减。（见上方）
使用锁的超发例子
<?php
header("content-type:text/html;charset=utf-8");
$redis = new redis();
$result = $redis->connect('10.10.10.119', 6379);
$mywatchkey = $redis->get("mywatchkey");
$rob_total = 100; //抢购数量
if($mywatchkey<$rob_total){
$redis->watch("mywatchkey");
$redis->multi();
//设置延迟，方便测试效果。
sleep(5);
//插入抢购数据
$redis->hSet("mywatchlist","user_id_".mt_rand(1, 9999),time());
$redis->set("mywatchkey",$mywatchkey+1);
$rob_result = $redis->exec();
if($rob_result){
$mywatchlist = $redis->hGetAll("mywatchlist");
echo "抢购成功！<br/>";
echo "剩余数量：".($rob_total-$mywatchkey-1)."<br/>";
echo "用户列表：<pre>";
var_dump($mywatchlist);
}else{
echo "手气不好，再抢购！";exit;
}
}
?>
Redis Cluster撑不住怎么办
若客户很多。即使部署了Redis Cluster，仍然撑不住，那该怎么办呢？ 下面，我们具体分析下，还有哪些情况会压垮我们架构在Redis（Cluster）上的秒杀系统。
脚本攻击
如现在有很多抢火车票的软件。它们会自动发起http请求。一个客户端一秒会发起很多次请求。如果有很多用户使用了这样的软件，就可能会直接把我们的交换机给压垮了。
这个问题其实属于网络问题的范畴，和我们的秒杀系统不在一个层面上。因此不应该由我们来解决。很多交换机都有防止一个源IP发起过多请求的功能。开源软件也有不少能实现这点。如linux上的TC可以控制。流行的Web服务器Nginx（它也可以看做是一个七层软交换机）也可以通过配置做到这一点。一个IP，一秒钟我就允许你访问我2次，其他软件包直接给你丢了，你还能压垮我吗？
交换机撑不住了
可能你们的客户并发访问量实在太大了，交换机都撑不住了。 这也有办法。我们可以用多个交换机为我们的秒杀系统服务。 原理就是DNS可以对一个域名返回多个IP，并且对不同的源IP，同一个域名返回不同的IP。如网通用户访问，就返回一个网通机房的IP；电信用户访问，就返回一个电信机房的IP。也就是用CDN了！
我们可以部署多台交换机为不同的用户服务。 用户通过这些交换机访问后面数据中心的Redis Cluster进行秒杀作业。