Kafka包括Producer、Broker、Consumer，因此從這三個(gè)方面分析。
Producer端
丟失原因：Kafka在Producer端的消息發(fā)送采用的是異步發(fā)送的方式(還有同步發(fā)送，但是同步發(fā)送會導(dǎo)致消息阻塞、需要等待)，丟失數(shù)據(jù)是因?yàn)橄]有到達(dá)Broker端，原因可能是網(wǎng)絡(luò)波動(dòng)導(dǎo)致沒有回調(diào)和數(shù)據(jù)消息太大超出Broker承受范圍，導(dǎo)致Broker拒收消息。
解決方法：更換調(diào)用方式，不使用異步發(fā)送，使用帶回調(diào)通知函數(shù)的方法進(jìn)行發(fā)送消息，網(wǎng)絡(luò)波動(dòng)和消息過大，可以調(diào)整Producer端重試次數(shù)和消息大小。
丟失原因：Kafka默認(rèn)ack設(shè)置為1，會存在數(shù)據(jù)丟失問題。(ack為0也會存在丟數(shù)據(jù)問題)
解決方法：修改ack設(shè)置為-1。(可以結(jié)合冪等性做到Exactly Once)
Broker端
丟失原因：數(shù)據(jù)從Producer端push過來后，Broker端需要將數(shù)據(jù)持久化存儲到磁盤中，消息存儲是異步存儲的，即按照一定的消息數(shù)量和間隔時(shí)間進(jìn)行存儲，數(shù)據(jù)會先放在 PageCache 中，如果在存儲的時(shí)候Broker宕機(jī)，此時(shí)選舉了一個(gè)落后Leader Partition 很多的 Follower Partition 成為新的Lerder Partition，那么落后的消息就會丟失。
解決方法：修改參數(shù)，設(shè)置有資格成為Leader的Follower(落后太久的不要)，設(shè)置分區(qū)數(shù)≥3(Leader宕機(jī)后可以有Follower補(bǔ)上)，設(shè)置消息至少要被寫入成功到ISR多少個(gè)副本才算“已提交”。
Consumer端
丟失原因：Consumer拉取消息后最終處理完需要提交 Offset，提交Offset有以下三種方式：
- 自動(dòng)提交Offset。
- 拉取消息后，先提交offset、再處理消息，如果此時(shí)處理消息的時(shí)候宕機(jī)，由于Offset已提交，Consumer重啟后會從之前已提交的offset 下一個(gè)位置開始消費(fèi)，之前未處理的消息不會被再次處理，對于Consumer來說消息已經(jīng)丟失。
- 拉取消息后，先處理消息、再提交Offset，如果此時(shí)在提交之前宕機(jī)，由于Offset沒有提交，Consumer重啟后會從上次的Offset重新拉取消息，不會丟失數(shù)據(jù)，但會出現(xiàn)重復(fù)消費(fèi)的情況，這里只能業(yè)務(wù)自己保證冪等性。
方式2會導(dǎo)致數(shù)據(jù)丟失。文章來源：http://www.zghlxwxcb.cn/news/detail-629424.html
解決方法：使用先拉取消息、再處理消息、再提交offset的方法，并且設(shè)置參數(shù) enable.auto.commit = false 使用手動(dòng)提交位移的方式。文章來源地址http://www.zghlxwxcb.cn/news/detail-629424.html
到了這里，關(guān)于Kafka數(shù)據(jù)丟失原因及解決方案的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
