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