普天同慶!最新版的Kafka 2.8.0
,移除了對Zookeeper
的依賴,通過kraft
進行自己的集羣管理。很好很好,終於有點質的改變了。
一聽到KRaft,我們就想到了Raft協議。Raft協議是當今最流行的分佈式協調算法,Etcd、Consul等系統的基礎,就來自於此。現在Kafka也有了。
由於這個功能太新了,所以2.8.0版本默認還是要用ZooKeeper的,但並不妨礙我們嚐嚐鮮。另外,不要太激動了,據官方聲稱有些功能還不是太完善,所以不要把它用在線上。
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
最後,還是要提醒一下,目前不要在線上環境開啓這個功能,還是老老實實用ZK吧。功能就是原因,因爲這些功能的配套設施還沒有到位,代碼也沒有達到讓人放心的程度。你要是用了,很可能會因爲工具不全或者難纏的bug痛不欲生。
不過,這勇敢的第一步已經邁出,方向也已經指明,我們剩下的就是等待了。無論如何,幹掉Zk,是件大好事。
拓展乾貨閱讀:一線大廠面試題、高併發等主流技術資料
文章來源:公衆號——小姐姐味道
如果本文對你有所幫助!請點擊頭像查看“傻姑個人簡介”分享更多一線大廠面試題、高併發等主流技術資料 ,幫助大家一起學習成長!