RocketMQ 5.x 引入了精准定时消息突破了 18 个等级的限制支持任意时间点的定时投递// 5.x 新特性精准定时消息Message msg new Message(“order_topic”, “内容”.getBytes());// 指定精确的投递时间戳毫秒msg.setDeliverTimeMs(System.currentTimeMillis() 30 * 60 * 1000); // 30 分钟后producer.send(msg);底层实现变化4.x 5.x18 个固定等级 支持任意时间点每个等级一个 Queue 基于 Timing Wheel时间轮 算法定时线程扫描 时间轮 多级时间轮高效调度适合固定延迟场景 适合任意定时场景时间轮定时消息槽位到期消息投递时间任意时间戳插入时间轮槽位时间轮每秒推进触发投递高效调度 O(1) 复杂度支持海量定时消息时间轮的优势可以处理任意时间点的定时消息不再受 18 个等级限制时间轮算法在调度大量定时任务时性能远优于传统的扫描方式支持取消定时消息通过消息 ID延迟消息的使用限制与最佳实践使用限制限制 说明❌ 不支持事务消息 延迟消息不能和事务消息组合使用❌ 不支持批量消息 批量消息不能设置延迟等级❌ 4.x 只支持 18 个等级 不能自定义延迟时间5.x 解决了❌ 消息投递后不可取消 一旦 Broker 调度投递无法撤回5.x 支持取消部分最佳实践评估延迟粒度如果只需要秒/分钟级别的延迟4.x 的 18 个等级通常够用5.x 新项目推荐使用定时消息更灵活支持取消避免过长的延迟 2 小时长时间延迟消息占用 Broker 存储建议采用外部调度方案监控延迟消息堆积延迟消息在 SCHEDULE_TOPIC_XXXX 中堆积需要监控其数量避免积压过多导致 Broker 内存压力十一、消息轨迹与消息查询消息轨迹的作用与配置开启消息轨迹Message Trace 记录了消息从生产到消费的完整链路是问题排查的利器。核心作用消息轨迹能回答的问题❓ 这条消息是谁发的❓ 什么时候发的❓ 发到了哪个 Broker❓ 被消费了吗❓ 谁消费的❓ 消费成功还是失败配置开启Broker 端配置broker.conf开启消息轨迹traceTopicEnabletrue轨迹数据存储的 Topic 名称默认msgTraceTopicNameRMQ_SYS_TRACE_TOPICProducer 端开启DefaultMQProducer producer new DefaultMQProducer(“producer_group”);producer.setEnableMsgTrace(true); // 开启轨迹producer.setMsgTraceTopic(“RMQ_SYS_TRACE_TOPIC”);Consumer 端开启DefaultMQPushConsumer consumer new DefaultMQPushConsumer(“consumer_group”);consumer.setEnableMsgTrace(true);consumer.setMsgTraceTopic(“RMQ_SYS_TRACE_TOPIC”);消息轨迹的数据采集与存储traceTopic消息轨迹通过 Hook 机制 无侵入地采集数据RMQ_SYS_TRACE_TOPICBrokerTrace HookProducerRMQ_SYS_TRACE_TOPICBrokerTrace HookProducer发送消息前触发 before记录发送开始时间、IP 等发送消息返回响应发送后触发 after记录耗时、结果将轨迹数据作为普通消息异步发送到 traceTopic轨迹数据内容字段 说明traceId 全局唯一追踪 IDmessageId 消息 IDkey 业务 Keytopic Topic 名称producerGroup 生产者组consumerGroup 消费者组sendTime 发送时间consumeTime 消费时间sendCost 发送耗时consumeCost 消费耗时clientIp 客户端 IPstatus 状态成功/失败errorMsg 错误信息
RocketMQ 5.x 的定时消息新特性（基于时间轮的精准定时）
RocketMQ 5.x 引入了精准定时消息突破了 18 个等级的限制支持任意时间点的定时投递// 5.x 新特性精准定时消息Message msg new Message(“order_topic”, “内容”.getBytes());// 指定精确的投递时间戳毫秒msg.setDeliverTimeMs(System.currentTimeMillis() 30 * 60 * 1000); // 30 分钟后producer.send(msg);底层实现变化4.x 5.x18 个固定等级 支持任意时间点每个等级一个 Queue 基于 Timing Wheel时间轮 算法定时线程扫描 时间轮 多级时间轮高效调度适合固定延迟场景 适合任意定时场景时间轮定时消息槽位到期消息投递时间任意时间戳插入时间轮槽位时间轮每秒推进触发投递高效调度 O(1) 复杂度支持海量定时消息时间轮的优势可以处理任意时间点的定时消息不再受 18 个等级限制时间轮算法在调度大量定时任务时性能远优于传统的扫描方式支持取消定时消息通过消息 ID延迟消息的使用限制与最佳实践使用限制限制 说明❌ 不支持事务消息 延迟消息不能和事务消息组合使用❌ 不支持批量消息 批量消息不能设置延迟等级❌ 4.x 只支持 18 个等级 不能自定义延迟时间5.x 解决了❌ 消息投递后不可取消 一旦 Broker 调度投递无法撤回5.x 支持取消部分最佳实践评估延迟粒度如果只需要秒/分钟级别的延迟4.x 的 18 个等级通常够用5.x 新项目推荐使用定时消息更灵活支持取消避免过长的延迟 2 小时长时间延迟消息占用 Broker 存储建议采用外部调度方案监控延迟消息堆积延迟消息在 SCHEDULE_TOPIC_XXXX 中堆积需要监控其数量避免积压过多导致 Broker 内存压力十一、消息轨迹与消息查询消息轨迹的作用与配置开启消息轨迹Message Trace 记录了消息从生产到消费的完整链路是问题排查的利器。核心作用消息轨迹能回答的问题❓ 这条消息是谁发的❓ 什么时候发的❓ 发到了哪个 Broker❓ 被消费了吗❓ 谁消费的❓ 消费成功还是失败配置开启Broker 端配置broker.conf开启消息轨迹traceTopicEnabletrue轨迹数据存储的 Topic 名称默认msgTraceTopicNameRMQ_SYS_TRACE_TOPICProducer 端开启DefaultMQProducer producer new DefaultMQProducer(“producer_group”);producer.setEnableMsgTrace(true); // 开启轨迹producer.setMsgTraceTopic(“RMQ_SYS_TRACE_TOPIC”);Consumer 端开启DefaultMQPushConsumer consumer new DefaultMQPushConsumer(“consumer_group”);consumer.setEnableMsgTrace(true);consumer.setMsgTraceTopic(“RMQ_SYS_TRACE_TOPIC”);消息轨迹的数据采集与存储traceTopic消息轨迹通过 Hook 机制 无侵入地采集数据RMQ_SYS_TRACE_TOPICBrokerTrace HookProducerRMQ_SYS_TRACE_TOPICBrokerTrace HookProducer发送消息前触发 before记录发送开始时间、IP 等发送消息返回响应发送后触发 after记录耗时、结果将轨迹数据作为普通消息异步发送到 traceTopic轨迹数据内容字段 说明traceId 全局唯一追踪 IDmessageId 消息 IDkey 业务 Keytopic Topic 名称producerGroup 生产者组consumerGroup 消费者组sendTime 发送时间consumeTime 消费时间sendCost 发送耗时consumeCost 消费耗时clientIp 客户端 IPstatus 状态成功/失败errorMsg 错误信息
