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

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

Kafka的ack機(jī)制：在Kafka發(fā)送數(shù)據(jù)的時(shí)候，每次發(fā)送消息都會(huì)有一個(gè)確認(rèn)反饋機(jī)制，確保消息正常的能夠被收到，其中狀態(tài)有0，1，-1。如果是同步模式：ack機(jī)制能夠保證數(shù)據(jù)的不丟失，如果ack設(shè)置為0，風(fēng)險(xiǎn)很大，一般不建議設(shè)置為0。即使設(shè)置為1，也會(huì)隨著leader宕機(jī)丟失數(shù)據(jù)。
producer.type=sync request.required.acks=1
如果是異步模式：也會(huì)考慮ack的狀態(tài)，除此之外，異步模式下的有個(gè)buffer，通過buffer來進(jìn)行控制數(shù)據(jù)的發(fā)送，有兩個(gè)值來進(jìn)行控制，時(shí)間閾值與消息的數(shù)量閾值，如果buffer滿了數(shù)據(jù)還沒有發(fā)送出去，有個(gè)選項(xiàng)是配置是否立即清空buffer?？梢栽O(shè)置為-1，永久阻塞，也就數(shù)據(jù)不再生產(chǎn)。異步模式下，即使設(shè)置為-1。也可能因?yàn)槌绦騿T的不科學(xué)操作，操作數(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ù)的可能，但是可以通過配置保證消息的不丟失。

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

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

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

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



猜你喜歡：

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

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

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

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