Redis 列表（List）是一种简单的字符串列表，它的底层实现是一个双向链表。

生产环境，很多公司都将 Redis 列表应用于轻量级消息队列 。这篇文章，我们聊聊如何使用 List 命令实现消息队列的功能以及剖析消费者线程模型。

1 核心流程

生产者使用LPUSH key element[element...]将消息插入到队列的头部，如果 key 不存在则会创建一个空的队列再插入消息。

如下，生产者向队列 queue 先后插入了 「Java」「勇哥」「Go」，返回值表示消息插入队列后的个数。

> LPUSH queue Java 勇哥 Go
(integer) 3

消费者使用RPOP key依次读取队列的消息，先进先出，所以 「Java」会先读取消费：

> RPOP queue
"Java"
> RPOP queue
"勇哥"
> RPOP queue
"Go"

接下来，我们可以通过 spring-data-redis API 演示生产消费流程：

redisTemplate.opsForList().leftPush("queue" , "Java");
redisTemplate.opsForList().leftPush("queue" , "勇哥");
redisTemplate.opsForList().leftPush("queue" , "Go");

我们启动一个独立的线程从队列中读取消息（RPOP 命令），读取成功之后，消费消息，若没有消息，则休眠一会，下一次循环再继续。

上图的伪代码中，while(true)循环内不停地调用RPOP指令，当有消息时，可以及时处理，但假如没有读取到消息，则需要休眠一会。

这里要加休眠，主要是为了减少空读的频率，避免 CPU 无意义的消耗。

有什么更优化的方式吗？ 有，那就是使用 Redis 阻塞读取 List 的命令。

Redis 提供了BLPOP、BRPOP阻塞读取的命令，消费者在在读取队列没有数据的时自动阻塞，直到有新的消息写入队列，才会继续读取新消息执行业务逻辑。

BRPOP queue 0

参数 0 表示阻塞等待时间无限制 。

如图，我们启动一个消费线程永动机，消费线程拉取消息后，执行消费逻辑。

这种消费者线程模型非常容易理解，同时也非常适合顺序消费的模式。同时，假如我们在消费消息时，服务器宕机或者断电，可能丢失一条消息。

接下来，我们想一想，有没有消费速度更高的消费模型吗？ 笔者根据过往的经历，列举三种模式：

2 拉取线程 + 消费线程池（非阻塞模式）

为了提升消费速度，我们可以将拉取和消费拆分成两种动作，分别通过不同的线程池来处理。拉取线程池负责拉取消息，消费线程池负责消费消息。

伪代码类似：

如图，在拉取线程内部，我们拉取完消息后，将消息提交到消费线程 consumeExecutor 。

这样方式可以通过多线程执行大幅度提升消费速度 ，但是这里还是有一个问题：

假如消费速度很慢，生产者速度很高，那么就会在线程池内容易产生消息堆积，这里面会产生两个隐形风险：

那么如何优化这种模式呢 ？

答案是：拉取线程提交消息到线程池时，当队列中消息数量到达一定数量时，提交消息到线程池会阻塞。

3 拉取线程 + 消费线程池（阻塞模式）

我们将消息包装为 Runnable ，然后通过消费线程池执行 execute ，拉取线程会不会阻塞呢 ？

下图是执行的源码：

可以看到，第 30 行调用的是 workQueue 的非阻塞的 offer 方法。

如果队列已满，新提交的任务并不会被 block 住，反而会调用后续的 reject 流程。

如果我们想要达到阻塞生产者的目的的话，可以采取如下的两种方案：

4 拉取线程 + Disruptor

下图展示了 Disruptor 的流程图 。

和线程池机制非常类似， Disruptor 也是非常典型的生产者/消费者模式。线程池存储提交任务的容器是阻塞队列，而 Disruptor 使用的是环形缓冲区 RingBuffer。

环形缓冲区的设计相比阻塞队列有如下优点：

为了避免垃圾回收，采用数组而非链表。同时，数组对处理器的缓存机制更加友好。

数组长度 2^n，通过位运算，加快定位的速度。下标采取递增的形式，不用担心 index 溢出的问题。index 是 long 类型，即使100万QPS的处理速度，也需要30万年才能用完。

每个生产者或者消费者线程，会先申请可以操作的元素在数组中的位置，申请到之后，直接在该位置写入或者读取数据。

此刻大家并不需要理解环形缓冲区的读写机制，只需要明白环形缓冲区 RingBuffer是 Disruptor 的精髓即可。

将消费线程池替换成 Disruptor 有两个明显的优点：

伪代码类似：

1、定义 Disruptor

2、拉取线程将消息发送到 Disruptor Ringbuffer

3、消费消息

整体的消费者线程模型如下图：

5 平滑停服 + 定时任务补偿

当我们分析消费者线程模型时，无论我们使用哪种方式，假如服务器突然宕机、或者物理机断电，则会丢失消息。

笔者推荐两种方式：

1、平滑停服

平滑停服是指在停止应用程序时，尽量避免中断正在进行的请求或任务，尽量让正在进行的任务处理完成，并且不再接收新的任务，等所有任务执行完成后关闭应用。

在 Unix/Linux 系统中，可以使用kill命令发送信号给运行中的进程。

常见的信号有：

为了实现平滑停服，可以使用 Java 的Runtime.getRuntime().addShutdownHook方法注册一个关闭钩子（shutdown hook）。当 JVM 接收到SIGTERM信号时，关闭钩子会被执行，从而可以在应用程序停止前执行一些清理工作。

Runtime.getRuntime().addShutdownHook(new Thread(() -> {
        System.out.println("Shutdown hook triggered. Performing cleanup...");
        // 在这里执行清理工作，如关闭资源、保存状态等
}));

我们可以在钩子里，关闭拉取线程池 ，优雅关闭消费线程池等 ，这样可以尽量避免丢失消息。

2、定时任务补偿

使用 List 做消息队列，不可避免的会有消息丢失，所以我们需要用定时任务做补偿，每隔一段时间去业务表里查询业务状态机，若状态机不符合条件，则触发补偿策略。

参考资料：

…

redis.io/docs/latest…

/post/709427…

/2021/12/01/…

十年的编程时光里，我也积累了很多的电子书籍，有些书写得非常经典，分享给各位。

这些电子书 我已经打包好了 ，下载地址是：

计算机电子书籍分享​/s/WHK7HNyaeM2cQTpJZiTuJQ

另外，花了半年时间，我写了一本消息队列电子书 ，书名是：《RocketMQ4.X设计精要》，有兴趣的朋友，可以看看。

这本书一共包含十五章，接近 10 万字，180 张图，按照 RocketMQ 的知识体系一章一章展开。

下载地址是：

1024 程序员节，圆一个小小的梦​/s/aMSa5GKloN2_lsMHRpGiOA