为什么说ROcketMQ更适用于业务型的消息中间件，因为它能够保证消息不丢失且带有事务消息。
先来看一张RocketMQ集群部署结构
其中Name Server主要是提供路由信息，这里暂时忽略，大致流程为：
Producer(生产者生产消息) –> Broker(存储消息) –> Consumer(消费消息)
接下来我们通过这分析者三个节点来具体说明：
Producer（生产者生产消息）
- 默认情况下可以通过同步的方式发送消息，然后检查发送状态，如果是OK，就一定发送到了Broker，否则会触发默认的
2次重试，这里可能成功也可能没成功，可以代码处理 - 采用事务消息TransactionMQProducer方式发送消息，不能保证一定发送到Broker（事务回滚）；但如果发送Consumer时返回Ack失败的话，会
保存在CommitLog中，不能算完全丢失 - RocketMQ支持日志的索引，如果一条消息发送之后超时，可以通过
查询日志的API来检查是否在Broker存储成功
Broker（存储消息）
- 消息支持
持久化到CommitLog中，即使宕机重启，也可以保证消息不会丢失 - Broker支持同步或异步
刷盘策略，可以保证接收到的消息一定存储在本地文件中 - Broker集群中支持
1主N从策略，支持同步双写、异步复制，其中同步双写可以保证即使Master磁盘崩溃，消息不会丢失（在从节点有相同的备份）
Consumer（消费消息）
- Consumer自身维护一个持久化的
offset（对应MessageQueue里面的min offset），标记已成功消费或发回Broker消息的下标 - 如果Consumer消息消费失败，会将消息
发回到Broker，然后更新自己的offset - 如果在消息发回到Broker过程中Broker挂了，Consumer会
定时重试这个操作 - 如果Broker和Consumer同时挂了，消息也不会丢失（CommitLog和持久化offset），在重启恢复后继续从offset继续消费消息
总结
总结来说就是：多次重试+持久化+offset+主从备份 来保证消息不丢失
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/17858.html
