写点什么

剖析 Redis List 消息队列的三种消费线程模型

  • 2024-09-11
    福建
  • 本文字数:2604 字

    阅读完需:约 9 分钟

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 表示阻塞等待时间无限制 。



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


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


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


  • 拉取线程 + 消费线程池(非阻塞模式)

  • 拉取线程 + 消费线程池 (阻塞模式)

  • 拉取线程 + Disruptor(阻塞模式)


2 拉取线程 + 消费线程池(非阻塞模式)


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



伪代码类似:



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


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


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


  • 线程池队列无限堆积,则可能有 OOM 的风险 ;

  • 假如消费者服务器宕机或者断电,那么会丢失大量的消息。


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


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


3 拉取线程 + 消费线程池(阻塞模式)


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


下图是执行的源码:



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


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


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


  • 信号量限制同时进入线程池等待队列的任务数 。



  • 使用线程池的拒绝机制,把新加入的任务 put 到等待队列里,这样也可以阻塞住生产者。



4 拉取线程 + Disruptor


下图展示了 Disruptor 的流程图 。



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


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


  • 环形数组结构

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


  • 元素位置定位

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


  • 无锁设计

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


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


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


  • 无锁队列,写入读取性能非常好

  • 当拉取线程提交消息到 Disruptor 时,若环形缓冲区 RingBuffer 已经满了,则拉取线程会阻塞,这样天然的可以避免无限拉取,同时避免 OOM 的问题。


伪代码类似:


1、定义 Disruptor



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



3、消费消息



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



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


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


笔者推荐两种方式:


1、平滑停服

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


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


常见的信号有:


  • SIGTERM (15):请求进程终止,可以被捕捉和处理,用于优雅地停止进程。

  • SIGKILL (9):强制终止进程,不能被捕捉或忽略。

  • SIGQUIT (3):进程退出并生成核心转储(core dump)。


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


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


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


2、定时任务补偿


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


文章转载自:勇哥编程游记

原文链接:https://www.cnblogs.com/makemylife/p/18407450

体验地址:http://www.jnpfsoft.com/?from=infoq

用户头像

还未添加个人签名 2023-06-19 加入

还未添加个人简介

评论

发布
暂无评论
剖析 Redis List 消息队列的三种消费线程模型_数据库_不在线第一只蜗牛_InfoQ写作社区