KRaft簡介
Kafka的共識機制KRaft，仍然處于預覽機制。未來KRaft將作為Apache Kafka的內置共識機制將取代Zookeeper。該模式在2.8版本當中就已經發布了體驗版本，在3.X系列中KRaft是一個穩定release版本。
KRaft運行模式的kafka集群，不會將元數據存儲在zookeeper中，即部署新集群的時候，無需部署zk集群，因為Kafka將元數據存儲在Controller節點的KRaft Quorum中。KRAFT可以帶來很多好處，比如可以支持更多的分區，更快速的切換Controller，也可以避免Controller緩存的元數據和zk存儲的數據不一致帶來的一系列問題。

KRaft架構

首先來看一下KRaft在系統架構層面和之前的版本有什么區別。KRaft模式提出來去zookeeper后的kafka整體架構入下圖是前后架構圖對比：

在當前架構中，一個kafka集群包含多個broker節點個一個ZooKeeper集群。我們在這張圖中描繪了一個典型的集群結構：4個broker節點個3個ZooKeeper節點。kafka集群的Controller（橙色）在被選中后，會從ZooKeeper中加載他的狀態。Controller指向其他Broker節點的箭頭表示Controller在通知其他briker發生了變更，如Leaderanddisr和Updatemetdata請求。

在新的架構中，3個Controller節點代替三個ZooKeeper節點。控制器節點和Broker節點在不同的進程中。Controller節點中會選擇一個成為Leader（橙色）。新架構中，控制器不會想Broker推送更新，而是Broker從這個Controller Leader拉取元數據的更新信息。

注意：盡管Controller進程在邏輯上與Broker進程是分離的，但他們不需要再物理上分離，即在某些情況下，部分所有Controller進程和Broker進程可以使同一個進程，即一個broker節點即是Broker也是Controller。另外在同一個節點上可以運行兩個進程，一個是Controller進程，一個是broker進程，這相當于在較小的及群眾。Zookeeper進程可以想Kafka Broker一樣部署在相同的節點上。

部署
首先目前官方頁面上并沒有集群搭建文檔。我們下載安裝包，查看config/kraft下的README.md文件。可以看到詳細說明。

?