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 
# 兩者滿足其一便發送

22、資料壓縮

資料壓縮的一個基本原理是, 重復資料越多壓縮效果越好. 因此將整個Batch的資料一起壓縮能更大幅度減小資料量, 從而更大程度提高網路傳輸效率Broker接收訊息后，并不直接解壓縮，而是直接將訊息以壓縮后的形式持久化到磁盤 Consumer接受到壓縮后的資料再解壓縮， 整體來講: Producer 到 Broker, 副本復制, Broker 到 Consumer 的資料都是壓縮后的資料, 保證高效率的傳輸，         一年將盡夜 萬里未歸人        

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/535972.html

標籤：Java

上一篇：【深入淺出 Yarn 架構與實作】3-2 Yarn Client 撰寫

下一篇：服務商系統集中高頻交易CPU飆升問題解決優化程序