Redis实战案例及问题分析之秒杀功能优化（异步下单、Redis消息队列）

原本存在问题

原本的优惠券秒杀业务中，查询优惠券、查询订单、减库存、创建订单都是直接访问的MySQL数据库，其中减库存和创建订单是写操作，当高并发的时候会给数据库造成较大的压力。

基于阻塞队列的异步解决办法：

 在redis中：

利用string结构保存优惠券的库存

利用set集合（可以存多个值且不可重复）来实现一人一单功能：

 同时利用lua脚本实现上述两个操作的原子性

 基于Redis完成秒杀资格判断

需求：

① 新增秒杀优惠券的同时，将优惠券信息保存到 Redis 中

// 保存秒杀库存到Redis中
        stringRedisTemplate.opsForValue()
.set(SECKILL_STOCK_KEY + voucher.getId(), voucher.getStock().toString());

② 基于 Lua 脚本，判断秒杀库存、一人一单，决定用户是否抢购成功

-- 1.参数列表
-- 1.1.优惠券id
local voucherId = ARGV[1]
-- 1.2.用户id
local userId = ARGV[2]
-- 1.3.订单id
local orderId = ARGV[3]

-- 2.数据key
-- 2.1.库存key
local stockKey = 'seckill:stock:' .. voucherId
-- 2.2.订单key
local orderKey = 'seckill:order:' .. voucherId

-- 3.脚本业务
-- 3.1.判断库存是否充足 get stockKey
if(tonumber(redis.call('get', stockKey)) <= 0) then
    -- 3.2.库存不足，返回1
    return 1
end
-- 3.2.判断用户是否下单 SISMEMBER orderKey userId
if(redis.call('sismember', orderKey, userId) == 1) then
    -- 3.3.存在，说明是重复下单，返回2
    return 2
end
-- 3.4.扣库存 incrby stockKey -1
redis.call('incrby', stockKey, -1)
-- 3.5.下单（保存用户）sadd orderKey userId
redis.call('sadd', orderKey, userId)
-- 3.6.发送消息到队列中， XADD stream.orders * k1 v1 k2 v2 ...
redis.call('xadd', 'stream.orders', '*', 'userId', userId, 'voucherId', voucherId, 'id', orderId)
return 0

public Result seckillVoucher(Long voucherId) {
        Long userId = UserHolder.getUser().getId();
        long orderId = redisIdWorker.nextId("order");
        // 1.执行lua脚本
        Long result = stringRedisTemplate.execute(
                SECKILL_SCRIPT,
                Collections.emptyList(),
                voucherId.toString(), userId.toString(), String.valueOf(orderId)
        );
        int r = result.intValue();
        // 2.判断结果是否为0
        if (r != 0) {
            // 2.1.不为0 ，代表没有购买资格
            return Result.fail(r == 1 ? "库存不足" : "不能重复下单");
        }
        // 3.返回订单id
        return Result.ok(orderId);
    }

 基于阻塞队列实现秒杀异步下单

③ 如果抢购成功，将优惠券 id 和用户 id 封装后存入阻塞队列

④ 开启线程任务，不断从阻塞队列中获取信息，实现异步下单功能

private static final ExecutorService SECKILL_ORDER_EXECUTOR = Executors.newSingleThreadExecutor();

    @PostConstruct //当前类初始化完毕就执行这个任务
    private void init() {
        SECKILL_ORDER_EXECUTOR.submit(new VoucherOrderHandler());
    }
private BlockingQueue<VoucherOrder> orderTasks = new ArrayBlockingQueue<>(1024 * 1024);
    private class VoucherOrderHandler implements Runnable{

        @Override
        public void run() {
            while (true){
                try {
                    // 1.获取队列中的订单信息
                    VoucherOrder voucherOrder = orderTasks.take();
                    // 2.创建订单
                    createVoucherOrder(voucherOrder);
                } catch (Exception e) {
                    log.error("处理订单异常", e);
                }
            }
        }
    }

 Redis消息队列实现异步秒杀

基于JVM实现的异步秒杀存在两个问题，一个是JVM内存有限，当有大量并发的时候就有可能超过JVM内存上限，二是数据安全问题，JVM的阻塞队列没有持久化机制，当出现宕机或者发生异常时，订单就会丢失。所以使用消息队列解决这两个问题：

 基于List模拟消息队列

 队列是入口和出口不在一边，因此我们可以利用：LPUSH 结合 RPOP、或者 RPUSH 结合 LPOP来实现。不过要注意的是，当队列中没有消息时RPOP或LPOP操作会返回null，并不像JVM的阻塞队列那样会阻塞并等待消息。因此这里应该使用BRPOP或者BLPOP来实现阻塞效果。

基于List的消息队列有哪些优缺点？

优点：

• •利用Redis存储，不受限于JVM内存上限
• •基于Redis的持久化机制，数据安全性有保证
• •可以满足消息有序性

缺点：

• •无法避免消息丢失
• •只支持单消费者

 基于PunSub的消息队列

消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有订阅者都能收到相关消息。

  SUBSCRIBE channel [channel] ：订阅一个或多个频道

  PUBLISH channel msg ：向一个频道发送消息

 PSUBSCRIBE pattern[pattern] ：订阅与pattern格式匹配的所有频道

基于PubSub的消息队列有哪些优缺点？

优点：

• •采用发布订阅模型，支持多生产、多消费

缺点：

• •不支持数据持久化
• •无法避免消息丢失
• •消息堆积有上限，超出时数据丢失

基于stream的消息队列 

Stream 是 Redis 5.0 引入的一种新数据类型，可以实现一个功能非常完善的消息队列。

 

注意：当我们指定起始ID为$时，代表读取最新的消息，如果我们处理一条消息的过程中，又有超过1条以上的消息到达队列，则下次获取时也只能获取到最新的一条，会出现漏读消息的问题。

STREAM类型消息队列的XREAD命令特点：

• 消息可回溯
• 一个消息可以被多个消费者读取
• 可以阻塞读取
• 有消息漏读的风险

 基于stream的消息队列——消费者组

 消费者组（Consumer Group）：将多个消费者划分到一个组中，监听同一个队列。具备下列特点：

 

 prnding-list是指消费了但为确认的消息。

STREAM类型消息队列的XREADGROUP命令特点：

• 消息可回溯
• 可以多消费者争抢消息，加快消费速度
• 可以阻塞读取
• 没有消息漏读的风险
• 有消息确认机制，保证消息至少被消费一次

 基于stream的消息队列实现异步秒杀下单