概述
分別從Producer發(fā)送機制、Broker的持久化機制木柬，以及消費者的offSet機制來最大程度保證消息不易丟失
- 從Producer的視角來看：如果消息未能正確的存儲在MQ中馁蒂，或者消費者未能正確的消費到這條消息饱亮，都是消息丟失兆旬。
- 從Broker的視角來看：如果消息已經(jīng)存在Broker里面了，如何保證不會丟失呢（宕機隧出、磁盤崩潰）
- 從Consumer的視角來看：如果消息已經(jīng)完成持久化了踏志，但是Consumer取了，但是未消費成功且沒有反饋胀瞪，就是消息丟失
從Producer分析：如何確保消息正確的發(fā)送到了Broker?
默認(rèn)情況下针余，可以通過同步的方式阻塞式的發(fā)送，check SendStatus凄诞，狀態(tài)是OK圆雁，表示消息一定成功的投遞到了Broker，狀態(tài)超時或者失敗帆谍，則會觸發(fā)默認(rèn)的2次重試伪朽。此方法的發(fā)送結(jié)果，可能Broker存儲成功了汛蝙，也可能沒成功
采取事務(wù)消息的投遞方式烈涮，并不能保證消息100%投遞成功到了Broker，但是如果消息發(fā)送Ack失敗的話患雇，此消息會存儲在CommitLog當(dāng)中，但是對ConsumerQueue是不可見的宇挫】林ǎ可以在日志中查看到這條異常的消息，嚴(yán)格意義上來講器瘪，也并沒有完全丟失
RocketMQ支持 日志的索引翠储，如果一條消息發(fā)送之后超時，也可以通過查詢?nèi)罩镜腁PI橡疼，來check是否在Broker存儲成功
從Broker分析：如果確保接收到的消息不會丟失?
- 消息支持持久化到Commitlog里面援所，即使宕機后重啟，未消費的消息也是可以加載出來的
- Broker自身支持同步刷盤欣除、異步刷盤的策略住拭，可以保證接收到的消息一定存儲在本地的內(nèi)存中
- Broker集群支持 1主N從的策略，支持同步復(fù)制和異步復(fù)制的方式，同步復(fù)制可以保證即使Master 磁盤崩潰滔岳，消息仍然不會丟失
從Cunmser分析：如何確保拉取到的消息被成功消費杠娱？
- 消費者可以根據(jù)自身的策略批量Pull消息
- Consumer自身維護(hù)一個持久化的offset（對應(yīng)MessageQueue里面的min offset），標(biāo)記已經(jīng)成功消費或者已經(jīng)成功發(fā)回到broker的消息下標(biāo)
- 如果Consumer消費失敗谱煤，那么它會把這個消息發(fā)回給Broker摊求，發(fā)回成功后，再更新自己的offset
- 如果Consumer消費失敗刘离，發(fā)回給broker時室叉，broker掛掉了，那么Consumer會定時重試這個操作
- 如果Consumer和broker一起掛了硫惕，消息也不會丟失茧痕，因為consumer 里面的offset是定時持久化的，重啟之后疲憋，繼續(xù)拉取offset之前的消息到本地
