文章首发到公众号:月伴飞鱼
文章内容收录到个人网站,方便阅读:hardyfish.top/
文章内容收录到个人网站,方便阅读:hardyfish.top/
觉得有收获,希望帮忙点赞,转发下哈,谢谢,谢谢!
资料分享
RocketMQ技术内幕:
- 资料链接:url81.ctfile.com/f/57345181-…
- 访问密码:3899
什么是延时消息?
❝
指的是当消息写入到
Broker
后,不能立刻被消费者消费,需要等待指定的时长后才可被消费处理的消息。
延时消息等级
❝
RocketMQ
延时消息的延迟时长不支持随意时长的延迟。
- 是通过特定的延迟等级来指定的。
默认支持18个等级的延迟消息。
延时等级定义在RocketMQ
服务端的MessageStoreConfig
类中的如下变量中:
// MessageStoreConfig.java
private String messageDelayLevel = "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。
发消息时,设置delayLevel
等级即可:msg.setDelayLevel(level)
。
❝
例如指定的延时等级为3,则表示延迟时长为10s,延迟等级是从1开始计数的。
使用场景
❝
1、电商交易系统的订单超时未支付,自动取消订单。
2、超时自动审批,系统审批流程可以设置为超过设定时间后自动执行通过或者拒绝流程。
3、限时优惠活动,商品需要促销,在活动开始时,发送一个两小时后触发的定时消息,用于在活动结束时恢复原价。
为什么不支持任意时间
❝
按照《RocketMQ Developer Guide》中的说法:
- 如果提供任意时间,就会涉及到消息的排序,会有一定的性能损耗。
而
RocketMQ
这种利用固定延迟级别到单个队列的实现方式是一种妥协,灵活性和极致性能的妥协。
延迟消息与消费重试的关系
❝
消息重试的16个级别,实际上是把延迟消息18个级别的前两个
Level
去掉了。事实上,
RocketMQ
的消息重试也是基于延迟消息来完成的。
- 在消息消费失败的情况下,将其重新当做延迟消息投递回
Broker
。在投递回去时,会跳过前两个
Level
,因此只重试16次。详细内容可以看我之前的文章!!!
实现原理
❝
RocketMQ
延时消息会暂存在名为SCHEDULE_TOPIC_XXXX
的Topic
中。
- 并根据
delayTimeLevel
存入特定的Queue
。
queueId = delayTimeLevel – 1
:即一个Queue
只存相同延迟的消息,保证具有相同发送延迟的消息能够顺序消费。
Broker
会调度地消费SCHEDULE_TOPIC_XXXX
,将消息写入真实的Topic
。
主要步骤:
修改消息Topic
名称和队列信息:
❝
RocketMQ Broker
端在存储生产者写入的消息时,首先都会将其写入到CommitLog
中。之后根据消息中的
Topic
信息和队列信息,将其转发到目标Topic
的指定队列(ConsumeQueue
)中。由于消息一旦存储到
ConsumeQueue
中,消费者就能消费到,而延迟消息不能被立即消费。所以将
Topic
的名称修改为SCHEDULE_TOPIC_XXXX
,并根据延迟级别确定要投递到哪个队列下。
- 同时,还会将消息原来要发送到的目标
Topic
和队列信息存储到消息的属性中。
转发消息到延迟主题SCHEDULE_TOPIC_XXXX
的CosumeQueue
中:
❝
CommitLog
中的消息转发到CosumeQueue
中是异步进行的。在转发过程中,会对延迟消息进行特殊处理,主要是计算这条延迟消息需要在什么时候进行投递。
- 投递时间 = 消息存储时间(
StoreTimestamp
) + 延迟级别对应的时间。
延迟服务消费SCHEDULE_TOPIC_XXXX
消息:
❝
Broker
内部有一个ScheduleMessageService
类,其充当延迟服务。
- 主要是消费
SCHEDULE_TOPIC_XXXX
中的消息,并投递到目标Topic
中。
ScheduleMessageService
在启动时,其会创建一个定时器Timer
,并根据延迟级别的个数,启动对应数量的TimerTask
。
每个
TimerTask
负责一个延迟级别的消费与投递。
- 如果可以投放,则在投放到原本的目的
Topic
。- 每隔
100ms
,从TopicSCHEDULE_TOPIC_XXXX
判断18个队列里的第一个消息是否可以被投放。需要注意
每个
TimeTask
在检查消息是否到期时:
- 首先检查对应队列中尚未投递第一条消息。
- 如果这条消息没到期,那么之后的消息都不会检查。
- 如果到期了,则进行投递,并检查之后的消息是否到期。
将信息重新存储到CommitLog
中:
❝
在将消息到期后,需要投递到目标
Topic
。由于在第一步已经记录了原来的
Topic
和队列信息,因此这里重新设置,再存储到CommitLog
即可。
将消息投递到目标Topic
中:
❝
由于消息的
Topic
名称已经改为了目标Topic
。因此消息会直接投递到目标
Topic
的ConsumeQueue
中,之后消费者即消费到这条消息。
消费者消费目标Topic
中的数据。