1.
2.
a.
3.
1.
2.
1.
2.
3.
4.
1.
2.
3.
4.
RabbitMQ延时消息实现方案
1. 问题背景
2. 目标
3. 总体方案
3.1. 实现原理
3.2. 技术方案
3.3. 消息发送流程
3.3.1. 原有业务流程
3.3.2. 自产自消的延迟消息流程
3.3.3. 普通的延迟消息流程
4. 操作步骤
4.1. 建立 delay.exchange
4.2. 建立延时队列(delay queue)
4.3. 配置延时路由规则
4.3.1. 需要延时的消息到exchange后先路由到指定的延时队列
4.3.2. delay.exchange 再重新把消息路由到正常的queue或exchang中
4.3.3. 消费者和以前一样从正常queue中接收消费消息
5. 积压消息测试结果
5.1. 积压测试结论
5.2. 40字节消息积压26万
5.3. 4字节消息积压7万
5.4. 4字节消息积压24万
5.5. 4字节消息积压31万
5.6. 4字节消息积压64万
6. 注意事项
1. 问题背景
所谓"延时消息"是指当消息被发送以后,并不想让消费者立即拿到消息,而是等待指定时间后,消费者才拿到这个消息进行消费。
场景一:客户A在十二点下了一个订单,我想半个小时后来检查一下这个订单的付款状态,根据付款状态来作下一步的处理。
针对场景一,建议采用方案数据库保存+schedule的方式也许更合适。
场景二:mdc系统更新了一个A门店信息,我要通知给主站和移动A门店信息发生了变化,通知他们回调API来读取门店最新的值。
如果主站立即拿到消息后回调,可能因为mdc事务、缓存、从库延迟等原因,拿到 的门店信息,所以mdc希望主站能延迟一段时间变化前
再来消费此消息。
2. 目标
可以实现消息按照自定义的时间延迟发送。
最好做到对消息生产者和消费者透明,不修改现有应用程序。
3. 总体方案
3.1. 实现原理
AMQP和RabbitMQ本身没有直接支持延迟队列功能,但是可以通过以下特性模拟出延迟队列的功能。
RabbitMQ可以针对Queue和Message设置 x-message-tt ,来控制消息的生存时间,如果超时,则消息变为dead letterl
RabbitMQ的Queue可以配置x-dead-letter-exchange 和 x-dead-letter-routing-key(可选)两个参数,用来控制队列内出现了dead
letter,则按照这两个参数重新路由。
结合以上两个特性,就可以模拟出延迟消息的功能。
参考资料:
https://www.cloudamqp.com/docs/delayed-messages.html
http://www.rabbitmq.com/ttl.html
http://www.rabbitmq.com/dlx.html
http://www.rabbitmq.com/maxlength.html
3.2. 技术方案
评论1