阿裏大牛的Kafka動態配置了解下？
在開始分享之前，我們先來復習壹下設置 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。我來解釋壹下它們的含義。
我來舉個例子說明壹下 per-broker 和 cluster-wide 的區別。Broker 端參數 listeners 想必妳應該不陌生吧。它是壹個 per-broker 參數，這表示妳只能為單個 Broker 動態調整listeners，而不能直接調整壹批 Broker 的 listeners。log.retention.ms 參數是 cluster-wide 級別的，Kafka 允許為集群內所有 Broker 統壹設置壹個日誌留存時間值。當然了，妳也可以為單個 Broker 修改此值。
妳可能會問，動態 Broker 參數的使用場景都有哪些呢？實際上，因為不必重啟 Broker，動態 Broker 參數的使用場景非常廣泛，通常包括但不限於以下幾種：
在這些使用場景中，動態調整線程池大小應該算是最實用的功能了。很多時候，當 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 下有兩大類子節點。第壹類子節點就只有壹個，它有個固定的名字叫 <default >，保存的是前面說過的 cluster-wide 範圍的動態參數；另壹類則以 broker.id 為名，保存的是特定 Broker 的 per-broker 範圍參數。由於是 per-broker 範圍，因此這類子節點可能存在多個。
我們壹起來看壹張圖片，它展示的是我的壹個 Kafka 集群環境上的動態 Broker 端參數。
在這張圖中，我首先查看了 /config/brokers 下的子節點，我們可以看到，這裏面有 <default > 節點和名為 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 範圍值。
總體來說命令很簡單，但有壹點需要註意。 如果要設置 cluster-wide 範圍的動態參數，需要顯式指定 entity-default 。現在，我們使用下面的命令來查看壹下剛才的配置是否成功。
從輸出來看，我們成功地在全局層面上設置該參數值為 true。註意 sensitive=false 的字眼，它表明我們要調整的參數不是敏感數據。如果我們調整的是類似於密碼這樣的參數時，該字段就會為 true，表示這屬於敏感數據。
好了，調整完 cluster-wide 範圍的參數，我來演示下如何設置 per-broker 範圍參數。我們還是以 unclean.leader.election.enable 參數為例，我現在為 ID 為 1 的 Broker 設置壹個不同的值。命令如下：
同樣，我們使用下列命令，來查看壹下剛剛的設置是否生效了。
這條命令的輸出信息很多。我們關註兩點即可。
如果我們要刪除 cluster-wide 範圍參數或 per-broker 範圍參數，也非常簡單，分別執行下面的命令就可以了。
刪除動態參數要指定 delete-config 。當我們刪除完動態參數配置後，再次運行查看命令，結果如下：
此時，剛才配置的所有動態參數都已經被成功移除了。
剛剛我只是舉了壹個參數的例子，如果妳想要知道動態 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，就可以令變更生效，因此能夠極大地降低運維成本。除此之外，還給出了動態參數的保存機制和設置方法。