Redis实战-消息队列篇

前言：

讲讲做消息队列遇到的问题。

今日所学：

• 异步优化
• 消息队列
• 基于stream实现异步下单

1. 异步优化

1.1 需求分析

1.1.1 现有下单流程：

1.查询优惠劵

2.判断是否是秒杀时间，库存是否充足

3.实现一人一单

在这个功能中，最初我们是直接使用synchronized锁让每次多个userId相同的线程只能有一个通过，后面为了能在集群下也可以实现一人一单功能，我们使用了redis的setnx，利用其互斥性来实现加锁和解锁

4.扣减库存（使用乐观锁CAS机制防止超卖）

5.创建订单

在这些操作中，很多操作比如（查询优惠劵，扣减库存，创建订单）都是要去操作数据库的，而且还是一个线程串行执行。这会导致我们的程序执行很慢，所以我们可以考虑去异步执行。

这里插播一条解释下同步和异步：

​​同步（Synchronous）​​：
任务执行时，调用方必须​​等待被调用方返回结果​​后才能继续执行后续代码。整个过程是​​阻塞的​​，严格按照顺序执行。

​​异步（Asynchronous）​​：
调用方发起任务后，​​无需等待被调用方完成​​，可以立即执行后续代码。被调用方通过回调、事件或消息等方式​​在完成后通知调用方​​。

通俗一点的解释就是：

同步就相当于是”我等着你做完“。就好比你打电话问你朋友问题，在朋友回答你之前，你必须一直等待（进入阻塞），期间做不了其他事。

异步就相当于”你弄你的，好了通知我就行“。就好比是你发微信问你朋友问题，在朋友回答你之前，你可以去干其他事，比如刷视频啥的呀。

1.1.2 优化方案

我们可以将比较耗时的逻辑判断放入redis中，比如库存是否充足，是否是一人一单，这样的逻辑如果能通过，就表示一定是能下单的，那么我就不需要等真实的下单逻辑走完，可以直接返回给用户结果，真实的下单流程我们可以在后台开个线程，让后台的线程去执行下单程序。

那么这样做存在两个难点：

第一.我们任何在redis中去校验一人一单功能和库存判断呢？

第二.我们校验和下单是两个线程，那么我们如何知道完成校验和下单的是哪个订单，校验和下单如何联系统一呢？

我们看整体思路：当用户下单后，判断库存是否充足只需要查找redis中相应的key的value是否是大于零的，大于零才能继续执行业务逻辑，接着我们可以设定一个set用来储存userId,那么判断用户是否下过单，我们只需要判断set集合中是否有这个这条记录，如果没有，返回0（代表下单成功），并将userID和优惠劵信息存到redis中。最后，整个过程我们要保证是原子性的，我们可以使用lua脚本。

当判断逻辑走完后，看返回的是否是0，如果是0，代表着可以下单，将之前所说的所有信息存入到queue中，然后返回订单id给前端，开启阻塞队列进行真正的下单功能。

1.2 代码实现

1.更改新增优惠券的代码，在新增秒杀优惠券的同时，将优惠券信息保存到Redis中

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

3. 如果判断可以下单，将优惠券id和用户id封装后存入阻塞队列，将订单id返回给用户

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

（这里截图用的是后续要学的消息队列，阻塞队列那张图找不到了）

下面是完整代码：

在service层VoucherServiceImpl下，添加保存秒杀库存到redis的功能

@Override

@Transactional

public void addSeckillVoucher(Voucher voucher) {

    // 保存优惠券

    save(voucher);

    // 保存秒杀信息

    SeckillVoucher seckillVoucher = new SeckillVoucher();

    seckillVoucher.setVoucherId(voucher.getId());

    seckillVoucher.setStock(voucher.getStock());

    seckillVoucher.setBeginTime(voucher.getBeginTime());

    seckillVoucher.setEndTime(voucher.getEndTime());

    seckillVoucherService.save(seckillVoucher);

    // 保存秒杀库存到Redis中

    //SECKILL_STOCK_KEY 这个变量定义在RedisConstans中

    //private static final String SECKILL_STOCK_KEY ="seckill:stock:"

    stringRedisTemplate.opsForValue().set(SECKILL_STOCK_KEY + voucher.getId(), voucher.getStock().toString());

}

在resources层下的seckill.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

在service层的VoucherOrderServiceImpl下

这段逻辑中我们使用BlockingQueue（阻塞队列）的原因是为了防止大量的请求直接到达数据库，压垮数据库。

当判断可以下单时，程序创建订单对象，并且使用add添加到阻塞队列中，然后消费者端的线程可以使用take()从阻塞队列中拿到订单信息，直接具体的订单创建功能。

当没有订单也就是队列为空时，take()会阻塞消费者端线程

//异步处理线程池

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

//在类初始化之后执行，因为当这个类初始化好了之后，随时都是有可能要执行的

@PostConstruct

private void init() {

   SECKILL_ORDER_EXECUTOR.submit(new VoucherOrderHandler());

}

// 用于线程池处理的任务

// 当初始化完毕后，就会去从对列中去拿信息

 private class VoucherOrderHandler implements Runnable{

        @Override

        public void run() {

            while (true){

                try {

                    // 1.获取队列中的订单信息

                    VoucherOrder voucherOrder = orderTasks.take();

                    // 2.创建订单

                    handleVoucherOrder(voucherOrder);

                } catch (Exception e) {

                    log.error("处理订单异常", e);

                }

             }

        }

     

       private void handleVoucherOrder(VoucherOrder voucherOrder) {

            //1.获取用户

            Long userId = voucherOrder.getUserId();

            // 2.创建锁对象

            RLock redisLock = redissonClient.getLock("lock:order:" + userId);

            // 3.尝试获取锁

            boolean isLock = redisLock.lock();

            // 4.判断是否获得锁成功

            if (!isLock) {

                // 获取锁失败，直接返回失败或者重试

                log.error("不允许重复下单！");

                return;

            }

            try {

                //注意：由于是spring的事务是放在threadLocal中，此时的是多线程，事务会失效

                proxy.createVoucherOrder(voucherOrder);

            } finally {

                // 释放锁

                redisLock.unlock();

            }

    }

     

    private BlockingQueue<VoucherOrder> orderTasks =new  ArrayBlockingQueue<>(1024 * 1024);

@Override

    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 ? "库存不足" : "不能重复下单");

        }

        VoucherOrder voucherOrder = new VoucherOrder();

        // 2.3.订单id

        long orderId = redisIdWorker.nextId("order");

        voucherOrder.setId(orderId);

        // 2.4.用户id

        voucherOrder.setUserId(userId);

        // 2.5.代金券id

        voucherOrder.setVoucherId(voucherId);

        // 2.6.放入阻塞队列

        orderTasks.add(voucherOrder);

        //3.获取代理对象

         proxy = (IVoucherOrderService)AopContext.currentProxy();

        //4.返回订单id

        return Result.ok(orderId);

    }

     

1.3 总结

秒杀业务的优化思路是什么：

• 先利用redis存量，一人一单判断，符合下单认证，则视为下单成功。给用户返回信息
• 再将下单业务放入阻塞队列中，利用独立线程异步完成真正的下单功能
• 这种做法基于阻塞队列，订单来时，线程池中的单线程会不断取出任务，处理订单，当没有任务时，陷入阻塞

1.4 问题

这段代码逻辑中，存在一个缺陷：

即redis中存在的库存量和数据库中的库存量有可能不同步。假设下如果redis校验通过，库存在redis中已经扣除了，但是在进行阻塞队列的时候发生了宕机，就既有可能导致二者的数据不同步。这个问题我们会留到消息队列那块去处理。

2.消息队列

2.1 认识消息队列

什么是消息队列：字面意思就是存放消息的队列。

最简单的消息队列模型包括3个角色：

•  消息队列：存储和管理消息，也被称为消息代理（Message Broker）
• 生产者：发送消息到消息队列
• 消费者：从消息队列获取消息并处理消息

使用这种队列的好处：

解耦合。​​解耦（Decoupling）​​ 指的是 ​​减少不同模块或组件之间的直接依赖关系​​，使它们能够独立变化、扩展和维护。而 ​​队列（Queue）​​ 是一种 ​​异步通信机制​​，能够有效实现解耦。

跟我在之前那个讲的异步和同步关系非常类似，使用这种队列就相当于在双方中间加了一个缓冲层，使得双方可以各干各的事情。

这种场景在我们秒杀中就变成了：我们下单之后，利用redis去进行校验下单条件，再通过队列把消息发送出去，然后再启动一个线程去消费这个消息，完成解耦，同时也加快我们的响应速度。

这里我们可以使用一些现成的mq，比如kafka，rabbitmq等等，但是呢，如果没有安装mq，我们也可以直接使用redis提供的mq方案，降低我们的部署和学习成本。

2.2 Redis消息队列

2.2.1 基于List结构去模拟消息队列

队列是入口和出口不在一边，因此我们可以利用：LPUSH 结合 RPOP、或者 RPUSH 结合 LPOP来实现。

不过要注意的是，当队列中没有消息时RPOP或LPOP操作会返回null，并不像JVM的阻塞队列那样会阻塞并等待消息。因此这里应该使用BRPOP或者BLPOP来实现阻塞效果。（没有元素弹出时会进行等待 BRPOP key [key ...] timeout1.

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

优点：

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

缺点：

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

2.2.2 基于PubSub的消息队列

PubSub（发布订阅）是Redis2.0版本引入的消息传递模型。顾名思义，消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有订阅者都能收到相关消息。

订阅一个或多个频道：

SUBSCRIBE channel [channel]

向一个频道发送消息：

 PUBLISH channel msg 

订阅与pattern格式匹配的所有频道: 

PSUBSCRIBE pattern[pattern] 

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

优点：

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

缺点：

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

2.2.3 基于Stream的消息队列

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

发送消息的命令：

例如：

读取消息的方式之一：XREAD

例如：

XREAD阻塞方式，读取最新的消息：

在业务开发中，我们可以循环的调用XREAD阻塞方式来查询最新消息，从而实现持续监听队列的效果，伪代码如下

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

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

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

2.3 基于Stream的消息队列-消费者组

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

生产者将通过XADD将消息写入Stream(追加在stream的末尾)，消费者组内所有消费者共享同一份数据。

数据分为未标记数据（还未分配给消费者组），标记数据（已经分配给消费者组但是还未确认），确认数据（已经被确认消费完成的数据）。其中标记数据会被放在pending-list中，待消费完成后并显式ack后才会从pending-list移除。如果消费完成但是还没有显式ack系统宕机，数据也不会从pending-list移除，而是由其他消费者重新消费，这种机制实现了消费“至少一次”，但可能存在被多次读取的情况。

创建消费者组：

key：队列名称

groupName：消费者组名称

ID：起始ID标示，$代表队列中最后一个消息，0则代表队列中第一个消息

MKSTREAM：队列不存在时自动创建队列

其他常见命令：

1. 删除指定消费者：

XGROUP DESTORY key groupName

2.给指定的消费者组添加消费者：

XGROUP CREATECONSUMER key groupname consumername

3.删除消费者组中的指定消费者： 

XGROUP DELCONSUMER key groupname consumername

4.从消费者组读取消息：

XREADGROUP GROUP group consumer [COUNT count] [BLOCK milliseconds] [NOACK] STREAMS key [key ...] ID [ID ...]

（注：创建消费者组后，是没有任何消费者的，当读取信息时，会判断是否存在该消费者，如果存在，使用已存在的消费者，如果不存在，则创建新的消费者）

group：消费组名称

 consumer：消费者名称，如果消费者不存在，会自动创建一个消费者

 count：本次查询的最大数量

 BLOCK milliseconds：当没有消息时最长等待时间

 NOACK：无需手动ACK，获取到消息后自动确认

 STREAMS key：指定队列名称

 ID：获取消息的起始ID

">"：从下一个未消费的消息开始

其它：根据指定id从pending-list中获取已消费但未确认的消息，例如0，是从pending-list中的第一个消息开始

消费者监听消息的基本思路：

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

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

2.4 总结：

3.基于stream实现异步下单

需求分析：

• 创建一个Stream类型的消息队列，名为stream.orders
•  修改之前的秒杀下单Lua脚本，在认定有抢购资格后，直接向stream.orders中添加消息，内容包含voucherId、userId、orderId
•  项目启动时，开启一个线程任务，尝试获取stream.orders中的消息，完成下单

代码实现：

1.在seckill.lua脚本中，添加发送信息功能，如果可以下单，发送信息到消息队列中

完整的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 判断库存是否充足
if (tonumber(redis.call('get', stockKey)) <= 0) then
    -- 3.2 库存不足，返回1
    return 1
end

-- 3.2 判断用户是否下单
if (redis.call('sismember', orderKey, userId) == 1) then
    -- 3.3 存在，，说明是重复下单，返回2
    return 2
end

-- 3.4扣库存
redis.call('incrby', stockKey, -1)
-- 3.5下单（保存用户）
redis.call('sadd', orderKey, userId)

-- 3.6 发送消息到队列当中
redis.call('xadd', 'stream.orders', '*', 'userId',userId, 'voucherId',voucherId, 'id', orderId)
return 0;

2.修改线程任务，交由消息队列处理

在service层中的VoucherOrderServiceImpi类中

实现思路：

1.获取消息订单信息

Counsumer指定消费者组和消费者（如果没有消费者则创建）

StreamReadOptions读取选项->一次读一个，如果没有，阻塞等待2秒

StreamOffset指定读取位置->读取最后被消费的位置开始读取

2.如果没读到 进入下一个循环

3.如果读到，解析相应数据，因为一次只读一个数据，使用get(0)拿第一条数据即可

4.转换成voucherOrder

5.调用createVoucherOrder在数据库扣减相应库存，创建订单

6.确认消息（ack）

private class VoucherOrderHandler implements Runnable {

    @Override

    public void run() {

        while (true) {

            try {

                // 1.获取消息队列中的订单信息 XREADGROUP GROUP g1 c1 COUNT 1 BLOCK 2000 STREAMS s1 >

                List<MapRecord<String, Object, Object>> list = stringRedisTemplate.opsForStream().read(

                    Consumer.from("g1", "c1"),

                    StreamReadOptions.empty().count(1).block(Duration.ofSeconds(2)),

                    StreamOffset.create("stream.orders", ReadOffset.lastConsumed())

                );

                // 2.判断订单信息是否为空

                if (list == null || list.isEmpty()) {

                    // 如果为null，说明没有消息，继续下一次循环

                    continue;

                }

                // 解析数据

                MapRecord<String, Object, Object> record = list.get(0);

                Map<Object, Object> value = record.getValue();

                VoucherOrder voucherOrder = BeanUtil.fillBeanWithMap(value, new VoucherOrder(), true);

                // 3.创建订单

                handleVoucherOrder(voucherOrder);

                // 4.确认消息 XACK

                stringRedisTemplate.opsForStream().acknowledge("s1", "g1", record.getId());

            } catch (Exception e) {

                log.error("处理订单异常", e);

                //处理异常消息

                handlePendingList();

            }

        }

    }

7.如果出现异常，比如说还未确认消息时程序宕机，进入异常处理环节。

此时由于消息还未被确认，任然是在pending-list队列中，此时由消费者重新消费该消息，并进行消息确认。

这里我们有两个需要注意的点：

1.重新消费信息时，为了防止他再次扣减库存以及创建订单，我们在createvoucherOrder进行二次校验：再扣减库存前，查询数据库是否有相应的userId

2.为了防止短时间内对线程池进行多次请求导致线程池耗尽，我们在出现异常时，需要加入Thread.sleep()来给线程池缓冲的时间

 private void handlePendingList() {

        while (true) {

            try {

                // 1.获取pending-list中的订单信息 XREADGROUP GROUP g1 c1 COUNT 1 BLOCK 2000 STREAMS s1 0

                List<MapRecord<String, Object, Object>> list = stringRedisTemplate.opsForStream().read(

                    Consumer.from("g1", "c1"),

                    StreamReadOptions.empty().count(1),

                    StreamOffset.create("stream.orders", ReadOffset.from("0"))

                );

                // 2.判断订单信息是否为空

                if (list == null || list.isEmpty()) {

                    // 如果为null，说明没有异常消息，结束循环

                    break;

                }

                // 解析数据

                MapRecord<String, Object, Object> record = list.get(0);

                Map<Object, Object> value = record.getValue();

                VoucherOrder voucherOrder = BeanUtil.fillBeanWithMap(value, new VoucherOrder(), true);

                // 3.创建订单

                createVoucherOrder(voucherOrder);

                // 4.确认消息 XACK

                stringRedisTemplate.opsForStream().acknowledge("s1", "g1", record.getId());

            } catch (Exception e) {

                log.error("处理pendding订单异常", e);

                try{

                    Thread.sleep(20);

                }catch(Exception e){

                    e.printStackTrace();

                }

            }

        }

    }

}

问题：

在这我遇到了几个问题：

1.短时间大量连接导致连接池耗尽->这里我在异常处理那加入了thread，就算有异常造成大量连接，也没有给连接池缓冲的时间。

2.对于使用阻塞队列可能造成的redis和数据库的数据不一致问题，在消息队列中也可以有效解决：

在ack过程中，如果出现异常，会进入handlePendingList函数，重新分配消费者进行消费，有效解决数据不一致问题

3.吞吐量的问题

可以发现，在1000个线程并发的请况下，我的吞吐量只有100/sec,这是极低的

我原先以为是数据库的问题，后面我给代码具体逻辑注释掉了，发现还是100/sec，可以排除是数据库或者是代码逻辑的问题

后面发现给时间设置成1s内启动

吞吐量明显增高，达到了1000qps

虽然还是偏低，但是没有以前那么离谱了。（问题解决过程有点搞笑，我还是想把它写下来）。