Kafka的存儲機制以及可靠性

Kafka的存儲機制以及可靠性

1、kafka的存儲機制

kafka經過topic來分主題存放數據，主題內有分區，分區能夠有多個副本，分區的內部還細分爲若干個segment。

所謂的分區其實就是在kafka對應存儲目錄下建立的文件夾，文件夾的名字是主題名加上分區編號，編號從0開始。

一、segment

所謂的segment其實就是在分區對應的文件夾下產生的文件。

一個分區會被劃分紅大小相等的若干segment，這樣一方面保證了分區的數據被劃分到多個文件中保證不會產生體積過大的文件；另外一方面能夠基於這些segment文件進行歷史數據的刪除，提升效率。

一個segment又由一個.log和一個.index文件組成。

1．.log

.log文件爲數據文件用來存放數據分段數據。

2．.index

.index爲索引文件保存對對應的.log文件的索引信息。

在.index文件中，保存了對對應.log文件的索引信息，經過查找.index文件能夠獲知每一個存儲在當前segment中的offset在.log文件中的開始位置，而每條日誌有其固定格式，保存了包括offset編號、日誌長度、key的長度等相關信息，經過這個固定格式中的數據能夠肯定出當前offset的結束位置，從而對數據進行讀取。

3．命名規則

這兩個文件的命名規則爲：

partition全局的第一個segment從0開始，後續每一個segment文件名爲上一個segment文件最後一條消息的offset值，數值大小爲64位，20位數字字符長度，沒有數字用0填充。

二、讀取數據

開始讀取指定分區中某個offset對應的數據時，先根據offset和當前分區的全部segment的名稱作比較，肯定出數據在哪一個segment中，再查找該segment的索引文件，肯定當前offset在數據文件中的開始位置，最後從該位置開始讀取數據文件，在根據數據格式判斷結果，獲取完整數據。

2、可靠性保證

一、AR

在Kafka中維護了一個AR列表，包括全部的分區的副本。AR又分爲ISR和OSR。

AR = ISR + OSR。

AR、ISR、OSR、LEO、HW這些信息都被保存在Zookeeper中。

1．ISR

ISR中的副本都要同步leader中的數據，只有都同步完成了數據才認爲是成功提交了，成功提交以後才能供外界訪問。

在這個同步的過程當中，數據即便已經寫入也不能被外界訪問，這個過程是經過LEO-HW機制來實現的。

2．OSR

OSR內的副本是否同步了leader的數據，不影響數據的提交，OSR內的follower盡力的去同步leader，可能數據版本會落後。

最開始全部的副本都在ISR中，在kafka工做的過程當中，若是某個副本同步速度慢於replica.lag.time.max.ms指定的閾值，則被踢出ISR存入OSR，若是後續速度恢復能夠回到ISR中。

3．LEO

LogEndOffset：分區的最新的數據的offset，當數據寫入leader後，LEO就當即執行該最新數據。至關於最新數據標識位。

4．HW

HighWatermark：只有寫入的數據被同步到全部的ISR中的副本後，數據才認爲已提交，HW更新到該位置，HW以前的數據才能夠被消費者訪問，保證沒有同步完成的數據不會被消費者訪問到。至關於全部副本同步數據標識位。

在leader宕機後，只能從ISR列表中選取新的leader，不管ISR中哪一個副本被選爲新的leader，它都知道HW以前的數據，能夠保證在切換了leader後，消費者能夠繼續看到HW以前已經提交的數據。

因此LEO表明已經寫入的最新數據位置，而HW表示已經同步完成的數據，只有HW以前的數據才能被外界訪問。

5．HW截斷機制

若是leader宕機，選出了新的leader，而新的leader並不能保證已經徹底同步了以前leader的全部數據，只能保證HW以前的數據是同步過的，此時全部的follower都要將數據截斷到HW的位置，再和新的leader同步數據，來保證數據一致。

當宕機的leader恢復，發現新的leader中的數據和本身持有的數據不一致，此時宕機的leader會將本身的數據截斷到宕機以前的hw位置，而後同步新leader的數據。宕機的leader活過來也像follower同樣同步數據，來保證數據的一致性。

二、生產者可靠性級別

經過以上的講解，已經能夠保證kafka集羣內部的可靠性，可是在生產者向kafka集羣發送時，數據通過網絡傳輸，也是不可靠的，可能由於網絡延遲、閃斷等緣由形成數據的丟失。

kafka爲生產者提供了以下的三種可靠性級別，經過不一樣策略保證不一樣的可靠性保障。

其實此策略配置的就是leader將成功接收消息信息響應給客戶端的時機。

經過request.required.acks參數配置：

1：生產者發送數據給leader，leader收到數據後發送成功信息，生產者收到後認爲發送數據成功，若是一直收不到成功消息，則生產者認爲發送數據失敗會自動重發數據。

當leader宕機時，可能丟失數據。

0：生產者不停向leader發送數據，而不須要leader反饋成功消息。

這種模式效率最高，可靠性最低。可能在發送過程當中丟失數據，也可能在leader宕機時丟失數據。

-1：生產者發送數據給leader，leader收到數據後要等到ISR列表中的全部副本都同步數據完成後，才向生產者發送成功消息，若是一隻收不到成功消息，則認爲發送數據失敗會自動重發數據。

這種模式下可靠性很高，可是當ISR列表中只剩下leader時，當leader宕機讓然有可能丟數據。

此時能夠配置min.insync.replicas指定要求觀察ISR中至少要有指定數量的副本，默認該值爲1，須要改成大於等於2的值

這樣當生產者發送數據給leader可是發現ISR中只有leader本身時，會收到異常代表數據寫入失敗，此時沒法寫入數據，保證了數據絕對不丟。

雖然不丟可是可能會產生冗餘數據，例如生產者發送數據給leader，leader同步數據給ISR中的follower，同步到一半leader宕機，此時選出新的leader，可能具備部分這次提交的數據，而生產者收到失敗消息重發數據，新的leader接受數據則數據重複了。

三、leader選舉

當leader宕機時會選擇ISR中的一個follower成爲新的leader，若是ISR中的全部副本都宕機，怎麼辦？

有以下配置能夠解決此問題：

unclean.leader.election.enable=false

策略1：必須等待ISR列表中的副本活過來才選擇其成爲leader繼續工做。

unclean.leader.election.enable=true

策略2：選擇任何一個活過來的副本，成爲leader繼續工做，此follower可能不在ISR中。

策略1，可靠性有保證，可是可用性低，只有最後掛了leader活過來kafka才能恢復。

策略2，可用性高，可靠性沒有保證，任何一個副本活過來就能夠繼續工做，可是有可能存在數據不一致的狀況。

四、kafka可靠性的保證

At most once：消息可能會丟，但毫不會重複傳輸。

At least once：消息毫不會丟，但可能會重複傳輸。

Exactly once：每條消息確定會被傳輸一次且僅傳輸一次。

kafka最多保證At least once，能夠保證不丟，可是可能會重複，爲了解決重複須要引入惟一標識和去重機制，kafka提供了GUID實現了惟一標識，可是並無提供自帶的去重機制，須要開發人員基於業務規則本身去重。

上一篇：Kafka簡介及安裝配置