Kafka
producer端
ack機制
ack=0 發(fā)送端不感應(yīng)broker是否接收成功
ack=1 消息發(fā)送到leader broker上，就認為消息發(fā)送成功了；但是消息還在page cache的時候，其他follow副本還沒拉取消息之前，leader broker就斷電了，消息也會丟失
ack=-1 消息發(fā)送到leader broker，并且成功寫入所有isr的follow 副本才會認為消息發(fā)送成功，可靠性最高
控制消息生產(chǎn)速率，防止發(fā)送線程跟不上生產(chǎn)線程，buffer打滿，導(dǎo)致OOM，比如使用阻塞隊列方式來減緩
消息生產(chǎn)時進行持久化到DB或者本地，消息發(fā)送成功進行callback刪除
broker端
通過調(diào)節(jié)磁盤刷盤機制降低消息丟失概率，同步刷盤/異步刷盤頻率提高，減少刷盤量
通過多副本機制來保證
consumer端
消費端關(guān)閉自動提交改為手動提交，消息成功消費后手動提交offset
RabbitMQ
exchange和queue之間存在正確的綁定關(guān)系
producer端，保證消息可以發(fā)送到queue，前提是exchange和queue之間有映射關(guān)系
事務(wù)模式，一條消息發(fā)送之后會使發(fā)送端阻塞，性能太差
callback confirm模式，一旦發(fā)布一條消息，生產(chǎn)者就可以繼續(xù)發(fā)送下一條消息，當(dāng)消息最終得到確認之后，生產(chǎn)者應(yīng)用便可以通過回調(diào)方法來處理該確認消息，如果RabbitMQ因為自身內(nèi)部錯誤導(dǎo)致消息丟失，就會發(fā)送一條nack（Basic.Nack）命令，生產(chǎn)者應(yīng)用程序同樣可以在回調(diào)方法中處理該nack命令 ；再補充一個Mandatory參數(shù)：當(dāng)Mandatory參數(shù)設(shè)為true時，如果目的不可達，會發(fā)送消息給生產(chǎn)者，生產(chǎn)者通過一個回調(diào)函數(shù)來獲取該信息。
queue
queue和消息都要做持久化操作，只持久化queue，queue內(nèi)部的消息會丟；只持久化queue，服務(wù)重啟后queue丟失，消息也無處存放。持久化消息并不是同步刷盤，也是異步刷盤，上面說的事務(wù)和confirm都是消息落到磁盤后才會執(zhí)行，但是無法保證單機故障無法恢復(fù)的情況
鏡像隊列，鏡像隊列相當(dāng)于配置了副本，絕大多數(shù)分布式的東西都有多副本的概念來確保HA。在鏡像隊列中，如果主節(jié)點（master）在此特殊時間內(nèi)掛掉，可以自動切換到從節(jié)點（slave），這樣有效的保證了高可用性，除非整個集群都掛掉
消費端
關(guān)閉自動ack，autoAck=true的情況下隊列將消息投遞給消費者后，就將消息標(biāo)記為刪除，如果消費者沒有正確消費就宕機，消息丟失
手動進行消息ack，消息消費失敗通過reject來拒絕消息不要直接確認，消息reject，requeue=false的情況下消息不會放回原來的隊列，而是轉(zhuǎn)發(fā)到指定的死信隊列，可以對死信進行特殊處理
RocketMQ
producer
默認情況下，可以通過同步的方式阻塞式的發(fā)送，check SendStatus，狀態(tài)是OK，表示消息一定成功的投遞到了Broker，狀態(tài)超時或者失敗，則會觸發(fā)默認的2次重試。此方法的發(fā)送結(jié)果，可能Broker存儲成功了，也可能沒成功
采取事務(wù)消息的投遞方式，并不能保證消息100%投遞成功到了Broker，但是如果消息發(fā)送Ack失敗的話，此消息會存儲在CommitLog當(dāng)中，但是對ConsumerQueue是不可見的?？梢栽谌罩局胁榭吹竭@條異常的消息，嚴格意義上來講，也并沒有完全丟失
RocketMQ支持 日志的索引，如果一條消息發(fā)送之后超時，也可以通過查詢?nèi)罩镜腁PI，來check是否在Broker存儲成功
broker
消息持久化到日志文件
支持同步刷盤和異步刷盤
采用一主多從的復(fù)制模式，支持同步復(fù)制和異步復(fù)制
consumer
手動提交offset
并行消費時提交的時message queue中最小的offset
consumer的offset定時持久化，可配置
集群模式，定時持久化到remote name server
廣播模式，offset定時持久化到local file，不涉及到reblance，不涉及消息重新投遞回broker
消息可靠性的套路
消息提前持久化DB
producer+confirm機制，消息發(fā)送成功將第一步保存的消息刪除；消息發(fā)送失敗，通過定時任務(wù)重新發(fā)送
broker端，消息配置持久化，通常都是異步刷盤，可以通過調(diào)節(jié)刷盤機制（可靠性和性能之間的權(quán)衡）；通常配備多副本機制來保證單店故障問題
消費端不要采用中間件的自動提交，交給使用方來做手動提交
參考文檔
