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 爲消息訂閱構建的索引文件，用來提高根據主題與消息隊列檢索消息的速度，這個就不細說了。