为什么说ROcketMQ更适用于业务型的消息中间件，因为它能够保证消息不丢失且带有事务消息。

先来看一张RocketMQ集群部署结构

其中Name Server主要是提供路由信息，这里暂时忽略，大致流程为：
Producer(生产者生产消息) --> Broker(存储消息) --> Consumer(消费消息)
接下来我们通过这分析者三个节点来具体说明：

Producer（生产者生产消息）

1. 默认情况下可以通过同步的方式发送消息，然后检查发送状态，如果是OK，就一定发送到了Broker，否则会触发默认的2次重试，这里可能成功也可能没成功，可以代码处理
2. 采用事务消息TransactionMQProducer方式发送消息，不能保证一定发送到Broker（事务回滚）；但如果发送Consumer时返回Ack失败的话，会保存在CommitLog中，不能算完全丢失
3. RocketMQ支持日志的索引，如果一条消息发送之后超时，可以通过查询日志的API来检查是否在Broker存储成功

Broker（存储消息）

1. 消息支持持久化到CommitLog中，即使宕机重启，也可以保证消息不会丢失
2. Broker支持同步或异步刷盘策略，可以保证接收到的消息一定存储在本地文件中
3. Broker集群中支持1主N从策略，支持同步双写、异步复制，其中同步双写可以保证即使Master磁盘崩溃，消息不会丢失（在从节点有相同的备份）

Consumer（消费消息）

1. Consumer自身维护一个持久化的offset（对应MessageQueue里面的min offset），标记已成功消费或发回Broker消息的下标
2. 如果Consumer消息消费失败，会将消息发回到Broker，然后更新自己的offset
3. 如果在消息发回到Broker过程中Broker挂了，Consumer会定时重试这个操作
4. 如果Broker和Consumer同时挂了，消息也不会丢失（CommitLog和持久化offset），在重启恢复后继续从offset继续消费消息

总结

总结来说就是：多次重试+持久化+offset+主从备份 来保证消息不丢失