为什么开源的RocketMQ没有支持任意精度的延时消息

写在前面

在我们日常的开发中，经常会遇到这样"在一段时间之后，触发某一个事件"的业务场景。如：

• 电商平台下单后30分钟不支付订单自动取消
• 红包24小时不领取自动退还

常见的解决方案

1.定时扫描

事先记录事件的触发时间点，定时任务不停查数据库对比触发时间。

这种方式不实时，随着定时任务的执行频率变高，触发实时性会有所提升，但是频繁地扫描增加了数据库的压力，也是最简单的做法。

2.jdk的解决方案

jdk为我们提供的定时器Timer，延时队列DelayQueue。

这种方式在单机，对可靠性要求不高的环境下是可以使用的，任务和队列都存在于jvm内存中，所以不支持分布式的环境，系统突然宕机后也无法恢复。

3.消息中间件的延时消息

生产者投递延时消息，消费者在规定时间后才能消费此消息，这样对于我们业务开发而言，只需要关注刚刚过期的那一条消息即可。

世面上成熟的消息中间件有很多，作为一个java开发人员，我倾向于开源的rocketmq，因为其他的消息中间件对于我都是一个黑盒，在rocketmq中，遇到了问题、疑惑，你甚至可以拿着源码debug。

初识rocketmq延时消息

使用官方提供的生产者投递消息api

可以看到，官方为我们提供的方法是setDelayTimeLevel(),并不是一个自定义的延时时间。
对于这个地方的设计我感到十分不解，于是便有了这篇文章。对于图中的延时级别‘5’只是随便设置的一个级别（对应一分钟），后文会有详细的解析。

投递完成后，立马打开控制台查看

该topic中四个队列所对应的消费位点没有发生变化，故此时订阅该topic的消费者是无法立刻消费到这条消息的

在等待延时之后

发现该条消息出现在此topic中，而且时间点刚好为我投递时间的后一分钟

猜想

从外部的表现形式来看，延时消息并没有直接投递到对应的topic中，而是在生产者和topic之间经历了某种“中转”，生产者投递延时消息到这个“中转站”，存在其他的任务从这个“中转站”中取出到期的消息发送给topic。

源码debug分析

• 关于如何在idea中运行RocketMQ

小贴士：这里如果顺着生产者的send()方法可能不太容易找，层级很多，而设置延时级别为Message类的setDelayTimeLevel()，反推肯定有地方调用Message中的getDelayTimeLevel(),在几处调用getDelayTimeLevel()方法的地方打上断点，就找到延时的处理逻辑了。

生产者投递CommitLog.java

将带有延时级别的普通消息直接丢到“中转站”——一个名为SCHEDULE_TOPIC_XXXX的特殊队列

public PutMessageResult putMessage(final MessageExtBrokerInner msg) {
    ...
    if (msg.getDelayTimeLevel() > 0) {
        //延时消息处理逻辑
        if (msg.getDelayTimeLevel() > this.defaultMessageStore.getScheduleMessageService().getMaxDelayLevel()) {
            //如果延时级别大于最大值，则置为最大值
            msg.setDelayTimeLevel(this.defaultMessageStore.getScheduleMessageService().getMaxDelayLevel());
        }
        //一个名为“SCHEDULE_TOPIC_XXXX”的特殊topic常量名
        topic = ScheduleMessageService.SCHEDULE_TOPIC;
        //队列号为delayLevel - 1(延时级别减1)
        queueId = ScheduleMessageService.delayLevel2QueueId(msg.getDelayTimeLevel());
    
        // Backup real topic, queueId
        //将消息的真实topic和queueId设置为其他属性保存
        MessageAccessor.putProperty(msg, MessageConst.PROPERTY_REAL_TOPIC, msg.getTopic());
        MessageAccessor.putProperty(msg, MessageConst.PROPERTY_REAL_QUEUE_ID, String.valueOf(msg.getQueueId()));
        msg.setPropertiesString(MessageDecoder.messageProperties2String(msg.getProperties()));
        //重新设置消息的topic为“SCHEDULE_TOPIC_XXXX”
        msg.setTopic(topic);
        msg.setQueueId(queueId);
    }
    ...
}

这个SCHEDULE_TOPIC_XXXX的特殊topic“中转站”我们在console控制台是无法查看到的，但是在我们的持久化目录store却存在，如图，队列号为4，正好对应延时级别减1（5-1=4），与我们源码分析的一致。

延时逻辑处理ScheduleMessageService.java

1.设置延时等级与延时时长的对应关系parseDelayLevel()

public boolean parseDelayLevel() {
        HashMap<String, Long> timeUnitTable = new HashMap<String, Long>();
        timeUnitTable.put("s", 1000L);
        timeUnitTable.put("m", 1000L * 60);
        timeUnitTable.put("h", 1000L * 60 * 60);
        timeUnitTable.put("d", 1000L * 60 * 60 * 24);
        //不同延时时间的字符串
        //String levelString = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h"
        String levelString = this.defaultMessageStore.getMessageStoreConfig().getMessageDelayLevel();
        try {
            String[] levelArray = levelString.split(" ");
            for (int i = 0; i < levelArray.length; i++) {
                String value = levelArray[i];
                String ch = value.substring(value.length() - 1);
                Long tu = timeUnitTable.get(ch);

                int level = i + 1;
                if (level > this.maxDelayLevel) {
                    this.maxDelayLevel = level;
                }
                long num = Long.parseLong(value.substring(0, value.length() - 1));
                long delayTimeMillis = tu * num;
                //存放延时级别与延时时长的对应关系
                this.delayLevelTable.put(level, delayTimeMillis);
            }
        } catch (Exception e) {
            log.error("parseDelayLevel exception", e);
            log.info("levelString String = {}", levelString);
            return false;
        }

        return true;
    }

2.为每一个延时级别设定单独的轮循任务start()

public void start() {
    //cas乐观锁保证线程安全
    if (started.compareAndSet(false, true)) {
        this.timer = new Timer("ScheduleMessageTimerThread", true);
        for (Map.Entry<Integer, Long> entry : this.delayLevelTable.entrySet()) {
            //遍历延时级别
            Integer level = entry.getKey();
            Long timeDelay = entry.getValue();
            Long offset = this.offsetTable.get(level);
            if (null == offset) {
                offset = 0L;
            }

            if (timeDelay != null) {
                //为每一个延时级别创建一个分发延时消息任务，首次启动延迟1s
                this.timer.schedule(new DeliverDelayedMessageTimerTask(level, offset), FIRST_DELAY_TIME);
            }
        }
        /* 持久化任务 */
        ...
    }
}

分发延时消息DeliverDelayedMessageTimerTask.java

“中转站”的延时消息到期后，转化为普通消息投递至目标topic：

public void executeOnTimeup() {
    /* 从SCHEDULE_TOPIC_XXXX中获取对应特定延时等级的消息 */
    ...
    //当前时间
    long now = System.currentTimeMillis();
    //消息经过延时后应该被发送的真实时间
    long deliverTimestamp = this.correctDeliverTimestamp(now, tagsCode);

    nextOffset = offset + (i / ConsumeQueue.CQ_STORE_UNIT_SIZE);
    //还需要等待的时间
    long countdown = deliverTimestamp - now;
     if (countdown <= 0) {
        //已经到期无需等待
        MessageExt msgExt =
            ScheduleMessageService.this.defaultMessageStore.lookMessageByOffset(
                offsetPy, sizePy);

        if (msgExt != null) {
            try {
                //将延时消息转化为普通消息（还记得上文`CommitLog.java`中将普通消息转化为了延时消息么）
                MessageExtBrokerInner msgInner = this.messageTimeup(msgExt);
                //将消息发送至目的地topic
                PutMessageResult putMessageResult = ScheduleMessageService.this.writeMessageStore
                                                        .putMessage(msgInner);
                if (putMessageResult != null
                    && putMessageResult.getPutMessageStatus() == PutMessageStatus.PUT_OK) {
                    continue;
                } else {
                    // XXX: warn and notify me
                    //错误重试
                    log.error(
                        "ScheduleMessageService, a message time up, but reput it failed, topic: {} msgId {}",
                        msgExt.getTopic(), msgExt.getMsgId());
                    ScheduleMessageService.this.timer.schedule(
                        new DeliverDelayedMessageTimerTask(this.delayLevel,
                            nextOffset), DELAY_FOR_A_PERIOD);
                    ScheduleMessageService.this.updateOffset(this.delayLevel,
                        nextOffset);
                    return;
                }
            } catch (Exception e) {
                log.error(
                    "ScheduleMessageService, messageTimeup execute error, drop it. msgExt="
                        + msgExt + ", nextOffset=" + nextOffset + ",offsetPy="
                        + offsetPy + ",sizePy=" + sizePy, e);
            }
        }
    } else {
        //countdown>0，即消息还未过期，即还需要等待countdown毫秒
        //延期countdown毫秒进行递归，这里设计的很巧妙，直接延期到消息发送的时间点，就不用反复判断是否过期了
        ScheduleMessageService.this.timer.schedule(
            new DeliverDelayedMessageTimerTask(this.delayLevel, nextOffset),
            countdown);
        ScheduleMessageService.this.updateOffset(this.delayLevel, nextOffset);
        return;
    }
    ...
    // 没有找到延时消息,则延时0.1s再次启动该定时器递归 
    ScheduleMessageService.this.timer.schedule(new DeliverDelayedMessageTimerTask(this.delayLevel,
                failScheduleOffset), DELAY_FOR_A_WHILE);
}

综上所述

总结

• 在生产者与目的地topic之间增加了一层“中转站”—名为SCHEDULE_TOPIC_XXXX的topic
• 这个特殊的topic中默认存在18个queue，分别对应不同的延时级别
• topic中的每一个queue都会存在一个检测queue中消息是否到期的任务，如果到期，则投递给最终目的地topic

特性

• 1.将所有消息以延时级别分区，提高了文件的查找性能

好处：目录多了肯定方便文件查找，对文件读写的定位速度都有提升。

• 2.对每一个级别的分区目录来说，根据延时时间从小到大维护了一个有序队列

好处：对于同一级别，新增的消息的延时一定是最大的，放在队列的最末尾，我们只需要关注队列最前面的那一条，因为最前面的最先到期（保证延时触发的实时性）。读队列头，新增的消息追加在最末尾（顺序读写提升性能）。

猜想

• 如果支持了任意的精度

则无论以什么标准来对消息进行分区，都无法保证分区队列中的消息顺序读写（在这个文件模型且不引入其他的中间件情况下）。

综上所述：RocketMQ延时消息考虑到不同延时的消息持久化后的读写性能与延时触发的实时性，引入了“延时等级”这种平衡性能与实时性的方案

讨论

本人也不是什么技术大牛，只能根据代码逻辑猜测设这样计的好处，以及不这样设计有没其他的设计，是否可行，如果你有其他的方案，欢迎留言讨论。

其他文章推荐

• 带你搭建自己的分布式消息推送系统