Kafka
producer端
ack機(jī)制
ack=0 發(fā)送端不感應(yīng)broker是否接收成功
ack=1 消息發(fā)送到leader broker上它改，就認(rèn)為消息發(fā)送成功了己沛；但是消息還在page cache的時候慌核，其他follow副本還沒拉取消息之前，leader broker就斷電了申尼，消息也會丟失
ack=-1 消息發(fā)送到leader broker垮卓，并且成功寫入所有isr的follow 副本才會認(rèn)為消息發(fā)送成功，可靠性最高
控制消息生產(chǎn)速率师幕，防止發(fā)送線程跟不上生產(chǎn)線程粟按，buffer打滿，導(dǎo)致OOM霹粥，比如使用阻塞隊(duì)列方式來減緩
消息生產(chǎn)時進(jìn)行持久化到DB或者本地灭将，消息發(fā)送成功進(jìn)行callback刪除
broker端
通過調(diào)節(jié)磁盤刷盤機(jī)制降低消息丟失概率，同步刷盤/異步刷盤頻率提高后控，減少刷盤量
通過多副本機(jī)制來保證
consumer端
消費(fèi)端關(guān)閉自動提交改為手動提交庙曙，消息成功消費(fèi)后手動提交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)消息最終得到確認(rèn)之后，生產(chǎn)者應(yīng)用便可以通過回調(diào)方法來處理該確認(rèn)消息察皇，如果RabbitMQ因?yàn)樽陨韮?nèi)部錯誤導(dǎo)致消息丟失茴厉，就會發(fā)送一條nack（Basic.Nack）命令，生產(chǎn)者應(yīng)用程序同樣可以在回調(diào)方法中處理該nack命令 什荣；再補(bǔ)充一個Mandatory參數(shù)：當(dāng)Mandatory參數(shù)設(shè)為true時矾缓，如果目的不可達(dá)，會發(fā)送消息給生產(chǎn)者稻爬，生產(chǎn)者通過一個回調(diào)函數(shù)來獲取該信息嗜闻。
queue
queue和消息都要做持久化操作，只持久化queue桅锄，queue內(nèi)部的消息會丟琉雳；只持久化queue，服務(wù)重啟后queue丟失友瘤，消息也無處存放翠肘。持久化消息并不是同步刷盤，也是異步刷盤辫秧，上面說的事務(wù)和confirm都是消息落到磁盤后才會執(zhí)行束倍，但是無法保證單機(jī)故障無法恢復(fù)的情況
鏡像隊(duì)列，鏡像隊(duì)列相當(dāng)于配置了副本盟戏，絕大多數(shù)分布式的東西都有多副本的概念來確保HA绪妹。在鏡像隊(duì)列中，如果主節(jié)點(diǎn)（master）在此特殊時間內(nèi)掛掉柿究，可以自動切換到從節(jié)點(diǎn)（slave）邮旷，這樣有效的保證了高可用性，除非整個集群都掛掉
消費(fèi)端
關(guān)閉自動ack蝇摸，autoAck=true的情況下隊(duì)列將消息投遞給消費(fèi)者后廊移，就將消息標(biāo)記為刪除，如果消費(fèi)者沒有正確消費(fèi)就宕機(jī)探入，消息丟失
手動進(jìn)行消息ack狡孔，消息消費(fèi)失敗通過reject來拒絕消息不要直接確認(rèn)，消息reject蜂嗽，requeue=false的情況下消息不會放回原來的隊(duì)列苗膝，而是轉(zhuǎn)發(fā)到指定的死信隊(duì)列，可以對死信進(jìn)行特殊處理
RocketMQ
producer
默認(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
消息持久化到日志文件
支持同步刷盤和異步刷盤
采用一主多從的復(fù)制模式侄旬，支持同步復(fù)制和異步復(fù)制
consumer
手動提交offset
并行消費(fèi)時提交的時message queue中最小的offset
consumer的offset定時持久化，可配置
集群模式篷朵，定時持久化到remote name server
廣播模式勾怒，offset定時持久化到local file婆排，不涉及到reblance声旺，不涉及消息重新投遞回broker
消息可靠性的套路
消息提前持久化DB
producer+confirm機(jī)制，消息發(fā)送成功將第一步保存的消息刪除段只；消息發(fā)送失敗腮猖，通過定時任務(wù)重新發(fā)送
broker端，消息配置持久化赞枕，通常都是異步刷盤澈缺，可以通過調(diào)節(jié)刷盤機(jī)制（可靠性和性能之間的權(quán)衡）；通常配備多副本機(jī)制來保證單店故障問題
消費(fèi)端不要采用中間件的自動提交炕婶，交給使用方來做手動提交
參考文檔
