Kafka 常見問題 一年將盡夜，萬里未歸人。 1、Kafka 簡介 Apache Kafka是一個分散式發佈 - 訂閱消息系統和一個強大的隊列, 可以處理大量的數據, 並使您能夠將消息從一個端點傳遞到另一個端點。 Kafka適合離線和線上消息消費，Kafka消息保留在磁碟上, 併在群集內複製以防止 ...
Kafka 常見問題
一年將盡夜，萬里未歸人。
1、Kafka 簡介
Apache Kafka是一個分散式發佈 - 訂閱消息系統和一個強大的隊列, 可以處理大量的數據, 並使您能夠將消息從一個端點傳遞到另一個端點。 Kafka適合離線和線上消息消費，Kafka消息保留在磁碟上, 併在群集內複製以防止數據丟失。 Kafka構建在ZooKeeper同步服務之上，依賴 Zookeeper，它與Apache Storm和Spark非常好地集成, 用於實時流式數據分析。 Kafka 依賴於日誌順序寫, 因此支持消息回溯和支撐高性能讀寫。2、Kafka 的 Broker 基本概念
Kafka的 Server包含多個 Topic 、Partition 和 Replica，負責協調 Producer 和 Consumer。主從結構為: 主節點為 Controller, 從節點為從節點 Kafka 啟動是會往 Zookeeper 中註冊當前Broker 信息，誰先註冊誰就是 Controller，讀取註冊上來的從節點的數據(通過監聽機制), 生成集群的元數據信息, 之後把這些信息都分發給其他的伺服器, 讓其他伺服器能感知到集群中其它成員的存在3、Kafka 的 Topic 基本概念
標準 MQ 中的 Queue，Kafka 中一個 Topic 的消息會保存在不同的 Partition (不同的 Broker)來保證高可用。4、Kafka 的 Partition (分區) 基本概念
- 可以理解為將標準 MQ 的 Queue 的消息進行拆分, 來實現高可用。
- Producer 發送的 Message, 根據 key 和 partition 數進行 hash, 然後進行投遞。
- 一個分區只能被同一個 Consumer Group 中的一個 Consumer 消費，分區內消費有序。
5、Replica (備份)
每一個 Partition 的備份。 Replica 的小於等於 Broker 的數量。 Leader: Replica領導節點, 每一個 Partition 都有對應的 Leader 節點(Broker)，Producer 寫數據時, 只會往 Leader 中寫，Consumer 讀數據也是從 Leader 中讀。 Follower: Replica跟隨節點, 用於複製領導節點的數據，複製 Leader 消息採用 pull (拉)模式。、# Broker 設置副本數量 預設為 3
default.replication.factor
# Topic 設置副本數量
replication-factor
6、ISR (In-Sync Replica)
Leader維護一個與其基本保持同步的Replica列表, 每個Partition都會有一個ISR, 而且是由leader動態維護。如果一個flower比一個leader落後太多, 或者超過一定時間未發起數據複製請求, 則leader將其重ISR中移除。當ISR中所有Replica都向Leader發送ACK時, leader才commit。 Leader 宕機之後, 會從 ISR 選擇數據最新的 Follower 來當做 Leader 如果 ISR 全部宕機, 則選擇第一個回覆的 Replica 當做 Leader 節點 (消息可能會丟失或者重覆消費)。7、水印備份機制
水印備份機制即 LEO (last end offffset)，日誌末端位移, 記錄了該副本對象底層日誌文件中下一條消息的位移值, 副本寫入消息的時候, 會自動更新 LEO 值 Leader 會保存兩個 LEO 值, 一個是自己的 LEO 值, 另外一個是 remote 的 LEO 值。Follower 每次 fetch 請求都會攜帶當前 LEO, Leader 會選擇最小的 LEO來更新 HW HW (high watermark): 從名字可以知道, 該值叫高水印值, HW 一定不會大於 LEO 值, 小於 HW 值的消息被認為是"已提交"或"已備份"的消息, 並對消費者可見。8、Message
標準 MQ 的 Queue 中的 Message，即一條消息。9、Producer
標準 MQ 中的發送方，發送給 Broker 使用push (推)模式。10、數據一致性保證 (消息不丟失)
request.required.asks=0
- 0: 相當於非同步的, 不需要leader給予回覆, producer立即返回, 發送就是成功,那麼發送消息網路超時或broker crash(1.Partition的Leader還沒有commit消息 2.Leader與Follower數據不同步), 既有可能丟失也可能會重發。
- 1：當leader接收到消息之後發送ack, 丟會重發, 丟的概率很小。
- -1：當所有的follower都同步消息成功後發送ack. 不會丟失消息。
11、Consumer
標準 MQ 中的消費方，接受 Broker 使用 pull (拉)模式, 預設 100ms 拉一次，Consumer 消費的是Partition 的數據。 消息丟失: 手動確認 ack 而不是自動提交。 消息重覆: 消費端冪等處理。12、Consumer Group
在 Kafka 中, 一個 Topic 是可以被一個消費組消費, 一個Topic 分發給 Consumer Group 中的Consumer 進行消費, 保證同一條 Message 不會被不同的 Consumer 消費。 註意: 當Consumer Group的 Consumer 數量大於 Partition 的數量時, 超過 Partition 的數量將會拿不到消息。13、分片規則
Kafka分配Replica的演算法有兩種: RangeAssignor 和 RoundRobinAssignor 預設為RangeAssignor: 1. 將所有Broker(假設共n個Broker)和待分配的Partition排序 2. 將第i個Partition分配到第(i mod n)個Broker上 3. 將第i個Partition的第j個Replica分配到第((i + j) mod n)個Broker上14、Rebalance (重平衡)
Rebalance 本質上是一種協議, 規定了一個 Consumer Group 下的所有 consumer 如何達成一致，來分配訂閱 Topic 的每個分區。 Rebalance 發生時, 所有的 Consumer Group 都停止工作, 直到 Rebalance 完成。15、Coordinator
Group Coordinator 是一個服務, 每個 Broker 在啟動的時候都會啟動一個該服務 Group Coordinator 的作用是用來存儲 Group 的相關 Meta 信息, 並將對應 Partition 的 Offset 信息記錄到 Kafka 內置 Topic(__consumer_offsets)中 Kafka 在0.9之前是基於 Zookeeper 來存儲Partition的 offset 信息(consumers/{group}/offsets/{topic}/{partition}), 因為 Zookeeper 並不適用於頻繁的寫操作, 所以在0.9之後通過內置 Topic 的方式來記錄對應 Partition 的 offset。16、Rebalace 流程
Rebalance 過程分為兩步：Join 和 Sync 1. Join: 顧名思義就是加入組。這一步中, 所有成員都向 Coordinator 發送 JoinGroup 請求, 請求加入消費組，一旦所有成員都發送了 JoinGroup 請求, Coordinator 會從中選擇一個Consumer 擔任 Leader 的角色, 並把組成員信息以及訂閱信息發給 Consumer Leader ，註意Consumer Leader 和 Coordinator不是一個概念。Consumer Leader負責消費分配方案的制定。 2. Sync: Consumer Leader 開始分配消費方案, 即哪個 Consumer 負責消費哪些 Topic 的哪些Partition。一旦完成分配, Leader 會將這個方案封裝進 SyncGroup 請求中發給 Coordinator,非 Leader 也會發 SyncGroup 請求, 只是內容為空。Coordinator 接收到分配方案之後會把方案塞進SyncGroup的Response中發給各個Consumer，這樣組內的所有成員就都知道自己應該消費哪些分區了。17、日誌索引
Kafka 能支撐 TB 級別數據, 在日誌級別有兩個原因: 順序寫和日誌索引。 Kafka 在一個日誌文件達到一定數據量 (1G) 之後, 會生成新的日誌文件, 大數據情況下會有多個日誌文件, 通過偏移量來確定到某行紀錄時, 如果遍歷所有的日誌文件, 那效率自然是很差的。Kafka在日誌級別上抽出來一層日誌索引, 來方便根據 offset 快速定位到是某個日誌文件。 每一個 partition 對應多個個 log 文件(最大 1G), 每一個 log 文件又對應一個 index 文件。18、Kafka 高性能、高吞吐 的原因？
分區、順序寫、批發送和數據壓縮等。19、分區的原因
如果我們假設像標準 MQ 的 Queue, 為了保證一個消息只會被一個消費者消費, 那麼我們第一想到的就是加鎖。對於發送者, 在多線程並且非順序寫環境下, 保證數據一致性, 我們同樣也要加鎖。一旦考慮到加鎖, 就會極大的影響性能。我們再來看Kafka 的 Partition, Kafka 的消費模式和發送模式都是以 Partition 為分界，也就是說對於一個 Topic 的併發量限制在於有多少個 Partition, 就能支撐多少的併發，可以參考 Java 1.7 的 ConcurrentHashMap 的桶設計, 原理一樣, 有多少桶, 支持多少的併發。20、順序寫
磁碟的順序寫的性能要比記憶體隨機寫的還要強。21、批發送
批處理是一種常用的用於提高I/O性能的方式。對Kafka而言, 批處理既減少了網路傳輸的Overhead, 又提高了寫磁碟的效率。Kafka 0.82 之後是將多個消息合併之後再發送, 而並不是send一條就立馬發送(之前支持)。# 批量發送的基本單位, 預設是16384Bytes, 即16kB
batch.size
# 延遲時間 linger.ms
# 兩者滿足其一便發送
