延迟消息是实际开发中一个非常有用的功能，本文第一部分从整体上介绍秒级精度延迟消息的实现思路，在第二部分结合RocketMQ的延迟消息实现，进行细致的讲解，点出关键部分的源码。第三步介绍延迟消息与消息重试的关系。

1 延迟消息介绍

基本概念：延迟消息是指生产者发送消息发送消息后，不能立刻被消费者消费，需要等待指定的时间后才可以被消费。场景案例：用户下了一个订单之后，需要在指定时间内(例如30分钟)进行支付，在到期之前可以发送一个消息提醒用户进行支付。 Broker端内置延迟消息处理能力，核心实现思路都是一样：将延迟消息通过一个临时存储进行暂存，到期后才投递到目标Topic中。如下图所示：

步骤说明如下：

1.producer要将一个延迟消息发送到某个Topic中

2.Broker判断这是一个延迟消息后，将其通过临时存储进行暂存。

3.Broker内部通过一个延迟服务(delay service)检查消息是否到期，将到期的消息投递到Topic中这个的延迟服务名字为delay service，不同消息中间件的延迟服务模块名称可能不同。

4.消费者消费目标topic中的延迟投递的消息

显然，临时存储模块和延迟服务模块，是延迟消息实现的关键。上图中，临时存储和延迟服务都是在Broker内部实现，对业务透明。

此外，还有一些消息中间件原生并不支持延迟消息，如Kafka。在这种情况下，可以选择对Kafka进行改造，但是成本较大。另外一种方式是使用第三方临时存储，并加一层代理。第三方存储选型要求：对于第三方临时存储，其需要满足以下几个特点：

高性能：写入延迟要低，MQ的一个重要作用是削峰填谷，在选择临时存储时，写入性能必须要高，关系型数据库(如Mysql)通常不满足需求。

高可靠：延迟消息写入后，不能丢失，需要进行持久化，并进行备份支持排序：支持按照某个字段对消息进行排序，对于延迟消息需要按照时间进行排序。

普通消息通常先发送的会被先消费，延迟消息与普通消息不同，需要进行排序。例如先发一条延迟10s的消息，再发一条延迟5s的消息，那么后发送的消息需要被先消费。支持长时间保存：一些业务的延迟消息，需要延迟几个月，甚至更长，所以延迟消息必须能长时间保留。不过通常不建议延迟太长时间，存储成本比较大，且业务逻辑可能已经发生变化，已经不需要消费这些消息。例如，滴滴开源的消息中间件DDMQ，底层消息中间件的基础上加了一层代理，独立部署延迟服务模块，使用rocksdb进行临时存储。rocksdb是一个高性能的KV存储，并支持排序。

2 RocketMQ中的延迟消息

开源RocketMQ支持延迟消息，但是不支持秒级精度。默认支持18个level的延迟消息，这是通过broker端的messageDelayLevel配置项确定的，如下：

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

Broker在启动时，内部会创建一个内部主题：SCHEDULE_TOPIC_XXXX，根据延迟level的个数，创建对应数量的队列，也就是说18个level对应了18个队列。注意，这并不是说这个内部主题只会有18个队列，因为Broker通常是集群模式部署的，因此每个节点都有18个队列。

延迟级别的值可以进行修改，以满足自己的业务需求，可以修改/添加新的level。例如：你想支持2天的延迟，修改最后一个level的值为2d，这个时候依然是18个level；也可以增加一个2d，这个时候总共就有19个level。

可以看到这里并不支持秒级精度，按照《rocketmq developer guide》中的说法，是为了避免在broker对消息进行排序，造成性能影响。不过笔者考虑，之所以不支持，更多应该是商业上的考虑。

生产者发送延迟消息：

生产者在发送延迟消息非常简单，只需要设置一个延迟级别即可，注意不是具体的延迟时间，如：

Message msg=new Message();
msg.setTopic("TopicA");
msg.setTags("Tag");
msg.setBody("this is a delay message".getBytes());
//设置延迟level为5，对应延迟1分钟
msg.setDelayTimeLevel(5);producer.send(msg);

消息延迟消息实现原理

2 RocketMQ中的延迟消息