高并发下防止商品超卖的Redis实现

朋友面试被问到高并发下，如何防止10个商品被超卖，当时想到了消息队列。我也搜了下，都是推荐内存处理秒杀类的高并发抢购，减库存则是通过异步的方式写到数据库，但是在这之前就已经对秒杀成功的用户完成了登记。看了网友的答案，总结大致如下：
1. 首先定义一个 Redis 队列名为 sku:awards，里面的元素的值都是比如 1，只是用来代表一个商品，元素的个数则是供秒杀的商品总数。
2. 因为 Redis 是单线程的，所以可以将并发的请求串行化，而且 Redis List 的 pop 操作是原子性的。
3. 所有请求打到 Redis 上，都是从 sku:awards 队列上 pop 出一个元素：
A. 如果有，说明还有商品，那么需要把用户ID加入到Redis 的 Set 名为 candidate:userids 里：
a. 如果加入成功，说明用户是第一次抢购
b. 否则，说明用户已经成功抢购了，不能重复抢购，需要往队列 sku:awards 弥补一个商品标识元素
B. 没有取到，说明都被秒杀完了
通过 jMeter 模拟并发，无论是 100，300 还是 400，candidate:userids 有且只有 10 个元素，说明商品没有超卖。
代码如下：public void testMiaosha(){
Object goods = redisTemplate.opsForList().leftPop("sku:awards");
if (goods != null){
int num = new Random().nextInt(1000) + 1;
Long result = redisTemplate.opsForSet().add("candidate:userids", num);
if (result > 0){
System.out.println("成功秒杀");
} else {
System.out.println("duplicate :::::: " + num);
redisTemplate.opsForList().rightPush("sku:awards", 1);
}
} else {
System.out.println("秒杀失败");
}
}
下面是 jMeter 测试界面：





看了【问底】徐汉彬：Web系统大规模并发——电商秒杀与抢购，里面提到了作弊手段，前两个可以通过鉴别是否同一个账号，
或者请求来自同一个IP地址来处理（上文使用的是鉴别同一账号）。也有网友提到了即便使用 Redis 也有可能抢购开始的一瞬
间请求数过多，撑爆了 Redis 的内存，那么是否可以引入如 Kafka 这样的消息队列对请求进行消峰，然后取请求数的一小部分
进入 Redis 进行下一步的真正抢购；还是直接使用消息队列就能完全应付下来呢？