本文介绍了如何利用RabbitMQ的Dead Letter特性来解决业务中的延时处理问题，以避免服务F2先消费取消订单消息M2再消费新增订单消息M1的情况。通过设置Dead Letter队列，确保消息在特定时间后被处理，从而实现延时发送。同时，提供了Spring配置Dead Letter的示例代码。
在我们实际业务中,经常会碰到需要延时处理的问题.例如A操作5分钟后触发B操作.这些也可以使用定时器来实现.
考虑以下情况.
1.客户端提交订单A.
2.服务端F新增订单A,通过Rabbitmq发送新增订单消息M1到服务F2.返回新增成功到客户端(M模块不影响主业务).
3.客户端收到新增成功后,取消订单A.
4.服务端F取消订单A,发送取消订单消息M2到模块M
5.偶尔出现服务F2先消费M2,再消费M1的情况.
上面5里面出现的问题怎么解决呢?
1)保证有序性
1.M1,M2使用同一个queue, 发送到queue的有序性得到保证.
2.M1,M2使用同一个consumer, queue到消费者的有序性得到保证.
2)M2更新操作延时处理
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
