1、可以从三个方面来分析rocket的消息可靠性
2、Producer端消息丢失
- 首先消息分为普通消息（同步，异步，单向发送），定时延时消息，顺序消息（不能保证全局有序，只能保证同一个quen中有序），事物消息
- producer端防止消息发送失败，可以采用同步阻塞式的发送（也就是发送同步消息），同步的检查Brocker返回的状态是否持久化成功，发送超时或者失败，则会默认重试2次，rocker选择了确保消息一定发送成功，但有可能发生重复投递
- 如果是异步发送消息，会有一个回调接口，当brocker存储成功或者失败的时候，也可以在这里根据返回状态来决定是否需要重试（当然这个是需要我们自己来实现的）
3、Brocker端消息丢失
- rocketmq一般都是先把消息写到PageCache中，然后再持久化到磁盘上，数据从pagecache刷新到磁盘有两种方式，同步和异步
- 同步刷盘方式：消息写入内存的 PageCache后，立刻通知刷盘线程刷盘，然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，返回消息写成功的状态。这种方式可以保证数据绝对安全，但是吞吐量不大。
- 异步刷盘方式（默认）：消息写入到内存的 PageCache中，就立刻给客户端返回写操作成功，当 PageCache中的消息积累到一定的量时，触发一次写操作，将 PageCache中的消息写入到磁盘中。这种方式吞吐量大，性能高，但是 PageCache中的数据可能丢失，不能保证数据绝对的安全。
4、Cousmer端消息丢失
- cousmer端默认是消息之后自动返回消费成功确认ack,但是这时如果我们的程序执行失败了，数据不就丢失了吗？
- 所以我们可以将自动提交（AutoCommit）消费响应，设置为在代码中手动提交，只有真正消费成功之后再通知brocker消费成功，然后更新消费唯一offset或者删除brocker中的消息
5、rocket持久化原理
- 现代的磁盘都是高性能的，写速度并不一定比网络的数据传输速度慢。比如 SSD 固态硬盘在 M.2 NVMe协议下，顺序写的速度可以达到 1500 MB/s，就算是普通磁盘，如果性能比较高的话，顺序写的速度可以达到 450MB/s~600MB/s。但是这是顺序写的速度。
- 但实际上磁盘采用的是随机写，在随机写的情况下，磁盘的写入速度急速下降，磁盘的随机写速度可能只有几百KB/s，这远远要慢于网络传输速度，所以它并不能满足高性能的要求。
- RocketMQ 在持久化的设计上，采取的是消息顺序写、随机读的策略，利用磁盘顺序写的速度，让磁盘的写速度不会成为系统的瓶颈。并且采用 MMPP 这种“零拷贝”技术，提高消息存盘和网络发送的速度。极力满足 RocketMQ 的高性能、高可靠要求。
- 在 RocketMQ 持久化机制中，涉及到了三个角色：
- CommitLog：消息真正的存储文件，所有消息都存储在 CommitLog 文件中。
- ConsumeQueue：消息消费逻辑队列，类似数据库的索引文件。
- IndexFile：消息索引文件，主要存储消息 Key 与 offset 对应关系，提升消息检索速度。
- 写入：CommitLog -->文件是存放消息数据的地方，所有的消息都将存入到 CommitLog 文件中。生产者将消息发送到 RocketMQ 的 Broker 后，Broker 服务器会将消息顺序写入到 CommitLog 文件中，这也就是 RocketMQ 高性能的原因，因为我们知道磁盘顺序写特别快，RocketMQ 充分利用了这一点，极大的提高消息写入效率。
- 读取：Queue-->但是同一主题的消息在 CommitLog 文件中可能是不连续的，那么消费者消费消息的时候，需要将 CommitLog 文件加载到内存中遍历查找订阅主题下的消息，频繁的 IO 操作，性能就会急速下降。为了解决这个问题，RocketMQ 引入了 Queue 文件。Queue 文件可以看作是索引文件，类似于 MySQL 中的二级索引。在存放了同一主题下的所有消息，消费者消费的时候只需要去对应的 Queue 组中取消息即可。Queue 文件不会存储消息的全量信息，了解 MySQL 索引的话，应该好理解这里，
- 由于 Queue 文件内容小，可以尽可能的保证 Consumequeue 文件全部读入到内存，提高消费效率。
- Queue 文件也是会持久化的，不存全量信息可以节约磁盘空间。
- IndexFile 是 RocketMQ 为消息订阅构建的索引文件，用来提高根据主题与消息队列检索消息的速度，这个就不细说了。