如何配置KRaft

本篇內容介紹了“如何配置KRaft”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

1. 如何開始KRaft?

Kafka使用內嵌的KRaft替代了ZooKeeper，是一個非常大的進步，因為像ES之類的分布式系統，這種集群meta信息的同步，都是自循環的。

但如何使用KRaft啟動呢?很多同學直接暈菜了，這方面的資料也比較少，但使用起來非常簡單。

我們注意到，在config目錄下，多了一個叫做kraft的目錄，里面包含著一套新的配置文件，可以直接摒棄對ZK的依賴。

通過下面三行命令，即可開啟一個單機的broker，從始至終沒有ZK的參與。

# ./bin/kafka-storage.sh random-uuid # ./bin/kafka-storage.sh format -t TBYU7WMiREexuZqrjKG60g -c ./config/kraft/server.properties # ./bin/kafka-server-start.sh ./config/kraft/server.properties

經過一陣噼里啪啦的運行，No ZK的Kafka已經啟動起來了。

就是這么簡單。

2. 如何配置的?

kafka又加了一個內部主題，叫做@metadata，用來存這些元信息。

接下來我們就要看一些關鍵的配置信息。你可以使用vimdiff config/server.properties  config/kraft/server.properties看一下這些主要的區別。

首先，kraft多了一個叫做process.roles的配置。在我們的配置文件里它是這樣的。

process.roles=broker,controller

它其實有三個取值。

• broker: 這臺機器將僅僅當作一個broker

• controller: 作為 Raft quorum的控制器之一進行啟動

• broker,controller: 包含兩者的功能

熟悉ES的同學可以看出，這些劃分就像是es的master和node，所以分布式的概念其實在一定程度上是相通的。

接下來是監聽地址的變化，因為我們的server有了兩個功能，所以也就需要開啟兩個端口。

listeners=PLAINTEXT://:9092,CONTROLLER://:9093

另外，還有一個叫做node.id的東西。不同于原來的broker.id，這個nodeid是用來投票用的。

node.id=1

因為raft協議的特性，我們的投票配置就要使用上面的node.id。寫起來比較怪異是不是?但總比Zk的好看多了。所以這些配置在后面的版本是有可能改動的。

controller.quorum.voters=1@localhost:9093

這就是配置文件的主要區別。我們來看看它的集合。

process.roles=broker,controller  listeners=PLAINTEXT://:9092,CONTROLLER://:9093 node.id=1    controller.quorum.voters=1@localhost:9093

3. 為什么要干掉ZK?

Kafka作為一個消息隊列，竟然要依賴一個重量級的協調系統ZooKeeper，不得不說是一個笑話。同樣作為消息隊列，人家RabbitMQ早早的就實現了自我管理。

Zookeeper非常笨重，還要求奇數個節點的集群配置，擴容和縮容也不方便。Zk的配置方式，也和kafka的完全不一樣，要按照調優Kafka，竟然還要兼顧另外一個系統，這真是日了狗了。

Kafka要想往輕量級，開箱即用的方向發展，就不得不干掉Zk。

另外，由于Zk和Kafka畢竟不是在一個存儲體系里面，當Topic和Partition的數量上了規模，數據同步問題就變的顯著起來。Zk是可靠，但是它慢啊，完全不如放在Kafka的日志存儲體系里面，這對標榜速度的Kafka來說，是不得不繞過的一環。

使用過Kafka-admin的同學，應該都對緩慢的監控數據同步歷歷在目。它需要先從zk上轉一圈，獲取一些元數據信息，然后再從Kafka的JMX接口中拉取數據。這么一轉悠，就幾乎讓大型集群死翹翹。

4. 會有哪些改變?

部署更簡單。

首先，部署變的更加簡單。對于一些不太追求高可用的系統，甚至一個進程就能把可愛的kafka跑起來。我們也不需要再申請對zookeeper友好的SSD磁盤，也不用再關注zk的容量是不是夠用了。

監控更便捷。

其次，由于信息的集中，從Kafka獲取監控信息，就變得輕而易舉，不用再到zk里轉一圈了。與grafana/kibana/promethus等系統的集成，指日可待。

速度更快捷。

最重要的當然是速度了。Raft比ZK的ZAB協議更加易懂，也更加高效，partition的主選舉將變得更快捷，controller的調度速度將上一個檔次。

以后，再也不會有這樣的連接方式。

zookeeper.connect=zookeeper:2181

取而代之的，只會剩下bootstrap的連接方式。Kafka的節點，越來越像對等節點。

bootstrap.servers=broker:9092

kafka還提供了一個叫做kafka-metadata-shell.sh的工具，能夠看到topic和partion的分布，這些信息原來是可以通過zk獲取的，現在可以使用這個命令行獲取。

$ ./bin/kafka-metadata-shell.sh  --snapshot /tmp/kraft-combined-logs/\@metadata-0/00000000000000000000.log >> ls / brokers  local  metadataQuorum  topicIds  topics >> ls /topics foo >> cat /topics/foo/0/data {   "partitionId" : 0,   "topicId" : "5zoAlv-xEh9xRANKXt1Lbg",   "replicas" : [ 1 ],   "isr" : [ 1 ],   "removingReplicas" : null,   "addingReplicas" : null,   "leader" : 1,   "leaderEpoch" : 0,   "partitionEpoch" : 0 } >> exit

“如何配置KRaft”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！