RocketMQ保證訊息不丟失

分別從producer傳送機制、broker的持久化機制，以及消費者的offset機制來最大程度保證訊息不易丟失

從producer的視角來看：如果訊息未能正確的儲存在mq中，或者消費者未能正確的消費到這條訊息，都是訊息丟失。

從broker的視角來看：如果訊息已經存在broker裡面了，如何保證不會丟失呢（宕機、磁碟崩潰）

從consumer的視角來看：如果訊息已經完成持久化了，但是consumer取了，但是未消費成功且沒有反饋，就是訊息丟失

從producer分析：如何確保訊息正確的傳送到了broker?

預設情況下，可以通過同步的方式阻塞式的傳送，check sendstatus，狀態是ok，表示訊息一定成功的投遞到了broker，狀態超時或者失敗，則會觸發預設的2次重試。此方法的傳送結果，可能broker儲存成功了，也可能沒成功

採取事務訊息的投遞方式，並不能保證訊息100%投遞成功到了broker，但是如果訊息傳送ack失敗的話，此訊息會儲存在commitlog當中，但是對consumerqueue是不可見的。可以在日誌中檢視到這條異常的訊息，嚴格意義上來講，也並沒有完全丟失

rocketmq支援日誌的索引，如果一條訊息傳送之後超時，也可以通過查詢日誌的api，來check是否在broker儲存成功

從broker分析：如果確保接收到的訊息不會丟失?

訊息支援持久化到commitlog裡面，即使宕機後重啟，未消費的訊息也是可以載入出來的

broker自身支援同步刷盤、非同步刷盤的策略，可以保證接收到的訊息一定儲存在本地的記憶體中

broker集群支援 1主n從的策略，支援同步複製和非同步複製的方式，同步複製可以保證即使master 磁碟崩潰，訊息仍然不會丟失

從cunmser分析：如何確保拉取到的訊息被成功消費？

消費者可以根據自身的策略批量pull訊息

consumer自身維護乙個持久化的offset（對應messagequeue裡面的min offset），標記已經成功消費或者已經成功發回到broker的訊息下標

如果consumer消費失敗，那麼它會把這個訊息發回給broker，發回成功後，再更新自己的offset

如果consumer消費失敗，發回給broker時，broker掛掉了，那麼consumer會定時重試這個操作

如果consumer和broker一起掛了，訊息也不會丟失，因為consumer 裡面的offset是定時持久化的，重啟之後，繼續拉取offset之前的訊息到本地