kafka工作流程
kafka中的數據只能保證分區內有序，不能保證全局有序
topic是邏輯上的概念，而partition是物理上的概念，可以在本地看見真實的目錄
kafka文件存儲機制
由於生產者生產的消息會不斷追加到 log 文件末尾，爲防止 log 文件過大導致數據定位效率低下，Kafka 採取了分片和索引機制，將每個 partition 分爲多個 segment。每個 segment對應兩個文件：
.index文件和 .log 文件。這些文件位於一個文件夾下，該文件夾的命名規則爲：
topic 名稱+分區序號。例如，first 這個 topic 有三個分區，則其對應的文件夾爲 first-0,first-1,first-2
index 和 log 文件以當前 segment 的第一條消息的 offset 命名。
找消息的步驟 ：先在index中 查找存儲消息的編號 和 每條消息的起始偏移量再去log（真正存儲的消息）中查找數據（採用二分法查找）
kafka生產者
分區策略
分區的原因：
（1）方便在集羣中擴展，每個 Partition 可以通過調整以適應它所在的機器，而一個 topic又可以有多個 Partition 組成，因此整個集羣就可以適應任意大小的數據了；
（2）可以提高併發，因爲可以以 Partition 爲單位讀寫了
分區的原則
將 producer 發送的數據封裝成一個ProducerRecord 對象。
ISR
當leader 收到數據，所有 follower 都開始同步數據，但有一個 follower，因爲某種故障，遲遲不能與leader 進行同步，那 leader 就要一直等下去，直到它完成同步，才能發送 ack。這個問題怎麼解決呢？
Leader 維護了一個動態的 in-sync replica set (ISR)，意爲和 leader 保持同步的 follower 集合。當 ISR 中的 follower 完成數據的同步之後，leader 就會給 follower 發送 ack。如果 follower長時間 未 向 leader 同 步 數 據 ， 則 該 follower 將 被 踢 出 ISR ， 該 時 間 閾 值 由replica.lag.time.max.ms 參數設定。如果當Leader 發生故障時，就會從 ISR 中選舉新的 leader。
0.9版本之後移除的參數 ：
replica.lag.max.messags
原因：如果生產者每次發送的batch大小大於max.messags（默認10000）的值時，當leader寫完後follow開始同步數據時所有的follower與leader的差值都大於參數設置，所以所有的follower都移除出ISR，當follower寫完後又重新加入進ISR，頻繁進出ISR會增加資源消耗。也增加zk的壓力
數據可靠性
爲保證 producer 發送的數據，能可靠的發送到指定的 topic，topic 的每個 partition 收到producer 發送的數據後，都需要向 producer 發送ack（acknowledgement） 確認收到，如producer 收到 ack，就會進行下一輪的發送，否則重新發送數據。
發送ack的兩種策略
Kafka 選擇了第二種方案，原因如下：
1.同樣爲了容忍 n 臺節點的故障，第一種方案需要 2n+1 個副本，而第二種方案只需要 n+1個副本，而 Kafka 的每個分區都有大量的數據，第一種方案會造成大量數據的冗餘。
2.雖然第二種方案的網絡延遲會比較高，但網絡延遲對 Kafka 的影響較小。
ack的參數設置
（此處fllower都爲ISR中的follower）
0：producer 不等待 broker 的 ack，這一操作提供了一個最低的延遲，broker 一接收到還沒有寫入磁盤就已經返回，當 broker 故障時丟失數據機率最大；
1：producer 等待 broker 的 ack，partition 的leader 落盤成功後返回 ack，如果在 follower同步成功之前 leader 故障，那麼將會丟失數據；
-1（all）：producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盤成功後才返回 ack。但是如果在 follower 同步完成後，broker 發送 ack 之前，leader 發生故障，那麼會造成數據重複。
故障處理 （一致性問題）
HW （high watermark）所有副本中最小的LEO
LEO（log end offset）每個副本的最後一個offset
存儲數據的一致性：
follower 故障：
當follower 故障時會被臨時踢出 ISR，待該follower 恢復後，follower 會讀取本地磁盤記錄的上次的 HW，如果此時log文件高於HW會將 log 文件高於 HW 的部分截取掉，從 HW 開始向 leader 進行同步。等該 follower 的 LEO 大於等於該 Partition 的 HW，即 follower 追上 leader 之後，就可以重新加入 ISR 了。
leader故障：
leader 發生故障之後，會從 ISR 中選出一個新的 leader，之後，爲保證多個副本之間的數據一致性，其餘的 follower 會先將各自的 log 文件高於 HW 的部分截掉，然後從新的 leader同步數據。
注意：
1.從新選舉的leader自己不截取 其他follower截取到HW位置再向leader同步
2 HW只保證副本之間數據一致性問題，不能解決數據重複和丟失問題
消費數據一致性：
在leader和follower中kafka只暴露給消費者hw之前的數據 保證消費數據一致性
冪等性
解決消費者消費數據即不重複也不丟失
enable.idompotence 設置爲 true
開啓冪等性的 Producer 在初始化的時候會被分配一個 PID，發往同一 Partition 的消息會附帶 Sequence Number。而Broker 端會對<PID, Partition, SeqNumber>做緩存，當具有相同主鍵的消息提交時，Broker 只會持久化一條。
但是 PID 重啓就會變化，同時不同的 Partition 也具有不同主鍵，所以冪等性無法保證跨分區跨會話的 Exactly Once。
消費者
消費方式
kafka中consumer 採用 pull（拉）模式從 broker 中讀取數據。
push（推）模式很難適應消費速率不同的消費者，因爲消息發送速率是由 broker 決定的。它的目標是儘可能以最快速度傳遞消息，但是這樣很容易造成 consumer 來不及處理消息，而 pull 模式則可以根據 consumer 的消費能力以適當的速率消費消息
pull 模式不足之處是，如果 kafka 沒有數據，消費者可能會陷入循環中，一直返回空數據（空輪詢）。針對這一點，Kafka 的消費者在消費數據時會傳入一個時長參數 timeout，如果當前沒有數據可供消費，consumer 會等待一段時間之後再返回，這段時長即爲timeout。
分區分配策略
一個 consumer group 中有多個 consumer，一個 topic 有多個 partition，所以必然會涉及到 partition 的分配問題，即確定那個 partition 由哪個 consumer 來消費。
Kafka 有兩種分配策略，一是 RoundRobin，一是 Range（默認方式）
RoundRobin 輪詢方式 面向分組
當consumer消費多個topic時
把一個消費者組訂閱的多個topic看作一個整體，將多個 topic中的partition按照hash重新排序，將排序後的整體結果輪詢分發給消費者組
儘量做到consumer消費數據數量平均。
Range 範圍模式 面向主題
如果訂閱多個topic 可能會帶來消費者消費數據數量不對等的問題
offset的維護
由於 consumer 在消費過程中可能會出現斷電宕機等故障，consumer 恢復後，需要從故障前的位置的繼續消費，所以 consumer 需要實時記錄自己消費到了哪個 offset，以便故障恢復後繼續消費
由消費者組+topic+partition唯一決定一個offset，保證了kafka動態擴展消費者和宕機恢復後繼續消費的功能。