源码剖析RocketMQ延时消息原理

Myth丶恋晨 2023-10-01 16:08 164阅读 0赞

一、前言

RocketMQ版本4.8.0，本文中相关源码注释见GitHub中：RocketMQ：release-4.8.0。上一篇文章我们分析了RocketMQ的的消费超时/失败重试机制，最终会发送一个延时消息到Broker，本篇接着分析RockeTMQ延时消息的实现机制；

1、消息延时级别

消息的延时级别level一共有18级，分别为：

1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h

level有以下三种情况：

  • level == 0，消息为非延迟消息
  • 1<=level<=maxLevel，消息延迟特定时间，例如level==1，延迟1s
  • level > maxLevel，则level== maxLevel，例如level==20，延迟2h

2、定时消息（延迟消息）简介

定时消息（延迟队列）是指消息发送到broker后，不会立即被消费，等待特定时间投递给真正的topic；

  1. 定时消息会暂存在名为SCHEDULE_TOPIC_XXXX的topic中，并根据delayTimeLevel存入特定的queue，queueId = delayTimeLevel – 1，即一个queue只存相同延迟的消息，保证具有相同发送延迟的消息能够顺序消费。
  2. broker会调度地消费SCHEDULE_TOPIC_XXXX，将消息写入真实的topic。
  3. 注意：定时消息会在第一次写入和调度写入真实topic时都会计数，因此发送数量、tps都会变高。
  4. 在消息创建的时候，调用 setDelayTimeLevel(int level) 方法设置延迟时间；

3、定时消息的使用

  1. public class Producer {
  3.     public static void main(String[] args) throws Exception {
  5.         DefaultMQProducer producer = new DefaultMQProducer("producer_saint");
  6.         producer.setNamesrvAddr("127.0.0.1:9876");
  7.         producer.start();
  8.         Message msg = new Message("consumer-timeout", "msg-body-001".getBytes(StandardCharsets.UTF_8));
  9.         msg.setTags("msg-body-001");
  10.         // 设置消息延时级别
  11.         msg.setDelayTimeLevel(3);
  12.         List<Message> list = new ArrayList<>();
  13.         list.add(msg);
  14.         SendResult send = producer.send(list);
  15.         System.out.println("sendResult: " + send);
  16.     }
  17. }

二、源码分析

1、整体实现流程

整体流程如下图，executeOnTimeup()方法部分代码太多，流程图中采用文字说明；
在这里插入图片描述

2、入口

ScheduleMessageService#start()

在Broker启动时会间接执行ScheduleMessageService#start()，执行启动延时消息服务操作；下面我们从Broker的核心类BrokerController中开始看起；

1> BrokerStartup#start()

这里是Broker启动的核心；关于Broker的启动流程，请参考这篇文章：RocketMQ：深度剖析Broker启动流程原理、源码
在这里插入图片描述

紧接着进入到BrokerController#start()；在这里会启动消息持久化服务MessageStore。

2> DefaultMessageStore#start()

在这里插入图片描述
MessageStore是一个接口，下面会进入到它的实现类DefaultMessageStore中；在DefaultMessageStore#start()方法中会判断Broker是否开启了DLegerCommitLog，如果没有并且Broker的角色不是Slave，才会开启延时消息服务。

在这里插入图片描述
在这里插入图片描述

ScheduleMessageService#start()是开启延时消息服务的核心，下面我们接着看；

3、核心逻辑

ScheduleMessageService#start()中主要做两件事：

  1. 为每个延时级别都分别开启一个定时任务，每秒执行一次发送延迟消息到真实Topic的操作；

  2. 延时10s为每个延时级别都分别开启一个定时任务，每10s做一次延时队列中消息偏移量的持久化；

    public void start() {

    if (started.compareAndSet(false, true)) {

    1.     this.timer = new Timer("ScheduleMessageTimerThread", true);
    2.     // delayLevelTable中存放着每个延时级别和其对应的消息offset
    3.     for (Map.Entry<Integer, Long> entry : this.delayLevelTable.entrySet()) {
    5.         Integer level = entry.getKey();
    6.         Long timeDelay = entry.getValue();
    7.         Long offset = this.offsetTable.get(level);
    8.         if (null == offset) {
    10.             offset = 0L;
    11.         }
    13.         if (timeDelay != null) {
    15.             // 1、每秒从"SCHEDULE_TOPIC_XXXX" topic中取数据
    16.             this.timer.schedule(new DeliverDelayedMessageTimerTask(level, offset), FIRST_DELAY_TIME);
    17.         }
    18.     }
    20.     // 2、延时10s启动，并且每10s把每一个延迟队列的最大消息偏移量写入到磁盘中
    21.     this.timer.scheduleAtFixedRate(new TimerTask() {
  1.             @Override
  2.             public void run() {
  4.                 try {
  6.                     if (started.get()) ScheduleMessageService.this.persist();
  7.                 } catch (Throwable e) {
  9.                     log.error("scheduleAtFixedRate flush exception", e);
  10.                 }
  11.             }
  12.         }, 10000, this.defaultMessageStore.getMessageStoreConfig().getFlushDelayOffsetInterval());
  13.     }
  14. }

1> ScheduleMessageService.this.persist()

我们先看ScheduleMessageService.this.persist()，点进去会进去到ConfigManager#persist()方法中；这里的操作就单纯的持久化delayQueue的offset到delayOffset.json文件中；

  1. public synchronized void persist() {
  3.     // 读取offsetTable缓存的延迟队列的值
  4.     String jsonString = this.encode(true);
  5.     if (jsonString != null) {
  7.         // 读取delayOffset.json的文件地址
  8.         String fileName = this.configFilePath();
  9.         try {
  11.             // 持久化到delayOffset.json文件中
  12.             MixAll.string2File(jsonString, fileName);
  13.         } catch (IOException e) {
  15.             log.error("persist file " + fileName + " exception", e);
  16.         }
  17.     }
  18. }

2> DeliverDelayedMessageTimerTask

DeliverDelayedMessageTimerTask是TimerTask的子类，表示一个线程任务；其主要作用是扫描延迟消息队列（SCHEDULE_TOPIC_XXXX）的消息，将该延迟消息转换为真实topic的消息。

这里真实消息的topic有几个特殊之处：

  • 对于（并发消费模式下）消费超时重试的消息而言，真实的topic是%RETRY%+consumerGroup；
1）DeliverDelayedMessageTimerTask#run()

在这里插入图片描述
我们接着看看这个线程任务内部，执行了executeOnTimeup()方法；这是判断延时消息是否到应该转发到真实topic的核心逻辑。

2）executeOnTimeup()

由于代码篇幅过长，这里我们从五个问题着手分析；

  1. 根据延时级别获取在SCHEDULE_TOPIC_XXXX主题下queueId为delayLevel - 1的延时队列是否存在？ 延时队列不存在怎么处理？
  2. 延时消息是否到期？到期后怎么处理？
  3. 延时消息到期后写入CommitLog失败怎么处理？
  4. 延时消息没到期怎么处理？
  5. 延时队列中的消息处理完怎么处理？

先看第一问题：

（1）根据延时级别获取在SCHEDULE_TOPIC_XXXX主题下queueId为delayLevel - 1的延时队列是否存在？ 延时队列不存在怎么办？

判断当前延时级别对应在SCHEDULE_TOPIC_XXXX主题下的queue是否存在，如果存在进入第二个问题，否则隔0.1s再次开启当前TimerTask；
在这里插入图片描述
再来看第二个问题：

（2）延时消息是否到期？到期后怎么处理？

在第一问题成立之后，我们已经获取到延时级别对应的延时队列，接下来首先要根据offset从ConsumeQueue中获取到延时消息的部分信息（offset、size、到期时间）；接着再判断消息是否到期，并计算出下一个延时消息在延时队列中的offset；
在这里插入图片描述
如果消息到期，再从commitlog中根据ofsetPy取出完整的消息，解析出消息的真实Topic和Queue，并清除消息的延时属性，然后将消息写入到CommitLog中；
在这里插入图片描述
对于如何判断消息过期，我们再跟一下correctDeliverTimestamp()方法；

从消息tagsCode属性中解析出消息应当被投递的时间，然后与当前时间做比较，判断是否应该进行投递（消息是否到期）；

在这里插入图片描述

再来看第三个问题：

（3）延时消息到期后写入CommitLog失败怎么办？

如果写入CommitLog失败，则延时10s重新开启当前TimerTask，持久化delayOffset；
在这里插入图片描述

再来看第四个问题：

（4）延时消息没到期怎么处理？

如果消息未到期，则延时countdown（countdown为延时队列中第一个消息的剩余到期时间），开启一个TimerTask，并持久化delayOffset；
在这里插入图片描述

最后再看第五个问题：

（5）延时队列中的消息处理完怎么办？

遍历完相应延时级别的延时队列后，更新下一次开始读取延迟队列的offset，然后延时0.1s开启当前TimerTask，并持久化delayOffset；最后退出当前方法；
在这里插入图片描述

executeOnTimeup()方法完成代码如下：

  1. public void executeOnTimeup() {
  3.     // 根据延迟级别找到topic为SCHEDULE_TOPIC_XXXX的队列（队列的ID 为延时级别 - 1）
  4.     ConsumeQueue cq =
  5.         ScheduleMessageService.this.defaultMessageStore.findConsumeQueue(TopicValidator.RMQ_SYS_SCHEDULE_TOPIC,
  6.             delayLevel2QueueId(delayLevel));
  8.     long failScheduleOffset = offset;
  10.     // 找到延时级别对应的队列
  11.     if (cq != null) {
  13.         SelectMappedBufferResult bufferCQ = cq.getIndexBuffer(this.offset);
  14.         if (bufferCQ != null) {
  16.             try {
  18.                 long nextOffset = offset;
  19.                 int i = 0;
  20.                 ConsumeQueueExt.CqExtUnit cqExtUnit = new ConsumeQueueExt.CqExtUnit();
  21.                 for (; i < bufferCQ.getSize(); i += ConsumeQueue.CQ_STORE_UNIT_SIZE) {
  23.                     // 消息的commitLog物理偏移量
  24.                     long offsetPy = bufferCQ.getByteBuffer().getLong();
  25.                     // 消息大小
  26.                     int sizePy = bufferCQ.getByteBuffer().getInt();
  27.                     // 延迟结束时间，在消息写入到CommitLog之后会分发到consumeQueue；
  28.                     // 对于延迟消息而言，tagsCode存储的是消息的延迟到期时间
  29.                     long tagsCode = bufferCQ.getByteBuffer().getLong();
  31.                     if (cq.isExtAddr(tagsCode)) {
  33.                         if (cq.getExt(tagsCode, cqExtUnit)) {
  35.                             tagsCode = cqExtUnit.getTagsCode();
  36.                         } else {
  38.                             //can't find ext content.So re compute tags code.
  39.                             log.error("[BUG] can't find consume queue extend file content!addr={}, offsetPy={}, sizePy={}",
  40.                                 tagsCode, offsetPy, sizePy);
  41.                             long msgStoreTime = defaultMessageStore.getCommitLog().pickupStoreTimestamp(offsetPy, sizePy);
  42.                             tagsCode = computeDeliverTimestamp(delayLevel, msgStoreTime);
  43.                         }
  44.                     }
  46.                     long now = System.currentTimeMillis();
  48.                     // 计算是否到消息投递时间
  49.                     long deliverTimestamp = this.correctDeliverTimestamp(now, tagsCode);
  51.                     // 定时任务下一次开始读取延迟队列的offset
  52.                     nextOffset = offset + (i / ConsumeQueue.CQ_STORE_UNIT_SIZE);
  54.                     // 剩余的延时时间
  55.                     long countdown = deliverTimestamp - now;
  57.                     if (countdown <= 0) {
  59.                         // 根据CommitLog物理偏移量找到msg
  60.                         MessageExt msgExt =
  61.                             ScheduleMessageService.this.defaultMessageStore.lookMessageByOffset(
  62.                                 offsetPy, sizePy);
  64.                         if (msgExt != null) {
  66.                             try {
  68.                                 // 解析消息体，取出真实的topic和queue（多为%RETRY% + consumerGroup）
  69.                                 MessageExtBrokerInner msgInner = this.messageTimeup(msgExt);
  70.                                 if (TopicValidator.RMQ_SYS_TRANS_HALF_TOPIC.equals(msgInner.getTopic())) {
  72.                                     log.error("[BUG] the real topic of schedule msg is {}, discard the msg. msg={}",
  73.                                             msgInner.getTopic(), msgInner);
  74.                                     continue;
  75.                                 }
  77.                                 // 将消息写入到commitLog中
  78.                                 PutMessageResult putMessageResult =
  79.                                     ScheduleMessageService.this.writeMessageStore
  80.                                         .putMessage(msgInner);
  82.                                 // 写入成功，跳过该次循环判断下一条延迟消息是否达到到期时间
  83.                                 if (putMessageResult != null
  84.                                     && putMessageResult.getPutMessageStatus() == PutMessageStatus.PUT_OK) {
  86.                                     log.info("send msg to real topic: {} from schedule topic: {}", msgInner.getTopic() ,msgExt.getTopic());
  87.                                     continue;
  88.                                 } else {
  90.                                     // XXX: warn and notify me
  91.                                     log.error(
  92.                                         "ScheduleMessageService, a message time up, but reput it failed, topic: {} msgId {}",
  93.                                         msgExt.getTopic(), msgExt.getMsgId());
  94.                                     // 写入消息失败，则延时10s重新执行TimerTask
  95.                                     ScheduleMessageService.this.timer.schedule(
  96.                                         new DeliverDelayedMessageTimerTask(this.delayLevel,
  97.                                             nextOffset), DELAY_FOR_A_PERIOD);
  98.                                     ScheduleMessageService.this.updateOffset(this.delayLevel,
  99.                                         nextOffset);
  100.                                     return;
  101.                                 }
  102.                             } catch (Exception e) {
  104.                                 /*
  105.                                  * XXX: warn and notify me
  109.                                  */
  110.                                 log.error(
  111.                                     "ScheduleMessageService, messageTimeup execute error, drop it. msgExt="
  112.                                         + msgExt + ", nextOffset=" + nextOffset + ",offsetPy="
  113.                                         + offsetPy + ",sizePy=" + sizePy, e);
  114.                             }
  115.                         }
  116.                     } else {
  118.                         // 这里说明，延时队列中最小到期的那条消息都还没到延迟时间
  120.                         // 重新提交一个TimerTask，延迟执行时间为延时队列中第一个消息剩余的延时时间
  121.                         ScheduleMessageService.this.timer.schedule(
  122.                             new DeliverDelayedMessageTimerTask(this.delayLevel, nextOffset),
  123.                             countdown);
  124.                         // 更新延时队列已消费的消息偏移量
  125.                         ScheduleMessageService.this.updateOffset(this.delayLevel, nextOffset);
  126.                         return;
  127.                     }
  128.                 } // end of for
  130.                 // 定时任务下一次开始读取延迟队列的offset
  131.                 nextOffset = offset + (i / ConsumeQueue.CQ_STORE_UNIT_SIZE);
  132.                 // 开始一个延时100ms执行的定时任务 消费延时队列
  133.                 ScheduleMessageService.this.timer.schedule(new DeliverDelayedMessageTimerTask(
  134.                     this.delayLevel, nextOffset), DELAY_FOR_A_WHILE);
  135.                 // 将下一次读取延迟队列的offset存放到一个缓存map中
  136.                 ScheduleMessageService.this.updateOffset(this.delayLevel, nextOffset);
  137.                 return;
  138.             } finally {
  141.                 bufferCQ.release();
  142.             }
  143.         } // end of if (bufferCQ != null)
  144.         else {
  147.             long cqMinOffset = cq.getMinOffsetInQueue();
  148.             if (offset < cqMinOffset) {
  150.                 failScheduleOffset = cqMinOffset;
  151.                 log.error("schedule CQ offset invalid. offset=" + offset + ", cqMinOffset="
  152.                     + cqMinOffset + ", queueId=" + cq.getQueueId());
  153.             }
  154.         }
  155.     } // end of if (cq != null)
  157.     ScheduleMessageService.this.timer.schedule(new DeliverDelayedMessageTimerTask(this.delayLevel,
  158.         failScheduleOffset), DELAY_FOR_A_WHILE);
  159. }

源码分析完了，我们来总结一下实现原理。

三、实现原理

消息的发送：

  1. producer设置消息的delayLevel延迟级别，并在消息属性DELAY中存储对应的延时级别；
  2. broker端收到消息后，判断延时消息延迟级别，如果大于0，则备份消息原始的topic和queueId，并将消息topic改为延时消息队列特定topic（SCHEDULE_TOPIC_XXXX），queueId改为（延时级别-1）。

消息的处理：

  1. MQ服务端（Broker）的ScheduleMessageService中，为每一个延迟级别分别开启一个定时器，定时(每隔1秒)从延迟级别对应的的ConsumeQueue消费队列中拉取消息；
  2. 然后根据消费偏移量offset从commitLog中解析出对应的消息；
  3. 从消息tagsCode属性中解析出消息应当被投递的时间，然后与当前时间做比较，判断是否应该进行投递（消息是否到期）；
  4. 若到达了投递时间（消息到期），则构建一个新的消息，从源消息属性中解析出出真实的topic和queueId，并清除消息的延迟属性；将其写入到CommitLog中；

四、对延时消息机制的思考

优点：

  • 设计简单，把所有相同延迟时间的消息都先放到一个队列中，做定时扫描，可以保证消息消费的有序性；
  • 延时队列中的消息时按消息到期时间进行递增排序，也就是说队列中消息越靠前的到期时间越早；

缺点：

  • 延时消息机制所有的定时任务都在一个定时器中，定时器采用的java.util.Timer，而Timer是单线程运行的；如果延迟消息的数量很大大的话，可能单线程处理不过来，也就会造成消息到期后没有及时发送出去的现象，甚至会造成消息拥堵；
    在这里插入图片描述

可能的改进点：

  • 为每个延迟队列上分别采用一个Timer;
  • 或者说仅使用Timer开始定时任务做扫描，而消息处理的核心逻辑使用线程池处理，进而提高消息处理的效率；

发表评论

表情：
评论列表 （有 0 条评论，164人围观）

还没有评论，来说两句吧...

相关阅读

    相关 RocketMQ进阶-延时消息

        前言 在开发中经常会遇到延时任务的需求，例如在12306购买车票，若生成订单30分钟未支付则自动取消；还有在线商城完成订单后48小时不评价 ，自动5星好评。像

    水深无声水深无声/ 0 赞/ 170 阅读