Kraft模式

Kafka Kraft模式（KRaft）是Apache Kafka自2.8版本引入的核心功能，旨在通過移除對ZooKeeper的依賴，簡化集群架構并提升性能。以下是其核心內容的總結：

1. 什么是Kraft模式？

Kraft模式（Kafka Raft元數據模式）是Kafka內置的分布式共識協議，基于Raft算法實現集群元數據（如主題、分區、副本狀態等）的自主管理。它替代了傳統ZooKeeper模式，使Kafka集群無需外部協調服務即可運行。

2. 為什么引入Kraft模式？

• 簡化架構：消除對ZooKeeper集群的依賴，減少運維復雜度。
• 提升擴展性：通過Raft協議實現元數據的高效同步，支持百萬級分區（遠超ZooKeeper的數萬限制）。
• 增強可靠性：控制器故障恢復時間縮短至毫秒級，且元數據變更通過Raft協議保證強一致性。
• 統一管理：將元數據管理與Kafka自身深度整合，統一安全模型和配置管理。

3. 核心優勢

• 部署與管理更簡單：僅需維護Kafka節點，無需額外部署ZooKeeper。
• 性能優化：元數據存儲本地化，減少跨系統通信延遲。
• 高可用性：通過Raft協議的多數派選舉機制，確保集群在部分節點故障時仍正常運行。
• 快速恢復：控制器故障后，新控制器可直接從內存加載元數據，無需從外部存儲恢復。

4. 架構與工作原理

• 控制器節點：
  • 集群中指定部分節點（如3個）作為控制器候選，通過Raft協議選舉產生主控制器（Active Controller），其余為備用（Standby）。
  • 控制器節點通過controller.quorum.voters配置定義，格式為id@host:port。
• 元數據存儲：
  • 元數據通過名為__cluster_metadata的主題存儲，支持日志壓縮和快照，確保數據持久化。
• Broker通信：
  • Broker通過心跳機制與控制器保持會話，主動拉取元數據更新，而非被動接收廣播。

5. 部署與配置要點

• 關鍵配置：
  • process.roles：定義節點角色（controller、broker或混合模式）。
  • node.id：唯一標識節點，需與controller.quorum.voters中的ID一致。
  • listeners：配置控制器通信端口（如CONTROLLER://host:9093）。
• 初始化集群：
  使用kafka-storage initialize命令生成元數據，需指定配置文件和引導服務器。
• 生產建議：
  • 控制器節點數建議為3或5（奇數），確保多數派存活。
  • 避免混合模式（同時作為控制器和Broker），推薦隔離部署以提升穩定性。

6. 適用場景與最佳實踐

• 適用場景：
  • 大規模集群（百萬級分區）。
  • 對延遲敏感的實時數據處理。
  • 需要簡化運維的邊緣計算或小型部署。
• 最佳實踐：
  • 遷移前充分測試，優先新建KRaft集群。
  • 監控控制器狀態和Raft日志同步情況。
  • 定期備份元數據存儲目錄。

總結

Kraft模式是Kafka架構的重大演進，通過自管理的Raft協議顯著提升了集群的可擴展性、可靠性和運維效率。隨著Kafka版本的迭代（如3.3+），KRaft已成為生產環境的首選模式，尤其適合需要高性能、低延遲的分布式消息系統場景。

KIP-833: Mark KRaft as Production Ready

KIP-833: Mark KRaft as Production Ready

除了Kraft模式，Kafka還有以下常用模式：

• ZooKeeper模式：這是Kafka在KRaft出現之前長期使用的模式。Kafka依賴ZooKeeper來管理元數據，比如集群成員信息、主題（Topic）配置、分區（Partition）分配等。ZooKeeper為Kafka提供了分布式協調服務，幫助Kafka處理諸如選舉領導者（Leader）副本、監控Broker狀態等任務。但隨著Kafka集群規模擴大，ZooKeeper可能成為性能瓶頸，并且其復雜的配置和維護也增加了管理難度。
• 消息消費模式：
  • 發布訂閱模式（Publish/Subscribe）：一對多的關系，消費者消費完消息后，消息不會立即被刪除，而是會存儲一段時間，該模式下的消息會被所有訂閱該主題的消費者消費。比如在實時數據分析場景中，多個數據分析應用可以同時訂閱同一個主題的業務數據，進行各自維度的分析 。此模式下又分為推模式（queue直接將消息推給消費者，可能出現消費者處理不過來的情況）和拉模式（消費者主動去拉取queue中的消息，可按自身消費能力拉取，但需持續維護拉取任務）。
  • 點對點模式（Point-to-Point，P2P）：一對一的關系，消費者主動拉取數據，消息確認被消費后，消息隊列會刪除該消息，一條消息只會被一個消費者消費。在Kafka中，同一消費者組里面的消費者，消費消息類似點對點模式，不過消費完消息后消息不會被刪除。
• 數據可靠性模式（基于生產者角度，通過acks參數設置） ：
  • acks = 0：生產者無需等待來自Broker的確認就繼續發送下一批消息，傳輸效率最高，但可靠性最低，可能丟數據，不會重復發送，因為這種模式下重試機制會失效。
  • acks = 1（默認）：生產者在ISR（In-Sync Replicas，副本同步隊列 ）中的Leader已成功收到數據并得到確認后，才發送下一條消息。如果Leader宕機，可能會丟失數據。
  • acks = -1或all：生產者需要等待ISR中的所有Follower都確認接收到數據后，才算一次發送完成，可靠性最高，但不能完全保證數據不丟失（如ISR中只剩Leader時，就類似acks = 1的情況），且開啟失敗重試可能導致消息重復發送。
• 消費者消費語義模式：
  • at most once（最多一次）：保證每一條消息commit成功之后，再進行消費處理。設置自動提交為false，接收到消息之后，首先commit，然后再進行消費。特點是不會重復發送，但可能丟失消息。
  • at least once（至少一次）：保證每一條消息處理成功之后，再進行commit。設置自動提交為false，消息處理成功之后，手動進行commit。特點是會重復發送，但消息不會丟失。
  • exactly once（恰好一次）：發送端數據發送成功，并且成功的消息只發送一次（重復的數據被服務器拒絕），消費端結合冪等性實現。例如，Kafka 0.11.0.0 及以后版本通過生產者冪等性和事務機制來實現Exactly - once語義，確保消息在生產和消費過程中都只被處理一次。

啟用 Kafka KRaft 模式

啟用 Kafka KRaft 模式需按以下標準流程操作：

1. 配置 server.properties 文件

• 核心配置項：
  • process.roles：定義節點角色，取值：
    • controller,broker：節點同時作為控制器和代理（測試場景）。
    • controller：僅作為控制器（生產環境推薦多節點）。
    • broker：僅作為代理。
  • node.id：為節點設置唯一 ID，集群內所有節點（控制器、代理）的 node.id 不可重復。
  • controller.quorum.voters：以 {id}@{host}:{port} 格式定義控制器仲裁列表，例如 1@host1:9093,2@host2:9093,3@host3:9093，其中 id 需與節點的 node.id 一致。
  • 其他基礎配置：如 listeners（監聽地址）、inter.broker.listener.name（代理間通信協議）、log.dirs（日志存儲路徑）等。

2. 初始化集群元數據

使用 kafka-storage 工具初始化 KRaft 集群元數據：

# 命令格式
bin/kafka-storage initialize \-bootstrap-server localhost:9093 \-cluster-id <自動生成，首次可不填> \-configuration config/kraft/server.properties

• 執行后會生成集群元數據，存儲在 log.dirs 配置的目錄中。

3. 啟動 Kafka 服務

bin/kafka-server-start.sh config/kraft/server.properties

生產環境注意事項

• 控制器節點數量：至少 3 個控制器節點，確保仲裁機制正常（遵循多數原則）。
• 網絡與端口：控制器間通過 controller.quorum.voters 配置的端口通信，需開放對應端口。
• 遷移場景：若從 ZooKeeper 模式遷移，需參考官方遷移文檔逐步操作，避免數據丟失。

完整流程參考 Apache Kafka 官方文檔：KRaft Documentation。