kafka?rabbitMQ及rocketMQ隊(duì)列的消息可靠性保證分析

更新時(shí)間：2022年05月09日 16:28:28 作者：馮子玉

這篇文章主要介紹了kafka?rabbitMQ及rocketMQ隊(duì)列的消息可靠性保證分析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

1.消息丟失

1.生產(chǎn)者發(fā)送失敗

所有消息隊(duì)列都可能發(fā)生的問題

生產(chǎn)者發(fā)送消息后，隊(duì)列未成功接收（網(wǎng)絡(luò)原因或其他）而生產(chǎn)者不知情，消息丟失
生產(chǎn)者發(fā)送消息后，隊(duì)列接收成功->生產(chǎn)者確認(rèn)，但消息并未持久化，隊(duì)列崩潰，消息丟失

針對(duì)這類問題，三種消息隊(duì)列都提供了生產(chǎn)者消息發(fā)送確認(rèn)的模式，例如將kafka的acks參數(shù)設(shè)置為大于0，將rabbitMQ的信道設(shè)置為confirm模式。而在rocketMQ中會(huì)返回消息發(fā)送狀態(tài)碼。其中rabbitMQ和rocketMQ還提供了生產(chǎn)者事務(wù)操作。

只有某些消息隊(duì)列才會(huì)發(fā)生的問題

kafka和rabbitMQ在集群狀態(tài)下當(dāng)前首領(lǐng)不可用時(shí)會(huì)進(jìn)行首領(lǐng)選舉。在kafka中，如果把a(bǔ)cks設(shè)置為1（只要首領(lǐng)節(jié)點(diǎn)收到生產(chǎn)者發(fā)送的消息即確認(rèn)發(fā)送成功）時(shí)，若當(dāng)前首領(lǐng)收到的消息但還未同步至從任一節(jié)點(diǎn)就崩潰了，kafka會(huì)在還來不及判定的非同步從節(jié)點(diǎn)中選舉出首領(lǐng)，這時(shí)消息丟失，解決方式是將acks設(shè)置未all，即全部從節(jié)點(diǎn)同步成功再確認(rèn)。而在rabbitMQ中，新加入的鏡像節(jié)點(diǎn)不會(huì)同步在此之前的消息，當(dāng)老的消息還未完全消費(fèi)完，老節(jié)點(diǎn)全部崩潰時(shí)，新節(jié)點(diǎn)被選舉為首領(lǐng)時(shí)，會(huì)丟失所有未消費(fèi)的舊消息（目前好像沒有什么好的解決方式）。
kafka中，即使及時(shí)的將所有未同步消息的節(jié)點(diǎn)成功判定未非同步節(jié)點(diǎn)，也要在消息丟失和系統(tǒng)不可用之間做出權(quán)衡，如果不希望消息丟失，則在首領(lǐng)節(jié)點(diǎn)恢復(fù)前整個(gè)系統(tǒng)不可用，通過參數(shù)unclean.leader.election.enable可以設(shè)置非同步副本是否能成為首領(lǐng)節(jié)點(diǎn)。

rocketMQ集群環(huán)境下，broker主從使用異步復(fù)制模式時(shí)，若master節(jié)點(diǎn)崩潰且數(shù)據(jù)無法恢復(fù)，會(huì)丟失還未同步至從節(jié)點(diǎn)的部分消息，解決方式是使用同步雙寫的方式同步消息，但會(huì)降低吞吐率。

2.消費(fèi)者消費(fèi)失敗

與生產(chǎn)者類似，若消費(fèi)者在消費(fèi)消息失敗時(shí)未告知消息隊(duì)列，此消息丟失。kafka，rabbitMQ，rocketMQ都提供了相似的消費(fèi)成功確認(rèn)機(jī)制來解決這個(gè)問題，rabbitMQ通過auto_ack參數(shù)設(shè)置自動(dòng)確認(rèn)或手動(dòng)確認(rèn)。

而rocketMQ和kafka通過消息偏移量來控制信息消費(fèi)，rocketMQ在pull模式下需要自己維護(hù)偏移量。

3.隊(duì)列因?yàn)樽陨眢w原因丟失數(shù)據(jù)

這個(gè)很好理解，例如rabbitMQ默認(rèn)將消息保存再內(nèi)存中，如果隊(duì)列崩潰，消息自然丟失

2.消息順序

1.kafka

kafka保證同一分區(qū)內(nèi)消息的順序，也就是說，如果要讓某一topic內(nèi)消息全部有序，只能為該topic設(shè)置一個(gè)分區(qū)，這會(huì)降低該主題的吞吐量。通常使用消息的key值將消息散布到不同分區(qū)上，以此保證消息的局部有序性，但這種局部有序性的保證僅僅在消息寫入分區(qū)時(shí)是有序的才能保證，例如生產(chǎn)者按順序消息寫入消息A，消息B，消息A寫入失敗，消息B寫入成功，生產(chǎn)者重發(fā)消息A且成功，這時(shí)候兩個(gè)消息的順序就顛倒了，解決方式是設(shè)定max.in.flight.requests.per.connection為1,指定生產(chǎn)者在收到消息成功發(fā)送的確認(rèn)之前不允許發(fā)送其他信息，但這種方式也會(huì)嚴(yán)重降低吞吐量。

另一個(gè)問題是kafka默認(rèn)的分區(qū)器使用散列算法將消息的key值映射到對(duì)映的分區(qū)上，如果增加了分區(qū)，key值映射的分區(qū)可能會(huì)與之前的不一致。在kafka中，一個(gè)分區(qū)只能被一個(gè)消費(fèi)者消費(fèi)，保證了消息消費(fèi)的局部有序性。

2.rocketMQ

rocketMQ的隊(duì)列（Message Queue）與kafka的分區(qū)在概念上相似，所以rocketMQ在消息有序性的保證上自然也是基于隊(duì)列（Message Queue）的，同kafka一樣，如果要讓某一主題內(nèi)的消息有序，必須將此主題內(nèi)的獨(dú)寫隊(duì)列數(shù)量設(shè)為1，但和kafka一樣，這種操作會(huì)大量降低該主題的吞吐量。

rocketMQ中在發(fā)送消息時(shí)傳入自定義的MessageQueueSelector保證消息生產(chǎn)的局部有序性，在消費(fèi)消息時(shí)push模式下通過MessageListenerOrderly保證順序消費(fèi)。

3.rabbitMQ

對(duì)于rabbitMQ，我沒有找到相關(guān)的資料，個(gè)人猜測，rabbitMQ同一隊(duì)列內(nèi)消息的有序性應(yīng)該是有保障的，但大多數(shù)人會(huì)在生產(chǎn)者和消費(fèi)者中增加消息有序性判斷

3.消息重復(fù)

幾乎所有的消息隊(duì)列中都未能提供不重復(fù)消息的保證，而且消息重復(fù)與消息丟失幾乎是二選一的問題，大多數(shù)情況下我們選擇保證消息不丟失而容忍一部分消息重復(fù)，最廣泛的解決消息重復(fù)的方式是在消費(fèi)者端對(duì)消息進(jìn)行驗(yàn)證或者保證消費(fèi)的冪等性

以上就是kafka rabbitMQ及rocketMQ隊(duì)列的消息可靠性保證分析的詳細(xì)內(nèi)容，更多關(guān)于kafka rabbitMQ rocketMQ消息隊(duì)列的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: