首頁技術(shù)文章正文

怎樣能確保Kafka儲存的數(shù)據(jù)不丟失?

更新時間:2021-04-02 來源:黑馬程序員 瀏覽量:

1577370495235_學IT就到黑馬程序員.gif


生產(chǎn)者數(shù)據(jù)的不丟失

Kafka的ack機制:在Kafka發(fā)送數(shù)據(jù)的時候,每次發(fā)送消息都會有一個確認反饋機制,確保消息正常的能夠被收到,其中狀態(tài)有0,1,-1。如果是同步模式:ack機制能夠保證數(shù)據(jù)的不丟失,如果ack設(shè)置為0,風險很大,一般不建議設(shè)置為0。即使設(shè)置為1,也會隨著leader宕機丟失數(shù)據(jù)。
producer.type=sync request.required.acks=1
如果是異步模式:也會考慮ack的狀態(tài),除此之外,異步模式下的有個buffer,通過buffer來進行控制數(shù)據(jù)的發(fā)送,有兩個值來進行控制,時間閾值與消息的數(shù)量閾值,如果buffer滿了數(shù)據(jù)還沒有發(fā)送出去,有個選項是配置是否立即清空buffer??梢栽O(shè)置為-1,永久阻塞,也就數(shù)據(jù)不再生產(chǎn)。異步模式下,即使設(shè)置為-1。也可能因為程序員的不科學操作,操作數(shù)據(jù)丟失,比如kill -9,但這是特別的例外情況。
producer.type=async
request.required.acks=1
queue.buffering.max.ms=5000
queue.buffering.max.messages=10000 queue.enqueue.timeout.ms = -1 batch.num.messages=200
結(jié)論:producer有丟數(shù)據(jù)的可能,但是可以通過配置保證消息的不丟失。

消費者數(shù)據(jù)的不丟失

通過offset commit 來保證數(shù)據(jù)的不丟失,Kafka自己記錄了每次消費的offset數(shù)值,下次繼續(xù)消費的時候,會接著上次的offset進行消費。
而offset的信息在Kafka0.8版本之前保存在Zookeeper中,在0.8版本之后保存到topic中,即使消費者在運行過程中掛掉了,再次啟動的時候會找到offset的值,找到之前消費消息的位置,接著消費,由于 offset的信息寫入的時候并不是每條消息消費完成后都寫入的,所以這種情況有可能會造成重復(fù)消費,但是不會丟失消息。
唯一例外的情況是,我們在程序中給原本做不同功能的兩個consumer組設(shè)置
KafkaSpoutConfig.bulider.setGroupid的時候設(shè)置成了一樣的groupid,這種情況會導致這兩個組共享同一份數(shù)據(jù),就會產(chǎn)生組A消費partition1,partition2中的消息,組B消費partition3的消息,這樣每個組消費的消息都會丟失,都是不完整的。 為了保證每個組都獨享一份消息數(shù)據(jù),groupid一定不要重復(fù)才行。

1617358484730_Kafka數(shù)據(jù)存儲1.jpg


Kafka集群中的broker的數(shù)據(jù)不丟失

每個broker中的partition我們一般都會設(shè)置有replication(副本)的個數(shù),生產(chǎn)者寫入的時候首先根據(jù)分發(fā)策略(有partition按partition,有key按key,都沒有輪詢)寫入到leader中,follower(副本)再跟leader同步數(shù)據(jù),這樣有了備份,也可以保證消息數(shù)據(jù)的不丟失。



猜你喜歡:

Hadoop生態(tài)體系有哪些子系統(tǒng)?

Zookeeper集群中的三種角色簡單介紹

Hadoop實現(xiàn)join的幾種方法【大數(shù)據(jù)開發(fā)面試】    

Hadoop虛擬機怎樣遠程登錄和開啟SSH免密登錄功能?    
黑馬程序員大數(shù)據(jù)培訓

分享到:
在線咨詢 我要報名
和我們在線交談!