常見的數(shù)據(jù)丟失
如果auto.commit.enable=true，當(dāng)consumer fetch了一些數(shù)據(jù)但還沒(méi)有完全處理掉的時(shí)候，剛好到commit interval出發(fā)了提交offset操作，接著consumer crash掉了。這時(shí)已經(jīng)fetch的數(shù)據(jù)還沒(méi)有處理完成但已經(jīng)被commit掉，因此沒(méi)有機(jī)會(huì)再次被處理，數(shù)據(jù)丟失。
網(wǎng)絡(luò)負(fù)載很高或者磁盤很忙寫入失敗的情況下，沒(méi)有自動(dòng)重試重發(fā)消息。
如果磁盤壞了，會(huì)丟失已經(jīng)落盤的數(shù)據(jù)
單批數(shù)據(jù)的長(zhǎng)度超過(guò)限制會(huì)丟失數(shù)據(jù)，報(bào)kafka.common.MessageSizeTooLargeException異常
partition leader在未完成副本數(shù)follows的備份時(shí)就宕機(jī)的情況，即使選舉出了新的leader但是已經(jīng)push的數(shù)據(jù)因?yàn)槲磦浞菥蛠G失了
- kafka的數(shù)據(jù)一開始就是存儲(chǔ)在PageCache上的，定期flush到磁盤上的，也就是說(shuō)，不是每個(gè)消息都被存儲(chǔ)在磁盤了，如果出現(xiàn)斷電或者機(jī)器故障等，PageCache上的數(shù)據(jù)就丟失了。
如何解決數(shù)據(jù)丟失
producer端：
宏觀上看保證數(shù)據(jù)的可靠安全性，肯定是依據(jù)分區(qū)數(shù)做好數(shù)據(jù)備份，設(shè)立副本數(shù)。broker端：
topic設(shè)置多分區(qū)，分區(qū)自適應(yīng)所在機(jī)器，為了讓各分區(qū)均勻分布在所在的broker中，分區(qū)數(shù)要大于broker數(shù)。分區(qū)是kafka進(jìn)行并行讀寫的單位，是提升kafka速度的關(guān)鍵。-
Consumer端
consumer端丟失消息的情形比較簡(jiǎn)單：如果在消息處理完成前就提交了offset，那么就有可能造成數(shù)據(jù)的丟失。由于Kafka consumer默認(rèn)是自動(dòng)提交位移的，所以在后臺(tái)提交位移前一定要保證消息被正常處理了，因此不建議采用很重的處理邏輯，如果處理耗時(shí)很長(zhǎng)，則建議把邏輯放到另一個(gè)線程中去做。為了避免數(shù)據(jù)丟失，有兩點(diǎn)建議：enable.auto.commit=false 關(guān)閉自動(dòng)提交位移
在消息被完整處理之后再手動(dòng)提交位移
