摘要:消費端弄丟了數(shù)據(jù)關(guān)閉自動提交,在自己處理完畢之后手動提交,這樣就不會丟失數(shù)據(jù)。弄丟了數(shù)據(jù)一般要求設(shè)置個參數(shù)來保證消息不丟失給設(shè)置參數(shù)這個值必須大于,表示要求每個必須至少有個副本。上一篇如何保證消息不重復(fù)消費下一篇如何保證消息按順序執(zhí)行
1.mq原則數(shù)據(jù)不能多,也不能少,不能多是說消息不能重復(fù)消費,這個我們上一節(jié)已解決;不能少,就是說不能丟失數(shù)據(jù)。如果mq傳遞的是非常核心的消息,支撐核心的業(yè)務(wù),那么這種場景是一定不能丟失數(shù)據(jù)的。
2.丟失數(shù)據(jù)場景丟數(shù)據(jù)一般分為兩種,一種是mq把消息丟了,一種就是消費時將消息丟了。下面從rabbitmq和kafka分別說一下,丟失數(shù)據(jù)的場景,
(1)rabbitmq
A:生產(chǎn)者弄丟了數(shù)據(jù)
生產(chǎn)者將數(shù)據(jù)發(fā)送到rabbitmq的時候,可能在傳輸過程中因為網(wǎng)絡(luò)等問題而將數(shù)據(jù)弄丟了。
B:rabbitmq自己丟了數(shù)據(jù)
如果沒有開啟rabbitmq的持久化,那么rabbitmq一旦重啟,那么數(shù)據(jù)就丟了。所依必須開啟持久化將消息持久化到磁盤,這樣就算rabbitmq掛了,恢復(fù)之后會自動讀取之前存儲的數(shù)據(jù),一般數(shù)據(jù)不會丟失。除非極其罕見的情況,rabbitmq還沒來得及持久化自己就掛了,這樣可能導(dǎo)致一部分?jǐn)?shù)據(jù)丟失。
C:消費端弄丟了數(shù)據(jù)
主要是因為消費者消費時,剛消費到,還沒有處理,結(jié)果消費者就掛了,這樣你重啟之后,rabbitmq就認為你已經(jīng)消費過了,然后就丟了數(shù)據(jù)。
3.如何防止消息丟失
(1)rabbitmq
A:生產(chǎn)者丟失消息
①:可以選擇使用rabbitmq提供是事物功能,就是生產(chǎn)者在發(fā)送數(shù)據(jù)之前開啟事物,然后發(fā)送消息,如果消息沒有成功被rabbitmq接收到,那么生產(chǎn)者會受到異常報錯,這時就可以回滾事物,然后嘗試重新發(fā)送;如果收到了消息,那么就可以提交事物。
channel.txSelect();//開啟事物 try{ //發(fā)送消息 }catch(Exection e){ channel.txRollback();//回滾事物 //重新提交 }
缺點: rabbitmq事物已開啟,就會變?yōu)橥阶枞僮鳎a(chǎn)者會阻塞等待是否發(fā)送成功,太耗性能會造成吞吐量的下降。
②:可以開啟confirm模式。在生產(chǎn)者哪里設(shè)置開啟了confirm模式之后,每次寫的消息都會分配一個唯一的id,然后如何寫入了rabbitmq之中,rabbitmq會給你回傳一個ack消息,告訴你這個消息發(fā)送OK了;如果rabbitmq沒能處理這個消息,會回調(diào)你一個nack接口,告訴你這個消息失敗了,你可以進行重試。而且你可以結(jié)合這個機制知道自己在內(nèi)存里維護每個消息的id,如果超過一定時間還沒接收到這個消息的回調(diào),那么你可以進行重發(fā)。
//開啟confirm channel.confirm(); //發(fā)送成功回調(diào) public void ack(String messageId){ } // 發(fā)送失敗回調(diào) public void nack(String messageId){ //重發(fā)該消息 }
二者不同
事務(wù)機制是同步的,你提交了一個事物之后會阻塞住,但是confirm機制是異步的,發(fā)送消息之后可以接著發(fā)送下一個消息,然后rabbitmq會回調(diào)告知成功與否。
一般在生產(chǎn)者這塊避免丟失,都是用confirm機制。
B:rabbitmq自己弄丟了數(shù)據(jù)
設(shè)置消息持久化到磁盤。設(shè)置持久化有兩個步驟:
①創(chuàng)建queue的時候?qū)⑵湓O(shè)置為持久化的,這樣就可以保證rabbitmq持久化queue的元數(shù)據(jù),但是不會持久化queue里面的數(shù)據(jù)。
②發(fā)送消息的時候講消息的deliveryMode設(shè)置為2,這樣消息就會被設(shè)為持久化方式,此時rabbitmq就會將消息持久化到磁盤上。
必須要同時開啟這兩個才可以。
而且持久化可以跟生產(chǎn)的confirm機制配合起來,只有消息持久化到了磁盤之后,才會通知生產(chǎn)者ack,這樣就算是在持久化之前rabbitmq掛了,數(shù)據(jù)丟了,生產(chǎn)者收不到ack回調(diào)也會進行消息重發(fā)。
C:消費者弄丟了數(shù)據(jù)
使用rabbitmq提供的ack機制,首先關(guān)閉rabbitmq的自動ack,然后每次在確保處理完這個消息之后,在代碼里手動調(diào)用ack。這樣就可以避免消息還沒有處理完就ack。
(2)kafka
A:消費端弄丟了數(shù)據(jù)
關(guān)閉自動提交offset,在自己處理完畢之后手動提交offset,這樣就不會丟失數(shù)據(jù)。
B:kafka弄丟了數(shù)據(jù)
一般要求設(shè)置4個參數(shù)來保證消息不丟失:
①給topic設(shè)置 replication.factor參數(shù):這個值必須大于1,表示要求每個partition必須至少有2個副本。
②在kafka服務(wù)端設(shè)置min.isync.replicas參數(shù):這個值必須大于1,表示 要求一個leader至少感知到有至少一個follower在跟自己保持聯(lián)系正常同步數(shù)據(jù),這樣才能保證leader掛了之后還有一個follower。
③在生產(chǎn)者端設(shè)置acks=all:表示 要求每條每條數(shù)據(jù),必須是寫入所有replica副本之后,才能認為是寫入成功了
④在生產(chǎn)者端設(shè)置retries=MAX(很大的一個值,表示無限重試):表示 這個是要求一旦寫入事變,就無限重試
C:生產(chǎn)者弄丟了數(shù)據(jù) 如果按照上面設(shè)置了ack=all,則一定不會丟失數(shù)據(jù),要求是,你的leader接收到消息,所有的follower都同步到了消息之后,才認為本次寫成功了。如果沒滿足這個條件,生產(chǎn)者會自動不斷的重試,重試無限次。
上一篇《如何保證消息不重復(fù)消費》
下一篇《如何保證消息按順序執(zhí)行》
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/7233.html
摘要:能不能支持?jǐn)?shù)據(jù)丟失啊可以的,參考我們之前說的那個數(shù)據(jù)零丟失方案其實一個肯定是很復(fù)雜的,其實這是個開放題,就是看看你有沒有從架構(gòu)角度整體構(gòu)思和設(shè)計的思維以及能力。其實回答這類問題,說白了,起碼不求你看過那技術(shù)的源碼,起碼你大概知道那個技術(shù)的基本原理,核心組成部分,基本架構(gòu)構(gòu)成,然后參照一些開源的技術(shù)把一個系統(tǒng)設(shè)計出來的思路說一下就好 比如說這個消息隊列系統(tǒng),我們來從以下幾個角度來考慮一下 (1...
摘要:數(shù)量對吞吐量的影響可以達到幾百幾千個的級別,吞吐量會有小幅度的下降。這是的一大優(yōu)勢,可在同等數(shù)量機器下支撐大量的從幾十個到幾百個的時候,吞吐量會大幅下降。下一篇如何保證消息隊列的高可用 1.為什么使用消息隊列? (1)解耦:可以在多個系統(tǒng)之間進行解耦,將原本通過網(wǎng)絡(luò)之間的調(diào)用的方式改為使用MQ進行消息的異步通訊,只要該操作不是需要同步的,就可以改為使用MQ進行不同系統(tǒng)之間的聯(lián)系,這樣項目之間...
摘要:一個對應(yīng)一個,但是里面進行了多線程消費,這樣也會造成消息消費順序錯誤。保證消息的消費順序拆分多個,每個一個,就是多一些而已,確實是麻煩點這樣也會造成吞吐量下降,可以在消費者內(nèi)部采用多線程的方式取消費。 1.為什么要保證順序 消息隊列中的若干消息如果是對同一個數(shù)據(jù)進行操作,這些操作具有前后的關(guān)系,必須要按前后的順序執(zhí)行,否則就會造成數(shù)據(jù)異常。舉例: 比如通過mysql binlog進行兩個數(shù)據(jù)...
摘要:緊接著征用倍的機器來部署,每一批消費一個臨時的消息。這種做法相當(dāng)于臨時將資源和資源擴大倍,以正常速度的倍來消費消息。解決方案這種情況下,實際上沒有什么消息擠壓,而是丟了大量的消息。 1.大量消息在mq里積壓了幾個小時了還沒解決 場景: 幾千萬條數(shù)據(jù)在MQ里積壓了七八個小時,從下午4點多,積壓到了晚上很晚,10點多,11點多。線上故障了,這個時候要不然就是修復(fù)consumer的問題,讓他恢復(fù)消...
摘要:的過期策略是什么樣的采用了定期刪除惰性刪除的過期策略。定期刪除原理定期刪除指的是默認每隔就隨機抽取一些設(shè)置了過期時間的,檢測這些是否過期,如果過期了就將其刪掉。所有只會抽取一部分而不會全部檢查。 1.數(shù)據(jù)為什么會過期? 首先,要明白redis是用來做數(shù)據(jù)緩存的,不是用來做數(shù)據(jù)存儲的(當(dāng)然也可以當(dāng)數(shù)據(jù)庫用),所以數(shù)據(jù)時候過期的,過期的數(shù)據(jù)就不見了,過期主要有兩種情況, ①在設(shè)置緩存數(shù)據(jù)時制定了...
閱讀 860·2021-11-24 10:44
閱讀 2798·2021-11-11 16:54
閱讀 3217·2021-10-08 10:21
閱讀 2113·2021-08-25 09:39
閱讀 2917·2019-08-30 15:56
閱讀 3474·2019-08-30 13:46
閱讀 3505·2019-08-23 18:09
閱讀 2099·2019-08-23 17:05