KRaft簡(jiǎn)介

?Kafka的共識(shí)機(jī)制KRaft，仍然處于預(yù)覽機(jī)制。未來(lái)KRaft將作為Apache Kafka的內(nèi)置共識(shí)機(jī)制將取代Zookeeper。該模式在2.8版本當(dāng)中就已經(jīng)發(fā)布了體驗(yàn)版本，在3.X系列中KRaft是一個(gè)穩(wěn)定release版本。
KRaft運(yùn)行模式的kafka集群，不會(huì)將元數(shù)據(jù)存儲(chǔ)在zookeeper中，即部署新集群的時(shí)候，無(wú)需部署zk集群，因?yàn)镵afka將元數(shù)據(jù)存儲(chǔ)在Controller節(jié)點(diǎn)的KRaft Quorum中。KRAFT可以帶來(lái)很多好處，比如可以支持更多的分區(qū)，更快速的切換Controller，也可以避免Controller緩存的元數(shù)據(jù)和zk存儲(chǔ)的數(shù)據(jù)不一致帶來(lái)的一系列問(wèn)題。

KRaft架構(gòu)

首先來(lái)看一下KRaft在系統(tǒng)架構(gòu)層面和之前的版本有什么區(qū)別。KRaft模式提出來(lái)去zookeeper后的kafka整體架構(gòu)入下圖是前后架構(gòu)圖對(duì)比：

在當(dāng)前架構(gòu)中，一個(gè)kafka集群包含多個(gè)broker節(jié)點(diǎn)個(gè)一個(gè)ZooKeeper集群。我們?cè)谶@張圖中描繪了一個(gè)典型的集群結(jié)構(gòu)：4個(gè)broker節(jié)點(diǎn)個(gè)3個(gè)ZooKeeper節(jié)點(diǎn)。kafka集群的Controller（橙色）在被選中后，會(huì)從ZooKeeper中加載他的狀態(tài)。Controller指向其他Broker節(jié)點(diǎn)的箭頭表示Controller在通知其他briker發(fā)生了變更，如Leaderanddisr和Updatemetdata請(qǐng)求。

在新的架構(gòu)中，3個(gè)Controller節(jié)點(diǎn)代替三個(gè)ZooKeeper節(jié)點(diǎn)。控制器節(jié)點(diǎn)和Broker節(jié)點(diǎn)在不同的進(jìn)程中。Controller節(jié)點(diǎn)中會(huì)選擇一個(gè)成為L(zhǎng)eader（橙色）。新架構(gòu)中，控制器不會(huì)想Broker推送更新，而是Broker從這個(gè)Controller Leader拉取元數(shù)據(jù)的更新信息。

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

部署

首先目前官方頁(yè)面上并沒(méi)有集群搭建文檔。我們下載安裝包，查看config/kraft下的README.md文件。可以看到詳細(xì)說(shuō)明。

根據(jù)說(shuō)明，這里我搭建Kraft模式的kafka集群。這里我用的是3.1版本

這里我準(zhǔn)備三臺(tái)機(jī)器：

下載

官網(wǎng)下載

上傳服務(wù)器并解壓

這里我在node2機(jī)器上傳到自己的目錄下/home/guohao

cd /home/guohao
#解壓
tar -zxvf kafka_2.13-3.1.0.tgz
cd /home/guohao/kafka_2.13-3.1.0/

配置server.properties

cd config/kraft/
vi server.properties
# 節(jié)點(diǎn)角色
process.roles=broker,controller
?
#節(jié)點(diǎn)ID，和節(jié)點(diǎn)所承擔(dān)的角色想關(guān)聯(lián)
node.id=1
?
# 集群地址
controller.quorum.voters=1@192.168.0.113:9093,2@192.168.0.114:9093,3@192.168.0.115:9093
?
#本機(jī)節(jié)點(diǎn)
listeners=PLAINTEXT://192.168.0.113:9092,CONTROLLER://192.168.0.113:9093
?
# 這里我修改了日志文件的路徑，默認(rèn)是在/tmp目錄下的
log.dirs=/home/guohao/kafka_2.13-3.1.0/kraftlog/kraft-combined-logs

Process.Roles

每個(gè)Kafka服務(wù)器現(xiàn)在都有一個(gè)新的配置項(xiàng)，叫做Process.Roles, 這個(gè)參數(shù)可以有以下值:

• 如果Process.Roles = Broker, 服務(wù)器在KRaft模式中充當(dāng) Broker。
• 如果Process.Roles = Controller, 服務(wù)器在KRaft模式下充當(dāng) Controller。

• 如果Process.Roles = Broker,Controller，服務(wù)器在KRaft模式中同時(shí)充當(dāng) Broker 和Controller。
• 如果process.roles 沒(méi)有設(shè)置。那么集群就假定是運(yùn)行在ZooKeeper模式下。

如前所述，目前不能在不重新格式化目錄的情況下在ZooKeeper模式和KRaft模式之間來(lái)回轉(zhuǎn)換。同時(shí)充當(dāng)Broker和Controller的節(jié)點(diǎn)稱(chēng)為“組合”節(jié)點(diǎn)。

對(duì)于簡(jiǎn)單的場(chǎng)景，組合節(jié)點(diǎn)更容易運(yùn)行和部署，可以避免多進(jìn)程運(yùn)行時(shí)，JVM帶來(lái)的相關(guān)的固定內(nèi)存開(kāi)銷(xiāo)。關(guān)鍵的缺點(diǎn)是，控制器將較少地與系統(tǒng)的其余部分隔離。例如，如果代理上的活動(dòng)導(dǎo)致內(nèi)存不足，則服務(wù)器的控制器部分不會(huì)與該OOM條件隔離。

Quorum Voters

系統(tǒng)中的所有節(jié)點(diǎn)都必須設(shè)置 `controller.quorum.voters` 配置。這個(gè)配置標(biāo)識(shí)有哪些節(jié)點(diǎn)是 Quorum 的投票者節(jié)點(diǎn)。所有想成為控制器的節(jié)點(diǎn)都需要包含在這個(gè)配置里面。這類(lèi)似于在使用ZooKeeper時(shí)，使用ZooKeeper.connect配置時(shí)必須包含所有的ZooKeeper服務(wù)器。

然而，與ZooKeeper配置不同的是，`controller.quorum.voters` 配置需要包含每個(gè)節(jié)點(diǎn)的id。格式為: id1@host1:port1,id2@host2:port2。

分發(fā)并配置

cd /home/guohao
#解壓
tar -zxvf kafka_2.13-3.1.0.tgz
cd /home/guohao/kafka_2.13-3.1.0/

#node3 server.properties
# 節(jié)點(diǎn)角色
process.roles=broker,controller
?
#節(jié)點(diǎn)ID，和節(jié)點(diǎn)所承擔(dān)的角色想關(guān)聯(lián)
node.id=2
?
# 集群地址
controller.quorum.voters=1@192.168.0.113:9093,2@192.168.0.114:9093,3@192.168.0.115:9093
?
#本機(jī)節(jié)點(diǎn)
listeners=PLAINTEXT://192.168.0.114:9092,CONTROLLER://192.168.0.114:9093
?
# 這里我修改了日志文件的路徑，默認(rèn)是在/tmp目錄下的
log.dirs=/home/guohao/kafka_2.13-3.1.0/kraftlog/kraft-combined-logs

#node4 server.properties
# 節(jié)點(diǎn)角色
process.roles=broker,controller
?
#節(jié)點(diǎn)ID，和節(jié)點(diǎn)所承擔(dān)的角色想關(guān)聯(lián)
node.id=3
?
# 集群地址
controller.quorum.voters=1@192.168.0.113:9093,2@192.168.0.114:9093,3@192.168.0.115:9093
?
#本機(jī)節(jié)點(diǎn)
listeners=PLAINTEXT://192.168.0.115:9092,CONTROLLER://192.168.0.115:9093
?
# 這里我修改了日志文件的路徑，默認(rèn)是在/tmp目錄下的
log.dirs=/home/guohao/kafka_2.13-3.1.0/kraftlog/kraft-combined-logs

運(yùn)行KRaft集群

運(yùn)行KRaft集群，主要分為三步：

• 用kafka-storage.sh 生成一個(gè)唯一的集群ID

./bin/kafka-storage.sh random-uuid

#會(huì)生成一個(gè)uuid 

• 用kafka-storage.sh 格式化存儲(chǔ)數(shù)據(jù)的目錄

1. ?
   #每個(gè)節(jié)點(diǎn)都要執(zhí)行
2. ?
   #./bin/kafka-storage.sh format -t <uuid> -c ./config/kraft/server.properties
3. ?
   ./bin/kafka-storage.sh format -t 04ofzeqFRgqBWQGtLEqmNQ -c ./config/kraft/server.properties

• 用bin/kafka-server-start.sh 啟動(dòng)Kafka Server

1. ?
   #每個(gè)節(jié)點(diǎn)都要執(zhí)行
2. ?
   ./bin/kafka-server-start.sh ./config/kraft/server.properties

運(yùn)行KRaft集群

運(yùn)行KRaft集群，主要分為三步：

• 用kafka-storage.sh 生成一個(gè)唯一的集群ID

./bin/kafka-storage.sh random-uuid

#會(huì)生成一個(gè)uuid 

• 用kafka-storage.sh 格式化存儲(chǔ)數(shù)據(jù)的目錄

1. ?
   #每個(gè)節(jié)點(diǎn)都要執(zhí)行
2. ?
   #./bin/kafka-storage.sh format -t <uuid> -c ./config/kraft/server.properties
3. ?
   ./bin/kafka-storage.sh format -t 04ofzeqFRgqBWQGtLEqmNQ -c ./config/kraft/server.properties

• 用bin/kafka-server-start.sh 啟動(dòng)Kafka Server

1. ?
   #每個(gè)節(jié)點(diǎn)都要執(zhí)行
2. ?
   ./bin/kafka-server-start.sh ./config/kraft/server.properties

實(shí)用工具

使用過(guò)程中，如果遇到問(wèn)題，可能需要查看元數(shù)據(jù)日志。在KRaft中，有兩個(gè)命令行工具需要特別關(guān)注下。kafka-dump-log.sh和kafka-metadata-shell.log。

KRaft模式下 ，原先保存在Zookeeper上的數(shù)據(jù)，全部轉(zhuǎn)移到了一個(gè)內(nèi)部的Topic：@metadata上了。比如Broker信息，Topic信息等等。所以我們需要有一個(gè)工具查看當(dāng)前的數(shù)據(jù)內(nèi)容。

Kafka-dump-log.sh是一個(gè)之前就有的工具，用來(lái)查看Topic的的文件內(nèi)容。這工具加了一個(gè)參數(shù)--cluster-metadata-decoder用來(lái)，查看元數(shù)據(jù)日志，

平時(shí)我們用zk的時(shí)候，習(xí)慣了用zk命令行查看數(shù)據(jù)，簡(jiǎn)單快捷。bin目錄下自帶了kafka-metadata-shell.sh工具，可以允許你像zk一樣方便的查看數(shù)據(jù)。

總結(jié)

Kafka 經(jīng)常被認(rèn)為是一個(gè)重量級(jí)的基礎(chǔ)設(shè)施，管理Apache Zookeeper的復(fù)雜性就是這種看法存在的重要原因。而KRaft模式提供了一種很棒的、輕量級(jí)的方式來(lái)開(kāi)始使用Kafka，或者可以使用它作為ActiveMQ或RabbitMQ等消息隊(duì)列的替代方案。