Kafka深入解析
1. Kafka工作流程及文件存儲機制
1 ）Kafka工作流程
Kafka中消息是以topic進(jìn)行分類(lèi)的，生產(chǎn)者生產(chǎn)消息，消費者消費消息，都是面向topic的。
topic是邏輯上的概念，而partition是物理上的概念，每個(gè)partition對應于一個(gè)log文件，該log文件中存儲的就是producer生產(chǎn)的數據。Producer生產(chǎn)的數據會(huì )被不斷追加到該log文件末端，且每條數據都有自己的offset。消費者組中的每個(gè)消費者，都會(huì )實(shí)時(shí)記錄自己消費到了哪個(gè)offset，以便出錯恢復時(shí)，從上次的位置繼續消費。
- Kafka文件存儲機制
由于生產(chǎn)者生產(chǎn)的消息會(huì )不斷追加到log文件末尾，為防止log文件過(guò)大導致數據定位效率低下，Kafka采取了分片和索引機制，將每個(gè)partition分為多個(gè)segment。每個(gè)segment對應兩個(gè)文件——“.index”文件和“.log”文件。這些文件位于一個(gè)文件夾下，該文件夾的命名規則為：topic名稱(chēng)+分區序號。例如，first這個(gè)topic有三個(gè)分區，則其對應的文件夾為first-0,first-1,first-2。
00000000000000000000.index
00000000000000000000.log
00000000000000170410.index
00000000000000170410.log
00000000000000239430.index
00000000000000239430.log
index和log文件以當前segment的第一條消息的offset命名。下圖為index文件和log文件的結構示意圖。
“.index”文件存儲大量的索引信息，“.log”文件存儲大量的數據，索引文件中的元數據指向對應數據文件中message的物理偏移地址。
2、Kafka生產(chǎn)者
1 ）分區策略
（1）分區的原因
? ① 方便在集群中擴展，每個(gè)Partition可以通過(guò)調整以適應它所在的機器，而一個(gè)topic又可以有多個(gè)Partition組成，因此整個(gè)集群就可以適應任意大小的數據了；
? ② 可以提高并發(fā)，因為可以以Partition為單位讀寫(xiě)了。
（2）分區的原則
? 我們需要將producer發(fā)送的數據封裝成一個(gè)ProducerRecord對象。
① 指明partition的情況下，直接將指明的值直接作為partiton值；
② 沒(méi)有指明partition值但有key的情況下，將key的hash值與topic的partition數進(jìn)行取余得到partition值；
③ 既沒(méi)有partition值又沒(méi)有key值的情況下，第一次調用時(shí)隨機生成一個(gè)整數（后面每次調用在這個(gè)整數上自增），將這個(gè)值與topic可用的partition總數取余得到partition值，也就是常說(shuō)的round-robin算法。
- 數據可靠性保證
為保證producer發(fā)送的數據，能可靠的發(fā)送到指定的topic，topic的每個(gè)partition收到producer發(fā)送的數據后，都需要向producer發(fā)送ack（acknowledgement確認收到），如果producer收到ack，就會(huì )進(jìn)行下一輪的發(fā)送，否則重新發(fā)送數據。
（1）副本同步策略：
Kafka選擇了第二種方案，原因如下：
? 1）同樣為了容忍n臺節點(diǎn)的故障，第一種方案需要2n+1個(gè)副本，而第二種方案只需要n+1個(gè)副本，而Kafka的每個(gè)分區都有大量的數據，第一種方案會(huì )造成大量數據的冗余。
? 2）雖然第二種方案的網(wǎng)絡(luò )延遲會(huì )比較高，但網(wǎng)絡(luò )延遲對Kafka的影響較小。
（2）ISR
? 采用第二種方案之后，設想以下情景：leader收到數據，所有follower都開(kāi)始同步數據，但有一個(gè)follower，因為某種故障，遲遲不能與leader進(jìn)行同步，那leader就要一直等下去，直到它完成同步，才能發(fā)送ack。這個(gè)問(wèn)題怎么解決呢？
? Leader維護了一個(gè)動(dòng)態(tài)的in-sync replica set (ISR)，意為和leader保持同步的follower集合。當ISR中的follower完成數據的同步之后，leader就會(huì )給follower發(fā)送ack。如果follower長(cháng)時(shí)間未向leader同步數據，則該follower將被踢出ISR，該時(shí)間閾值由replica.lag.time.max.ms參數設定。Leader發(fā)生故障之后，就會(huì )從ISR中選舉新的leader。
（3）ack應答機制
? 對于某些不太重要的數據，對數據的可靠性要求不是很高，能夠容忍數據的少量丟失，所以沒(méi)必要等ISR中的follower全部接收成功。
? 所以Kafka為用戶(hù)提供了三種可靠性級別，用戶(hù)根據對可靠性和延遲的要求進(jìn)行權衡，選擇以下的配置。
acks參數配置：
? acks：
? 0：producer不等待broker的ack，這一操作提供了一個(gè)最低的延遲，broker一接收到還沒(méi)有寫(xiě)入磁盤(pán)就已經(jīng)返回，當broker故障時(shí)有可能丟失數據；
? 1：producer等待broker的ack，partition的leader落盤(pán)成功后返回ack，如果在follower同步成功之前l(fā)eader故障，那么將會(huì )丟失數據；
-1（all）：producer等待broker的ack，partition的leader和follower全部落盤(pán)成功后才返回ack。但是如果在follower同步完成后，broker發(fā)送ack之前，leader發(fā)生故障，那么會(huì )造成數據重復。
（4）故障處理細節
① follower故障
? follower發(fā)生故障后會(huì )被臨時(shí)踢出ISR，待該follower恢復后，follower會(huì )讀取本地磁盤(pán)記錄的上次的HW，并將log文件高于HW的部分截取掉，從HW開(kāi)始向leader進(jìn)行同步。等該follower的LEO大于等于該Partition的HW，即follower追上leader之后，就可以重新加入ISR了。
② leader故障
? leader發(fā)生故障之后，會(huì )從ISR中選出一個(gè)新的leader，之后，為保證多個(gè)副本之間的數據一致性，其余的follower會(huì )先將各自的log文件高于HW的部分截掉，然后從新的leader同步數據。
? 注意：這只能保證副本之間的數據一致性，并不能保證數據不丟失或者不重復。
3、Kafka消費者
- 消費方式
?consumer采用pull（拉）模式從broker中讀取數據。
?push（推）模式很難適應消費速率不同的消費者，因為消息發(fā)送速率是由broker決定的。它的目標是盡可能以最快速度傳遞消息，但是這樣很容易造成consumer來(lái)不及處理消息，典型的表現就是拒絕服務(wù)以及網(wǎng)絡(luò )擁塞。而pull模式則可以根據consumer的消費能力以適當的速率消費消息。
?pull模式不足之處是，如果kafka沒(méi)有數據，消費者可能會(huì )陷入循環(huán)中，一直返回空數據。針對這一點(diǎn)，Kafka的消費者在消費數據時(shí)會(huì )傳入一個(gè)時(shí)長(cháng)參數timeout，如果當前沒(méi)有數據可供消費，consumer會(huì )等待一段時(shí)間之后再返回，這段時(shí)長(cháng)即為timeout。 - 分區分配策略
? 一個(gè)consumer group中有多個(gè)consumer，一個(gè) topic有多個(gè)partition，所以必然會(huì )涉及到partition的分配問(wèn)題，即確定那個(gè)partition由哪個(gè)consumer來(lái)消費。
? Kafka有兩種分配策略：RoundRobin和Range。
（1）RoundRobin
（2）Rang
- offset維護
? 由于consumer在消費過(guò)程中可能會(huì )出現斷電宕機等故障，consumer恢復后，需要從故障前的位置的繼續消費，所以consumer需要實(shí)時(shí)記錄自己消費到了哪個(gè)offset，以便故障恢復后繼續消費。
?Kafka 0.9版本之前，consumer默認將offset保存在Zookeeper中，從0.9版本開(kāi)始，consumer默認將offset保存在Kafka一個(gè)內置的topic中，該topic為_(kāi)_consumer_offsets。
4、Kafka高效讀寫(xiě)數據
- 順序寫(xiě)磁盤(pán)
? Kafka的producer生產(chǎn)數據，要寫(xiě)入到log文件中，寫(xiě)的過(guò)程是一直追加到文件末端，為順序寫(xiě)。官網(wǎng)有數據表明，同樣的磁盤(pán)，順序寫(xiě)能到到600M/s，而隨機寫(xiě)只有100k/s。這與磁盤(pán)的機械機構有關(guān)，順序寫(xiě)之所以快，是因為其省去了大量磁頭尋址的時(shí)間。 - 零復制技術(shù)
5、Zookeeper在Kafka中的作用
Kafka集群中有一個(gè)broker會(huì )被選舉為Controller，負責管理集群broker的上下線(xiàn)，所有topic的分區副本分配和leader選舉等工作。
? Controller的管理工作都是依賴(lài)于Zookeeper的。
? 以下為partition的leader選舉過(guò)程：
轉載自：Kafka深入解析
評論
