阿里大牛的Kafka動態配置瞭解下?

本文已收錄GitHub,更有互聯網大廠面試真題,面試攻略,高效學習資料等

什麼是動態Broker參數配置?

在開始分享之前,我們先來複習一下設置 Kafka 參數,特別是 Broker 端參數的方法。

在 Kafka 安裝目錄的 config 路徑下,有個 server.properties 文件。通常情況下,我們會指定這個文件的路徑來啓動 Broker。如果要設置 Broker 端的任何參數,我們必須在這個文件中顯式地增加一行對應的配置,之後啓動 Broker 進程,令參數生效。我們常見的做法是,一次性設置好所有參數之後,再啓動 Broker。當後面需要變更任何參數時,我們必須重啓 Broker。但生產環境中的服務器,怎麼能隨意重啓呢?所以,目前修改 Broker 端參數是非常痛苦的過程。

基於這個痛點,社區於 1.1.0 版本中正式引入了動態 Broker 參數(Dynamic BrokerConfigs)。所謂動態,就是指修改參數值後,無需重啓 Broker 就能立即生效,而之前在server.properties 中配置的參數則稱爲靜態參數(Static Configs)。顯然,動態調整參數值而無需重啓服務,是非常實用的功能。如果你想體驗動態 Broker 參數的話,那就趕快升級到 1.1 版本吧。

當然了,當前最新的 2.3 版本中的 Broker 端參數有 200 多個,社區並沒有將每個參數都升級成動態參數,它僅僅是把一部分參數變成了可動態調整。那麼,我們應該如何分辨哪些參數是動態參數呢?

如果你打開 1.1 版本之後(含 1.1)的 Kafka 官網,你會發現Broker Configs表中增加了Dynamic Update Mode 列。該列有 3 類值,分別是 read-only、per-broker 和 cluster-wide。我來解釋一下它們的含義。

  • read-only。被標記爲 read-only 的參數和原來的參數行爲一樣,只有重啓 Broker,才能令修改生效。
  • per-broker。被標記爲 per-broker 的參數屬於動態參數,修改它之後,只會在對應的Broker 上生效。
  • cluster-wide。被標記爲 cluster-wide 的參數也屬於動態參數,修改它之後,會在整個集羣範圍內生效,也就是說,對所有 Broker 都生效。你也可以爲具體的 Broker 修改cluster-wide 參數。

我來舉個例子說明一下 per-broker 和 cluster-wide 的區別。Broker 端參數 listeners 想必你應該不陌生吧。它是一個 per-broker 參數,這表示你只能爲單個 Broker 動態調整listeners,而不能直接調整一批 Broker 的 listeners。log.retention.ms 參數是 cluster-wide 級別的,Kafka 允許爲集羣內所有 Broker 統一設置一個日誌留存時間值。當然了,你也可以爲單個 Broker 修改此值。

使用場景

你可能會問,動態 Broker 參數的使用場景都有哪些呢?實際上,因爲不必重啓 Broker,動態 Broker 參數的使用場景非常廣泛,通常包括但不限於以下幾種:

  • 動態調整 Broker 端各種線程池大小,實時應對突發流量。
  • 動態調整 Broker 端連接信息或安全配置信息。
  • 動態更新 SSL Keystore 有效期。
  • 動態調整 Broker 端 Compact 操作性能。
  • 實時變更 JMX 指標收集器 (JMX Metrics Reporter)。

在這些使用場景中,動態調整線程池大小應該算是最實用的功能了。很多時候,當 KafkaBroker 入站流量(inbound data)激增時,會造成 Broker 端請求積壓(Backlog)。有了動態參數,我們就能夠動態增加網絡線程數和 I/O 線程數,快速消耗一些積壓。當突發流量過去後,我們也能將線程數調整回來,減少對資源的浪費。整個過程都不需要重啓Broker。你甚至可以將這套調整線程數的動作,封裝進定時任務中,以實現自動擴縮容。

如何保存?

由於動態配置的特殊性,它必然有和普通只讀參數不同的保存機制。下面我來介紹一下Kafka 是如何保存動態配置的。

首先,Kafka 將動態 Broker 參數保存在 ZooKeeper 中,具體的 znode 路徑如下圖所示。

我來解釋一下圖中的內容。changes 是用來實時監測動態參數變更的,不會保存參數值;topics 是用來保存 Kafka 主題級別參數的。雖然它們不屬於動態 Broker 端參數,但其實它們也是能夠動態變更的。

users 和 clients 則是用於動態調整客戶端配額(Quota)的 znode 節點。所謂配額,是指Kafka 運維人員限制連入集羣的客戶端的吞吐量或者是限定它們使用的 CPU 資源。

分析到這裏,我們就會發現,/config/brokers znode 纔是真正保存動態 Broker 參數的地方。該 znode 下有兩大類子節點。第一類子節點就只有一個,它有個固定的名字叫 ,保存的是前面說過的 cluster-wide 範圍的動態參數;另一類則以 broker.id 爲名,保存的是特定 Broker 的 per-broker 範圍參數。由於是 per-broker 範圍,因此這類子節點可能存在多個。

我們一起來看一張圖片,它展示的是我的一個 Kafka 集羣環境上的動態 Broker 端參數。

在這張圖中,我首先查看了 /config/brokers 下的子節點,我們可以看到,這裏面有 節點和名爲 0、1 的子節點。< default > 節點中保存了我設置的 cluster-wide範圍參數;0 和 1 節點中分別保存了我爲 Broker 0 和 Broker1 設置的 per-broker 參數。

接下來,我分別展示了 cluster-wide 範圍和 per-broker 範圍的參數設置。拿num.io.threads 參數爲例,其 cluster-wide 值被動態調整爲 12,而在 Broker 0 上被設置成 16,在 Broker 1 上被設置成 8。我爲 Broker 0 和 Broker 1 單獨設置的值,會覆蓋掉cluster-wide 值,但在其他 Broker 上,該參數默認值還是按 12 計算。

如果我們再把靜態參數加進來一起討論的話,cluster-wide、per-broker 和 static 參數的優先級是這樣的:per-broker 參數 > cluster-wide 參數 > static 參數 > Kafka 默認值。

另外,如果你仔細查看上圖中的ephemeralOwner 字段,你會發現它們的值都是 0x0。這表示這些 znode 都是持久化節點,它們將一直存在。即使 ZooKeeper 集羣重啓,這些數據也不會丟失,這樣就能保證這些動態參數的值會一直生效。

如何配置?

講完了保存原理,我們來說說如何配置動態 Broker 參數。目前,設置動態參數的工具行命令只有一個,那就是 Kafka 自帶的 kafka-configs 腳本。接下來,我來以unclean.leader.election.enable 參數爲例,演示一下如何動態調整。

下面這條命令展示瞭如何在集羣層面設置全局值,即設置 cluster-wide 範圍值。

$ bin/kafka-configs.sh --bootstrap-server kafka-host:port --entity-type brokers --entityCompleted updating default config for brokers in the cluster,

總體來說命令很簡單,但有一點需要注意。如果要設置 cluster-wide 範圍的動態參數,需要顯式指定 entity-default。現在,我們使用下面的命令來查看一下剛纔的配置是否成功。

$ bin/kafka-configs.sh --bootstrap-server kafka-host:port --entity-type brokers --entityDefault config for brokers in the cluster are:
unclean.leader.election.enable=true sensitive=false synonyms={DYNAMIC_DEFAULT_BROKER_C

從輸出來看,我們成功地在全局層面上設置該參數值爲 true。注意 sensitive=false 的字眼,它表明我們要調整的參數不是敏感數據。如果我們調整的是類似於密碼這樣的參數時,該字段就會爲 true,表示這屬於敏感數據。

好了,調整完 cluster-wide 範圍的參數,我來演示下如何設置 per-broker 範圍參數。我們還是以 unclean.leader.election.enable 參數爲例,我現在爲 ID 爲 1 的 Broker 設置一個不同的值。命令如下:

$ bin/kafka-configs.sh --bootstrap-server kafka-host:port --entity-type brokers --entityCompleted updating config for broker: 1.

同樣,我們使用下列命令,來查看一下剛剛的設置是否生效了。

$ bin/kafka-configs.sh --bootstrap-server kafka-host:port --entity-type brokers --entityConfigs for broker 1 are:
unclean.leader.election.enable=false sensitive=false synonyms={DYNAMIC_BROKER_CONFIG:u

這條命令的輸出信息很多。我們關注兩點即可。

  1. 在 Broker 1 層面上,該參數被設置成了 false,這表明命令運行成功了。
  2. 從倒數第二行可以看出,在全局層面上,該參數值依然是 true。這表明,我們之前設置的 cluster-wide 範圍參數值依然有效。

如果我們要刪除 cluster-wide 範圍參數或 per-broker 範圍參數,也非常簡單,分別執行下面的命令就可以了。

#刪除cluster-wide範圍參數
$ bin/kafka-configs.sh --bootstrap-server kafka-host:port --entity-type brokers --entityCompleted updating default config for brokers in the cluster,
#刪除per-broker範圍參數
$ bin/kafka-configs.sh --bootstrap-server kafka-host:port --entity-type brokers --entityCompleted updating config for broker: 1.

刪除動態參數要指定 delete-config。當我們刪除完動態參數配置後,再次運行查看命令,結果如下:

#查看cluster-wide範圍參數
$ bin/kafka-configs.sh --bootstrap-server kafka-host:port  --entity-type brokers --entitDefault config for brokers in the cluster are:
#查看Broker 1上的動態參數配置
$ bin/kafka-configs.sh --bootstrap-server kafka-host:port  --entity-type brokers --entitConfigs for broker 1 are:`

此時,剛纔配置的所有動態參數都已經被成功移除了。

剛剛我只是舉了一個參數的例子,如果你想要知道動態 Broker 參數都有哪些,一種方式是在 Kafka 官網中查看 Broker 端參數列表,另一種方式是直接運行無參數的 kafka-configs腳本,該腳本的說明文檔會告訴你當前動態 Broker 參數都有哪些。我們可以先來看看下面這兩張圖。

看到有這麼多動態 Broker 參數,你可能會問:這些我都需要調整嗎?你能告訴我最常用的幾個嗎?根據我的實際使用經驗,我來跟你分享一些有較大機率被動態調整值的參數。

1.log.retention.ms

修改日誌留存時間應該算是一個比較高頻的操作,畢竟,我們不可能完美地預估所有業務的消息留存時長。雖然該參數有對應的主題級別參數可以設置,但擁有在全局層面上動態變更的能力,依然是一個很好的功能亮點。

2.num.io.threads 和 num.network.threads

這是我們在前面提到的兩組線程池。就我個人而言,我覺得這是動態 Broker 參數最實用的場景了。畢竟,在實際生產環境中,Broker 端請求處理能力經常要按需擴容。如果沒有動態 Broker 參數,我們是無法做到這一點的。

3. 與 SSL 相關的參數

主要是 4 個參數(ssl.keystore.type、ssl.keystore.location、ssl.keystore.password 和ssl.key.password)。允許動態實時調整它們之後,我們就能創建那些過期時間很短的 SSL證書。每當我們調整時,Kafka 底層會重新配置 Socket 連接通道並更新 Keystore。新的連接會使用新的 Keystore,階段性地調整這組參數,有利於增加安全性。

4.num.replica.fetchers

這也是我認爲的最實用的動態 Broker 參數之一。Follower 副本拉取速度慢,在線上Kafka 環境中一直是一個老大難的問題。針對這個問題,常見的做法是增加該參數值,確保有充足的線程可以執行 Follower 副本向 Leader 副本的拉取。現在有了動態參數,你不需要再重啓 Broker,就能立即在 Follower 端生效,因此我說這是很實用的應用場景。

總結

本文重點討論了 Kafka 1.1.0 版本引入的動態 Broker 參數。這類參數最大的好處在於,無需重啓 Broker,就可以令變更生效,因此能夠極大地降低運維成本。除此之外,還給出了動態參數的保存機制和設置方法。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章