问一个消息队列的问题

sinat_38008319 2017-03-21 10:15:28

当我用消息队列，系统A通知系统B做某些事情并且需要B做完之后通知A时，消息正确传递给了系统B，但因为某种状况，B失去了响应，这个时候应该怎么办？

...全文

183 2 打赏收藏转发到动态举报

写回复

2 条回复

切换为时间正序

请发表友善的回复…

发表回复

yql1986 2017-03-22

打赏
举报

回复

你这是属于事务性的消息，即消息必须100%发送到消息方且100%被消费。可以看一下曾宪杰写的一本书，书名如下。书中有一章节是专门用来介绍消息中间件的，其中就有你提到的这种场景《《大型网站系统与Java中间件实践》》

tianfang 2017-03-22

打赏
举报

回复

这个是业务级问题，要做异常处理业务逻辑

1.最重要的一个，默认publisher(task) 未报错即代表消息已经推送到了消息队列中，但是实际上神秘小故障有可能导致实际上消息队列并没有成功收到(具体故障可以问AI)，因此我们需要使用消息队列自带的Publisher Confirm机制，来确保消息队列确实收到了消息，再修改DB状态。2.如果发送消息成功，但是由于神秘小故障，导致进程在修改outbox表的状态前就挂掉了，会导致下次publisher再次扫描该表，导致同一个消息被多次生产，这个问题作者目前没找到比较轻量的解决方案。

探讨消息队列在微服务架构中的应用，包括异步处理、解耦和削峰填谷的作用，以及引入消息队列带来的系统复杂性、数据一致性和可用性挑战。

本文深入探讨了消息队列的核心概念、应用场景、解决消息丢失和顺序性问题的方法，以及如何处理消息积压。此外，还讨论了Kafka、RocketMQ和RabbitMQ的选型对比，以及如何设计高可用的消息中间件。重点强调了事务消息在确保数据一致性中的作用，并提出了设计消息队列架构的思考方向。

本文深入探讨了消息队列的核心概念、应用场景、解决消息丢失和顺序性问题的方法，以及如何处理消息积压。介绍了Kafka、RocketMQ和RabbitMQ的优缺点，并讨论了消息中间件的高可用设计和事务消息实现。此外，还分享了设计消息队列架构的关键考量点，包括流程、持久化、消费确认和扩展性。

本文围绕消息队列面试展开，介绍使用消息队列的好处，如解耦、异步、削峰，也指出其缺点，如降低系统可用性等。还对比了Kafka、ActiveMQ等优缺点，阐述保证高可用、消息不重复消费等方法，以及解决消息队列延时、过期失效等问题的策略，最后提及消息队列架构设计思路。

51,408

社区成员

86,090

社区内容

发帖

与我相关

我的任务

javaspring bootspring cloud 技术论坛（原bbs）

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章