不可靠的KAFKA

這里的不可靠是指代KAFKA其設(shè)計(jì)之初就為高性能而設(shè)計(jì)，其是允許消息丟失的，但經(jīng)過(guò)多個(gè)版本的升級(jí)之后，通過(guò)KAFKA的相關(guān)配置，我們可以將其作為可靠的隊(duì)列(不丟消息的隊(duì)列)。

在本文里，不會(huì)具體列出要改哪個(gè)參數(shù)，需要改的參數(shù)請(qǐng)大家自行翻文檔找出來(lái)，這樣理解會(huì)更為深刻。

發(fā)送消息到KAFKA時(shí)產(chǎn)生的消息丟失

在一些比較舊的版本，KAFKA客戶端發(fā)送消息到KAFKA服務(wù)器時(shí)，由于客戶端不等待服務(wù)器回應(yīng)，直接返回，等待發(fā)送異步進(jìn)行。因此其在發(fā)送環(huán)節(jié)就可能存在消息丟失。

為了避免消息丟失，我們需要用新版客戶端，并配置客戶端發(fā)送消息時(shí)同步等待返回結(jié)果

KAFKA服務(wù)器宕機(jī)導(dǎo)致的消息丟失(磁盤(pán)緩存丟失)

KAFKA自身不管理LOG寫(xiě)入磁盤(pán)的緩存，將其交由操作系統(tǒng)處理。因此在默認(rèn)配置下，如果KAFKA宕機(jī)，則會(huì)因?yàn)閿?shù)據(jù)沒(méi)有FLUSH到磁盤(pán)而丟失數(shù)據(jù)。

為了保證數(shù)據(jù)不丟失，KAFKA提供的現(xiàn)成方法有兩個(gè)，

每條消息都Flush一次； 每條都Flush一遍，必然不可行，因?yàn)槠渌俣葧?huì)變得很慢。官方也不建議這么做。(如果其有類(lèi)似Group Commit的優(yōu)化機(jī)制的話，我覺(jué)得可以使用，但是貌似曾經(jīng)有人提過(guò)這個(gè)PR，沒(méi)有被采納，其認(rèn)為用集群就可解決這個(gè)可靠性問(wèn)題)

構(gòu)建集群，以提高可用性。 官方推薦的方法。只要掛的機(jī)器不要超過(guò)強(qiáng)制寫(xiě)入的機(jī)器，那么就可以保證數(shù)據(jù)不丟失。但需要注意的是，KAFKA組成的集群必須在不同機(jī)房。不然機(jī)房一斷電，集群內(nèi)的KAFKA就會(huì)出現(xiàn)消息丟失。

KAFKA復(fù)制模式導(dǎo)致的丟失

KAFKA的副本模式為主備復(fù)制模式，這個(gè)模式下有兩種形式 同步復(fù)制模式 以及 異步復(fù)制模式。

異步復(fù)制模式： 客戶端將信息發(fā)送到主副本，主副本收到信息寫(xiě)到本地緩存后即返回ACK給客戶端。然后異步地將數(shù)據(jù)發(fā)送給備份。本配置為默認(rèn)配置，其高效，但主掛掉，則消息丟失。 同步復(fù)制模式： 客戶端將信息發(fā)送到主副本，主副本收到信息，寫(xiě)到本地緩存，并發(fā)送給所有從機(jī)，從機(jī)都寫(xiě)到緩存后給主機(jī)反饋，主機(jī)都收到反饋后再反饋給客戶端

需要修改復(fù)制模式為同步復(fù)制

KAFKA選舉導(dǎo)致的消息丟失

KAFKA有一個(gè)配置，是否允許在不得已的情況下，允許在非同步狀態(tài)下的副本成為主副本。其默認(rèn)是打開(kāi)的，結(jié)果就導(dǎo)致存在丟失消息的可能性。需要將其關(guān)閉

未被確認(rèn)的消息不會(huì)被消費(fèi)

KAFKA使用主從同步復(fù)制的時(shí)候，沒(méi)有被完全復(fù)制(完全復(fù)制的消息會(huì)在HW(High water Mark之下))的信息不會(huì)被消費(fèi)。 一個(gè)Broker若需要從非ISR狀態(tài)進(jìn)入到ISR狀態(tài)前，會(huì)將其在HW之前的消息記錄給truncate掉，并嘗試跟上Master里的記錄。跟上后，將會(huì)恢復(fù)ISR狀態(tài)。

KAFKA的主節(jié)點(diǎn)選舉通過(guò)ZK中登記的序號(hào)決定，更細(xì)節(jié)可查看KAFKA同步復(fù)制模式選舉過(guò)程，以上為默認(rèn)實(shí)現(xiàn)，不需修改，也無(wú)法修改

已確認(rèn)的消息如果存在ISR狀態(tài)的副本的話，就不會(huì)丟失記錄

原Master掛掉后，新選出的Master不會(huì)丟棄HW之后的消息，新Master會(huì)將這些HW之后的副本再次發(fā)送給其余的副本。因此即使高水位信息沒(méi)有傳遞給新的Master副本也沒(méi)有問(wèn)題。

ISR分區(qū)過(guò)少導(dǎo)致失去容災(zāi)特性

默認(rèn)配置下，ISR分區(qū)個(gè)數(shù)可以為1時(shí)依然可以寫(xiě)數(shù)據(jù)。但當(dāng)出現(xiàn)這種情況的時(shí)候，就失去了容災(zāi)性。只要主分區(qū)掛掉，那么數(shù)據(jù)就丟失。

KAFKA有配置可以指定寫(xiě)入時(shí)最少的ISR數(shù)量，少于特定值，就不再ACK。如一共三臺(tái)BROKER，我們可以指定ISR最少數(shù)量為2,那么只有1臺(tái)處于ISR狀態(tài)的話，COMMIT將無(wú)法執(zhí)行。

是否設(shè)置該值，視具體情況而定，若無(wú)法容忍丟失，則設(shè)置該值為2，NAME 。追求可用性，則不設(shè)置。

個(gè)人建議設(shè)置為2，無(wú)論副本數(shù)量有多少

KAFKA如何處理網(wǎng)絡(luò)分區(qū)情況？

如果MASTER與其他的副本與ZK是聯(lián)通的，但是MASTER與其他副本之間出現(xiàn)了網(wǎng)絡(luò)分區(qū)，那么ISR就只能為1。

消息保存的策略的設(shè)置

建議保留消息的策略基于時(shí)間。如保留21天

客戶端宕機(jī)導(dǎo)致的消費(fèi)位置丟失

KAFKA在分區(qū)中的消費(fèi)位置由客戶端管控，其有可能沒(méi)有及時(shí)保存到KAFKA中，導(dǎo)致消費(fèi)位置丟失。 若消費(fèi)位置丟失，則消費(fèi)可能從上一個(gè)保存的消費(fèi)位置重新進(jìn)行消費(fèi)。所以在不能接受重復(fù)消息的系統(tǒng)需要自行定制對(duì)于消息的冪等處理

(死信是否會(huì)丟失？)

At Least Once

實(shí)際上我們對(duì)可靠消息系統(tǒng)的要求通常是At least Once,經(jīng)過(guò)上述配置已經(jīng)基本達(dá)到了At Least Once的要求

消息消費(fèi)失敗的重試設(shè)置

需要設(shè)計(jì)一個(gè)死信隊(duì)列，消費(fèi)失敗的消息需放入里面，以免影響后續(xù)其他消息消費(fèi)

參考

總結(jié)

以上是生活随笔為你收集整理的kafka数据不丢失不重复_如何配置 KAFKA 使其消息不会丢失的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。