Kafka官方文件V2.7

1.開始

1.1 簡介

什麼是事件流？

事件流相當於人體的中樞神經系統的數字化。它是 "永遠線上 "世界的技術基礎，在這個世界裡，業務越來越多地被軟體定義和自動化，軟體的使用者更是軟體。

從技術上講，事件流是指以事件流的形式從資料庫、感測器、移動裝置、雲服務和軟體應用等事件源中實時捕獲資料；將這些事件流持久地儲存起來，以便日後檢索；對事件流進行實時以及回顧性的操作、處理和反應；並根據需要將事件流路由到不同的目的技術。因此，事件流確保了資料的連續流動和解釋，從而使正確的資訊在正確的時間和地點出現。

我可以使用事件流做什麼？

事件流被應用於眾多行業和組織的各種用例中。它的許多例子包括：

• 實時處理支付和金融交易，如證券交易所、銀行和保險公司。
• 實時跟蹤和監控汽車、卡車、車隊和貨物，如物流和汽車行業。
• 持續採集和分析來自物聯網裝置或其他裝置的感測器資料，例如在工廠和風場。
• 收集並立即響應客戶的互動和訂單，例如在零售、酒店和旅遊行業以及移動應用中。
• 監測醫院護理中的病人，並預測病情變化，以確保緊急情況下的及時治療。
• 連線、儲存和提供公司不同部門產生的資料。
• 作為資料平臺、事件驅動架構和微服務的基礎。

Apache Kafka®是一個事件流平臺。這意味著什麼？

Kafka結合了三個關鍵功能，因此您可以通過一個經過實戰檢驗的解決方案，端到端實現您的事件流用例。

• 釋出（寫）和訂閱（讀）事件流，包括從其他系統持續匯入/匯出資料。
• 只要你想，就能持久可靠地儲存事件流。
• 在事件發生時處理事件流，或對事件流進行追溯。

所有這些功能都是以分散式、高度可擴充套件、彈性、容錯和安全的方式提供的。Kafka可以部署在裸機硬體、虛擬機器和容器上，也可以部署在企業內部以及雲端。您可以在自我管理Kafka環境和使用由各種供應商提供的完全託管服務之間進行選擇。

 

Kafka是如何工作的？

Kafka是一個分散式系統，由伺服器和客戶端組成，通過高效能的TCP網路協議進行通訊。它可以部署在內部以及雲環境中的裸機硬體、虛擬機器和容器上。

伺服器。Kafka以一個或多個伺服器叢集的形式執行，可以跨越多個資料中心或雲區域。這些伺服器中的一些構成了儲存層，稱為broker。其他伺服器執行Kafka Connect，以事件流的形式持續匯入和匯出資料，將Kafka與您現有的系統（如關係型資料庫以及其他Kafka叢集）整合。為了讓您實現關鍵任務用例，Kafka叢集具有高度的可擴充套件性和容錯性：如果它的任何一臺伺服器發生故障，其他伺服器將接管它們的工作，以確保在沒有任何資料丟失的情況下連續執行。

客戶端。它們允許你編寫分散式應用和微服務，即使在網路問題或機器故障的情況下，也能以並行、大規模、容錯的方式讀取、寫入和處理事件流。Kafka船載包含了一些這樣的客戶端，Kafka社群提供的幾十個客戶端對其進行了增強：客戶端可用於Java和Scala，包括更高階別的Kafka Streams庫，用於Go、Python、C/C++和許多其他程式語言，以及REST API。

 

主要概念和術語

事件記錄了世界上或你的企業中 "發生了什麼 "的事實。它在文件中也被稱為記錄或訊息。當你向Kafka讀寫資料時，你是以事件的形式進行的。概念上，一個事件有一個鍵、值、時間戳和可選的後設資料頭。下面是一個事件的例子。

• 事件鍵："Alice"
• 事件價值： "支付了200美元給鮑勃"
• 事件時間戳： "2020年6月25日下午2點06分"

生產者是那些向Kafka釋出（寫）事件的客戶端應用，消費者是那些訂閱（讀取和處理）這些事件的應用。在Kafka中，生產者和消費者是完全解耦的，彼此不可知，這是實現Kafka聞名的高可擴充套件性的關鍵設計元素。例如，生產者從來不需要等待消費者。Kafka提供了各種保證，例如，能夠精確地處理事件-once。

事件被組織並持久地儲存在主題中。非常簡化，一個topic類似於檔案系統中的一個資料夾，而事件就是該資料夾中的檔案。一個例子的topic名稱可以是 "支付"。Kafka中的topic總是多生產者和多訂閱者的：一個topic可以有零個、一個或許多生產者向它寫入事件，也可以有零個、一個或許多消費者訂閱這些事件。主題中的事件可以根據需要隨時讀取--與傳統的訊息系統不同，事件在消耗後不會被刪除。相反，你可以通過每個主題的配置設定來定義Kafka應該保留你的事件多長時間，之後舊的事件將被丟棄。Kafka的效能與資料大小有效地保持不變，所以長時間儲存資料是完全可以的。

主題是分割槽的，也就是說一個主題會分佈在位於不同的Kafkabroker上的多個 "桶 "上。這種資料的分散式放置對可擴充套件性非常重要，因為它允許客戶端應用程式同時從/向許多broker讀寫資料。當一個新的事件被髮布到一個主題時，它實際上被附加到主題的一個分割槽中。具有相同事件鍵的事件（例如，客戶或車輛ID）被寫入同一分割槽，Kafka保證給定主題-分割槽的任何消費者將始終以完全相同的順序讀取該分割槽的事件，因為它們被寫入。

 

 

 

圖：本例題有四個分割槽P1-P4。這個主題有四個分割槽P1 -P4。兩個不同的生產者客戶端通過網路將事件寫入主題的分割槽，彼此獨立地釋出新事件到主題。具有相同鍵的事件（圖中用它們的顏色表示）被寫入同一個分割槽。注意，如果合適的話，兩個生產者都可以寫到同一個分割槽。

 

為了使你的資料具有容錯性和高可用性，每個主題都可以被複制，甚至可以跨地理區域或資料中心，這樣總有多個broker擁有資料的副本，以防萬一出現問題，你想對broker進行維護等等。常見的生產設定是複製係數為3，即你的資料永遠有三個副本。這種複製是在主題-分割槽的層面上進行的。

這個初級介紹應該足夠了。如果你有興趣的話，文件中的設計部分會完整詳細地解釋Kafka的各種概念。

 

Kafka APIs

除了用於管理和行政任務的命令列工具外，Kafka還有五個針對Java和Scala的核心API。

• 管理API用於管理和檢查主題、broker和其他Kafka物件。
• Producer API用於向一個或多個Kafka主題釋出（寫入）事件流。
• 消費者API用於訂閱（讀取）一個或多個主題，並處理向其產生的事件流。
• Kafka Streams API用於實現流處理應用程式和微服務。它提供了更高層次的函式來處理事件流，包括轉換、有狀態的操作（如聚合和連線）、視窗化、基於事件時間的處理等。從一個或多個主題讀取輸入，以便生成輸出到一個或多個主題，有效地將輸入流轉化為輸出流。
• Kafka Connect API來構建和執行可重用的資料匯入/匯出聯結器，這些聯結器從外部系統和應用程式消耗（讀）或產生（寫）事件流，以便它們可以與Kafka整合。例如，連線PostgreSQL等關係型資料庫的聯結器可能會捕獲一組表的每一個變化。然而，在實踐中，你通常不需要實現自己的聯結器，因為Kafka社群已經提供了數百個現成的聯結器。

下一步是什麼

• 要獲得Kafka的實際操作經驗，請關注快速入門。
• 要想更詳細地瞭解Kafka，請閱讀文件。您還可以選擇Kafka書籍和學術論文。
• 瀏覽使用案例，瞭解全球社群的其他使用者如何從Kafka中獲得價值。
• 加入當地的Kafka meetup小組，觀看Kafka社群的主要會議--Kafka Summit的演講。

 

1.2使用案例

 

以下是對Apache Kafka®的一些流行用例的描述。關於這些領域的概述，請看這篇部落格文章。

 

訊息傳遞

Kafka可以很好地替代更傳統的訊息中介。訊息broker的使用有多種原因（將處理與資料生產者解耦，緩衝未處理的訊息等）。與大多數訊息系統相比，Kafka具有更好的吞吐量、內建的分割槽、複製和容錯能力，這使得它成為大規模訊息處理應用的良好解決方案。
根據我們的經驗，訊息處理的用途往往是比較低的吞吐量，但可能需要較低的端到端延遲，並且往往依賴於Kafka提供的強大的耐久性保證。

在這個領域中，Kafka可以和傳統的訊息系統，如ActiveMQ或RabbitMQ相媲美。

網站活動跟蹤

 

Kafka最初的用例是能夠將使用者活動跟蹤管道重建為一組實時釋出-訂閱feeds。這意味著網站活動（頁面瀏覽、搜尋或使用者可能採取的其他行動）被髮布到中心主題，每個活動型別有一個主題。這些feed可供訂閱，用於一系列用例，包括實時處理、實時監控以及載入到Hadoop或離線資料倉儲系統中進行離線處理和報告。
活動跟蹤通常是非常大的量，因為每個使用者頁面瀏覽都會產生許多活動訊息。

 

衡量標準

 

Kafka經常用於運營監控資料。這涉及到從分散式應用中聚合統計資料，以產生集中的運營資料來源。

 

日誌聚合

 

許多人使用Kafka作為日誌聚合解決方案的替代品。日誌聚合通常會從伺服器上收集物理日誌檔案，並將它們放在一箇中心位置（可能是檔案伺服器或HDFS）進行處理。Kafka抽象掉了檔案的細節，並將日誌或事件資料抽象為一個更乾淨的訊息流。這使得處理延遲更低，更容易支援多個資料來源和分散式資料消費。與Scribe或Flume等以日誌為中心的系統相比，Kafka同樣具有良好的效能，由於複製而具有更強的耐久性保證，端到端延遲也低得多。

 

流處理

Kafka的許多使用者在由多個階段組成的處理管道中處理資料，原始輸入資料從Kafka主題中消耗，然後聚合、豐富或以其他方式轉化為新的主題，以便進一步消耗或後續處理。例如，用於推薦新聞文章的處理管道可能會從RSS訂閱中抓取文章內容，並將其釋出到 "文章 "主題中；進一步的處理可能會對這些內容進行歸一化或重複資料化，並將清洗後的文章內容釋出到新的主題中；最後的處理階段可能會嘗試向使用者推薦這些內容。這樣的處理流水線會根據各個主題建立實時資料流的圖。從0.10.0.0開始，Apache Kafka中提供了一個輕量級但功能強大的流處理庫Kafka Streams，用於執行上述此類資料處理。除了Kafka Streams，其他的開源流處理工具還包括Apache Storm和Apache Samza。

事件源

事件源是一種應用設計風格，其中狀態變化被記錄為一個時間順序的記錄序列。Kafka對非常大的儲存日誌資料的支援使其成為以這種風格構建的應用程式的優秀後端。

提交日誌

Kafka可以作為分散式系統的一種外部提交日誌。該日誌有助於在節點之間複製資料，並作為失敗節點的重新同步機制，以恢復其資料。Kafka中的日誌壓縮功能有助於支援這種用法。在這個用法上，Kafka類似於Apache BookKeeper專案。

 

1.3 快速開始

 

步驟一：獲取kafka

下載最新的Kafka版本並解壓。

 

$ tar -xzf kafka_2.13-2.7.0.tgz
$ cd kafka_2.13-2.7.0

步驟二：啟動kafka環境

注意：您的本地環境必須安裝有 Java 8+。

執行以下命令，以便以正確的順序啟動所有服務。

# Start the ZooKeeper service
# Note: Soon, ZooKeeper will no longer be required by Apache Kafka.
$ bin/zookeeper-server-start.sh config/zookeeper.properties

開啟另一個終端會話並執行。

# Start the Kafka broker service
$ bin/kafka-server-start.sh config/server.properties

一旦所有服務成功啟動，您將擁有一個基本的Kafka環境執行並準備使用。

 

步驟三：建立一個主題來儲存你的事件

Kafka是一個分散式事件流平臺，它可以讓你在許多機器上讀取、寫入、儲存和處理事件（在文件中也稱為記錄或訊息）。

示例事件有支付交易、手機的地理位置更新、運輸訂單、物聯網裝置或醫療裝置的感測器測量等等。這些事件被組織並儲存在主題中。非常簡化，一個主題類似於檔案系統中的一個資料夾，而事件就是該資料夾中的檔案。

所以在你寫第一個事件之前，你必須建立一個topic。開啟另一個終端會話並執行。

$ bin/kafka-topics.sh --create --topic quickstart-events --bootstrap-server localhost:9092

Kafka的所有命令列工具都有額外的選項：執行kafka-topics.sh命令，不需要任何引數就可以顯示使用資訊。例如，它還可以顯示新主題的分割槽數等細節。

 

$ bin/kafka-topics.sh --describe --topic quickstart-events --bootstrap-server localhost:9092
Topic:quickstart-events  PartitionCount:1    ReplicationFactor:1 Configs:
    Topic: quickstart-events Partition: 0    Leader: 0   Replicas: 0 Isr: 0

步驟四：將一些事件寫進主題裡

Kafka客戶端通過網路與Kafkabroker進行通訊，以寫入（或讀取）事件。一旦接收到事件，brokers將以持久和容錯的方式儲存這些事件，只要你需要--甚至永遠。

執行控制檯生產者客戶端，將一些事件寫入你的主題中。預設情況下，你輸入的每一行都會導致一個單獨的事件被寫入主題。

$ bin/kafka-console-producer.sh --topic quickstart-events --bootstrap-server localhost:9092
This is my first event
This is my second event

你可以在任何時候用Ctrl+C停止生產者客戶端。

 

步驟五：讀取事件

開啟另一個終端會話，執行控制檯消費者客戶端來讀取剛才建立的事件。

 

$ bin/kafka-console-consumer.sh --topic quickstart-events --from-beginning --bootstrap-server localhost:9092
This is my first event
This is my second event

 

你可以在任何時候用Ctrl+C停止消費者客戶端。

隨意試驗一下：例如，切換回你的生產者終端(上一步)來寫入額外的事件，看看這些事件是如何立即顯示在你的消費者終端中的。

因為事件是持久儲存在Kafka中的，所以它們可以被任意次數和任意數量的消費者讀取。你可以通過開啟另一個終端會話並再次重新執行上一條命令來輕鬆驗證。

 

步驟六：使用KAFKA CONNECT將您的資料以事件流的形式匯入/匯出

你可能在現有的系統中擁有大量的資料，比如關係型資料庫或傳統的訊息系統，以及許多已經使用這些系統的應用程式。Kafka Connect允許您將外部系統中的資料不斷地攝入到Kafka中，反之亦然。因此，將現有系統與Kafka整合起來非常容易。為了使這一過程更加簡單，有數百個這樣的聯結器隨時可用。

看看Kafka連線部分，瞭解更多關於如何將你的資料連續匯入/匯出到Kafka中。

步驟七：使用KAFKA STREAMS處理您的事件

一旦您的資料以事件的形式儲存在Kafka中，您就可以使用Java/Scala的Kafka Streams客戶端庫處理資料。它允許您實現任務關鍵型實時應用程式和微服務，其中輸入和/或輸出資料儲存在Kafka主題中。Kafka Streams將在客戶端編寫和部署標準Java和Scala應用程式的簡單性與Kafka伺服器端叢集技術的優勢相結合，使這些應用程式具有高度的可擴充套件性、彈性、容錯性和分散式。該庫支援精確的一次性處理、有狀態的操作和聚合、視窗化、連線、基於事件時間的處理等。

為了讓大家先體驗一下，下面是如何實現流行的WordCount演算法。

KStream<String, String> textLines = builder.stream("quickstart-events");

KTable<String, Long> wordCounts = textLines
            .flatMapValues(line -> Arrays.asList(line.toLowerCase().split(" ")))
            .groupBy((keyIgnored, word) -> word)
            .count();

wordCounts.toStream().to("output-topic"), Produced.with(Serdes.String(), Serdes.Long()));

Kafka Streams演示和應用開發教程演示瞭如何從頭到尾地編碼和執行這樣一個流媒體應用。

 

步驟八：終止kafka執行環境

現在你已經到達了快速入門的終點，可以隨意拆掉Kafka環境--或者繼續玩。

1. 用Ctrl-C停止生產者和消費者客戶端，如果你還沒有這樣做。
2. 用Ctrl-C停止Kafka broker。
3. 最後，用Ctrl-C停止ZooKeeper伺服器。

如果你還想刪除你本地Kafka環境的任何資料，包括你一路建立的任何事件，執行下列命令：

$ rm -rf /tmp/kafka-logs /tmp/zookeeper

 

祝賀！

您已經成功完成了Apache Kafka快速入門。

要了解更多資訊，我們建議採取以下步驟。

• 閱讀簡短的介紹，瞭解Kafka如何在高層次上工作，它的主要概念，以及它與其他技術的比較。要了解Kafka的更多細節，請前往文件。
• 瀏覽使用案例，瞭解全球社群的其他使用者如何從Kafka中獲得價值。
• 加入當地的Kafka meetup小組，觀看Kafka社群的主要會議--Kafka Summit的演講。

 

 

1.4 生態系統

在主發行版之外，有大量的工具與Kafka整合。生態系統頁面列出了其中的許多工具，包括流處理系統、Hadoop整合、監控和部署工具。

 

1.5 從舊版本升級

從0.8.x到2.6.x的任何版本升級到2.7.0

如果您要從 2.1.x 之前的版本升級，請檢視下面關於用於儲存消費者偏移量的模式變化的說明。一旦您將 inter.broker.protocol.version 更改為最新版本，將無法降級到 2.1 之前的版本。

如何平滑升級：

1. 更新所有broker的server.properties，並新增以下屬性。CURRENT_KAFKA_VERSION 指的是您要升級的版本。CURRENT_MESSAGE_FORMAT_VERSION 指的是當前使用的訊息格式版本。如果您之前已經覆蓋了訊息格式版本，您應該保留它的當前值。另外，如果您從 0.11.0.x 之前的版本升級，那麼 CURRENT_MESSAGE_FORMAT_VERSION 應該設定為與 CURRENT_KAFKA_VERSION 匹配。
   • inter.broker.protocol.version=CURRENT_KAFKA_VERSION (例如，2.6、2.5等)
   • log.message.format.version=CURRENT_MESSAGE_FORMAT_VERSION (關於這個配置的詳細作用，請看升級後對效能的潛在影響。)
     
     如果你是從0.11.0.x或更高版本升級的，並且你沒有覆蓋訊息格式，那麼你只需要覆蓋inter-broker協議版本。
   • inter.broker.protocol.version=CURRENT_KAFKA_VERSION（如2.6、2.5等）。
2. 一次升級一個broker：關閉broker，更新程式碼，然後重新啟動它。一旦你這樣做了，broker將執行最新的版本，你可以驗證叢集的行為和效能是否符合預期。如果有任何問題，此時仍然可以降級。
3. 一旦叢集的行為和效能得到驗證，通過編輯inter.broker.protocol.version並將其設定為2.7來提升協議版本。
4. 逐個重啟broker，讓新協議版本生效。一旦brokers開始使用最新的協議版本，將不再可能將群集降級到舊版本。
5. 如果你已經按照上面的指示覆蓋了訊息格式版本，那麼你需要再做一次滾動重啟，將其升級到最新版本。一旦所有（或大多數）消費者都升級到0.11.0或更高版本，在每個broker上將log.message.format.version改為2.7，然後逐個重啟它們。需要注意的是，不再維護的舊版Scala客戶端不支援0.11中引入的訊息格式，因此為了避免轉換成本（或利用精確的一次語義），必須使用較新的Java客戶端。

 

2.7.0中的顯著變化

• 2.7.0版本包括KIP-595中規定的核心Raft實現。有一個單獨的 "Raft "模組，包含大部分的邏輯。在與控制器的整合完成之前，有一個獨立的伺服器，使用者可以用來測試Raft實現的效能。詳細內容請參見 raft 模組中的 README.md。
• KIP-651 增加了對使用 PEM 檔案作為金鑰和信任儲存的支援。
• KIP-612 增加了對執行整個代理和每個監聽器連線建立率的支援。2.7.0 版本包含 KIP-612 的第一部分，動態配置將在 2.8.0 版本中推出。
• 通過KIP-599，能夠節制主題和分割槽的建立或主題的刪除，以防止叢集受到傷害。
• 當Kafka中出現新功能時，主要有兩個問題。
• Kafka客戶如何知道broker的功能？
• broker如何決定啟用哪些功能？
• KIP-584提供了一個靈活且易於操作的解決方案，用於客戶端發現、功能門控和使用一次重啟進行滾動升級。
• 通過KIP-431，現在可以通過ConsoleConsumer列印記錄偏移量和標頭檔案的能力。
• KIP-554的加入，繼續朝著從Kafka中移除Zookeeper的目標前進。KIP-554的加入意味著你不必再直接連線到ZooKeeper來管理SCRAM憑證。
• 改變存在的監聽器的不可重新配置的配置會導致InvalidRequestException。相比之下，之前（非預期）的行為會導致更新的配置被持久化，但直到broker被重新啟動才會生效。更多討論請參見KAFKA-10479。請參閱DynamicBrokerConfig.DynamicSecurityConfigs和SocketServer.ListenerReconfigurableConfigs，瞭解存在的監聽器的支援的可重新配置。
• Kafka Streams在KStreams DSL中增加了對Sliding Windows Aggregations的支援。
• 在狀態儲存上進行反向迭代，使KIP-617的最近更新搜尋更加高效。
• Kafka Steams中的端到端延遲指標，詳見KIP-613。
• Kafka Streams增加了用KIP-607報告預設RocksDB屬性的指標。
• KIP-616提供更好的Scala隱式Serdes支援。

2. APIS

Kafka包括五個核心API。

1. 生產者API允許應用程式向Kafka叢集中的主題傳送資料流。
2. Consumer API允許應用程式從Kafka叢集中的主題讀取資料流。
3. Streams API允許將資料流從輸入主題轉換為輸出主題。
4. 連線API允許實現聯結器，不斷地從一些源系統或應用拉入Kafka，或從Kafka推入一些匯系統或應用。
5. 管理API允許管理和檢查主題、broker和其他Kafka物件。

Kafka通過一個獨立於語言的協議公開其所有功能，該協議有許多程式語言的客戶端。然而，只有Java客戶端是作為Kafka主專案的一部分來維護的，其他的客戶端是作為獨立的開源專案來提供的。非Java客戶端的列表可以在這裡找到。

 

2.1 生產者API

Producer API允許應用程式向Kafka叢集中的主題傳送資料流。
javadocs中給出瞭如何使用producer的例子。

要使用producer，你可以使用以下maven依賴。

　　　　　　　　　　<dependency>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka-clients</artifactId>
			<version>2.7.0</version>
		</dependency>

2.2 消費者API

消費者API允許應用程式從Kafka叢集中的主題讀取資料流。
javadocs中給出瞭如何使用消費者的例子。

要使用消費者，你可以使用以下maven依賴。

		<dependency>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka-clients</artifactId>
			<version>2.7.0</version>
		</dependency>

2.3 流API

Streams API允許將資料流從輸入主題轉換為輸出主題。
在javadocs中給出瞭如何使用這個庫的例子。

關於使用Streams API的其他文件在這裡。

要使用Kafka Streams，你可以使用以下maven依賴。

 

		<dependency>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka-streams</artifactId>
			<version>2.7.0</version>
		</dependency>

 

當使用Scala時，你可以選擇包含kafka-streams-scala庫。關於使用Kafka Streams DSL for Scala的其他文件請參見開發者指南。

要使用Kafka Streams DSL for Scala for Scala 2.13，你可以使用以下maven依賴。

 

		<dependency>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka-streams-scala_2.13</artifactId>
			<version>2.7.0</version>
		</dependency>

 

2.4 連線API

Connect API允許實現聯結器，不斷地從一些源資料系統拉入Kafka，或者從Kafka推送到一些匯資料系統。
很多Connect的使用者不需要直接使用這個API，不過，他們可以使用預建的聯結器，而不需要編寫任何程式碼。關於使用Connect的其他資訊可以在這裡獲得。

想要實現自定義聯結器的使用者可以檢視javadoc。

 

2.5 管理API

管理API支援管理和檢查主題、broker、acls和其他Kafka物件。
要使用Admin API，請新增以下Maven依賴關係。

 

		<dependency>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka-clients</artifactId>
			<version>2.7.0</version>
		</dependency>

有關Admin APIs的更多資訊，請參閱javadoc。

3. 配置

Kafka使用屬性檔案格式的鍵值對進行配置。這些值可以從檔案或程式上提供。

3.1 broker配置

基本配置如下。

• broker.id
• log.dirs
• zookeeper.connect

下面將詳細討論主題級配置和預設值。

 

 

zookeeper.connect
以 hostname:port 的形式指定 ZooKeeper 連線字串，其中 host 和 port 是 ZooKeeper 伺服器的主機和埠。為了允許在該ZooKeeper機器當機時通過其他ZooKeeper節點進行連線，你也可以以hostname1:port1,hostname2:port2,hostname3:port3的形式指定多個主機。
伺服器也可以有一個ZooKeeper chroot路徑作為其ZooKeeper連線字串的一部分，它將其資料放在全域性ZooKeeper名稱空間的某個路徑下。例如，給chroot路徑為/chroot/path，你可以給連線字串為hostname1:port1,hostname2:port2,hostname3:port3/chroot/path。

型別：字串
預設值：
有效值：
重要性：高
更新模式：只讀

 

advertised.host.name
已經廢棄：只有在沒有設定advertised.listeners或listeners時才使用。請使用advertised.listeners代替。
釋出到ZooKeeper的主機名，供客戶端使用。在IaaS環境中，這可能需要與broker繫結的介面不同。如果沒有設定，它將使用host.name的值，如果配置。否則，它將使用從 java.net.InetAddress.getCanonicalHostName()返回的值。

型別：字串
預設值: null
有效值：
重要性：高
更新模式：只讀

 

advertised.listeners
監聽器釋出到ZooKeeper供客戶端使用，如果與監聽器配置屬性不同。在IaaS環境中，這可能需要與broker繫結的介面不同。如果沒有設定這個，將使用監聽器的值。與監聽器不同，宣傳0.0.0.0元地址是無效的。
同樣與監聽器不同的是，在這個屬性中可以有重複的埠，這樣一個監聽器可以被配置為宣傳另一個監聽器的地址。這在某些使用外部負載均衡器的情況下很有用。

型別：字串
預設值: null
有效值:
重要性：高
更新模式：每個broker

 

advertised.port
已經廢棄：只有在沒有設定advertised.listeners或listeners時才使用。請使用advertised.listeners代替。
釋出到ZooKeeper供客戶端使用的埠。在IaaS環境中，這可能需要與broker繫結的埠不同。如果沒有設定，它將釋出與broker繫結的相同埠。

型別：int
預設值: null
有效值：
重要性：高
更新模式：只讀

 

auto.create.topics.enable
啟用自動建立伺服器上的主題

型別: 布林型
預設：true
有效值：
重要性：高
更新模式：只讀

 

auto.leader.rebalance.enable

啟用自動領導平衡。後臺執行緒定期檢查分割槽領導的分佈情況，可由`leader.imbalance.check.interval.seconds`配置。如果leader.imbalance.per.broker.百分比超過`leader.imbalance.per.broker.百分比`，則會觸發對分割槽的首選leader重新平衡。

 

型別：布林值

預設：true

有效值：

重要性：高

更新模式：只讀

 

background.threads

用於各種後臺處理任務的執行緒數。

 

型別：int

預設值：10

有效值：[1，...]

重要性：高

更新模式：全叢集

 

broker.id

這個伺服器的broker id，如果沒有設定，將生成一個唯一的broker id。為了避免zookeeper生成的broker id和使用者配置的broker id之間的衝突，生成的broker id從 reserved.broker.max.id + 1 開始。

 

型別：int

預設值：-1

有效值：

重要性：高

更新模式：只讀

 

compression.type

指定給定主題的最終壓縮型別。此配置接受標準的壓縮編解碼器（'gzip'、'snappy'、'lz4'、'zstd'）。此外，它還接受'uncompressed'，這相當於沒有壓縮；以及'producer'，這意味著保留製作者設定的原始壓縮編解碼器。

 

型別：字串

預設：生產者

有效值：

重要性：高

更新模式：全叢集

 

control.plane.listener.name

用於控制器和broker之間通訊的監聽器的名稱。broker將使用control.plane.listener.name來定位監聽器列表中的端點，以監聽來自控制器的連線。例如，如果一個broker的配置是.plane.listener.name。

listeners = INTERNAL://192.1.1.8:9092, EXTERNAL://10.1.1.5:9093, CONTROLLER://192.1.1.8:9094。

listener.security.protocol.map = INTERNAL:PLAINTEXT, EXTERNAL:SSL, CONTROLLER:SSL。

control.plane.listener.name = CONTROLLER

在啟動時，broker將開始監聽 "192.1.1.8:9094"，安全協議為 "SSL"。

在控制器端，當它通過zookeeper發現一個broker釋出的端點時，它會使用control.plane.listener.name來找到端點，然後用它來建立與broker的連線。

例如，如果broker在zookeeper上釋出的端點是...。

"endpoints" : ["INTERNAL://broker1.example.com:9092", "EXTERNAL://broker1.example.com:9093", "CONTROLLER://broker1.example.com:9094"] 。

而控制器的配置是 。

listener.security.protocol.map = INTERNAL:PLAINTEXT, EXTERNAL:SSL, CONTROLLER:SSL。

control.plane.listener.name = CONTROLLER

那麼控制器將使用 "broker1.example.com:9094 "和安全協議 "SSL "來連線到代理。

如果沒有明確配置，預設值為空，控制器連線將沒有專用端點。

 

型別：字串

預設值: null

有效值：

重要性：高

更新模式：只讀

 

delete.topic.enable

啟用刪除主題。如果關閉此配置，通過管理工具刪除主題將沒有效果。

 

型別: 布林型

預設：true

有效值：

重要性：高

更新模式：只讀

 

host.name

已經過期：只有在沒有設定監聽器時才使用。使用 listeners 代替。

broker的主機名。如果設定了這個，它將只繫結到這個地址。如果沒有設定，則會繫結到所有介面。

 

型別：字串

預設：""

有效值：

重要性：高

更新模式：只讀

 

leader.imbalance.check.interval.seconds

控制器觸發分割槽再平衡檢查的頻率。

 

型別：長

預設值：300

有效值：

重要性：高

更新模式：只讀

 

leader.imbalance.per.broker.percentage

每個broker允許的領導者不平衡的比率。如果每個broker超過這個值，控制器將觸發一個領導者平衡。該值以百分比指定。

 

型別：int

預設值：10

有效值：

重要性：高

更新模式：只讀

 

listeners

Listener List - 我們將監聽的URI和監聽者名稱的逗號分隔的列表，如果監聽者名稱不是安全協議，還必須設定listener.security.protocol.map。如果監聽器名稱不是安全協議，還必須設定listener.security.protocol.map。

監聽器名稱和埠號必須是唯一的。

將hostname指定為0.0.0.0，繫結到所有介面。

將hostname留空以繫結到預設介面。

合法監聽器列表的例子。

PLAINTEXT://myhost:9092,SSL://:9091

CLIENT://0.0.0.0:9092,REPLICATION://localhost:9093。

 

型別：字串

預設值: null

有效值：

重要性：高

更新模式：每個broker

log.dir

儲存日誌資料的目錄（log.dirs屬性的補充）。

 

型別：字串

預設值：/tmp/kafka-logs。

有效值：

重要性：高

更新模式：只讀

 

log.dirs

儲存日誌資料的目錄。如果沒有設定，則使用log.dir中的值。

 

型別：字串

預設值: null

有效值：

重要性：高

更新模式：只讀

 

log.flush.interval.messages

在將訊息重新整理到磁碟之前，日誌分割槽上累積的訊息數量。

 

型別：長

預設：9223372036854775807。

有效值：[1，...]

重要性：高

更新模式：全叢集

 

log.flush.interval.ms

任何主題中的訊息在重新整理到磁碟之前在記憶體中儲存的最大時間，單位為ms。如果沒有設定，則使用log.flush.schedule.interval.ms中的值。

 

型別：長

預設值: null

有效值：

重要性：高

更新模式：全叢集

 

log.flush.offset.checkpoint.interval.ms

我們更新作為日誌恢復點的最後一次重新整理的永續性記錄的頻率。

 

型別：int

預設：60000（1分鐘）

有效值：[0，...]

重要性：高

更新模式：只讀

 

log.flush.scheduler.interval.ms

日誌重新整理器檢查是否需要將日誌重新整理到磁碟上的頻率，單位為ms。

 

型別：長

預設：9223372036854775807。

有效值：

重要性：高

更新模式：只讀

 

log.flush.start.offset.checkpoint.interval.ms

更新日誌起始偏移量的永續性記錄的頻率。

 

型別：int

預設：60000（1分鐘

有效值：[0，...]

重要性：高

更新模式：只讀

 

log.retention.bytes

刪除前日誌的最大尺寸

 

型別：長

預設值：-1

有效值：

重要性：高

更新模式：全叢集

 

log.retention.hours

在刪除日誌檔案之前保留日誌檔案的小時數（小時），三級為log.retaining.ms屬性。

 

型別：int

預設值：168

有效值：

重要性：高

更新模式：只讀

 

log.retention.minutes

刪除日誌檔案前保留日誌檔案的分鐘數（以分鐘為單位），次於log.retain.ms屬性。如果沒有設定，則使用 log.retaining.hours 屬性中的值。

 

型別：int

預設值: null

有效值：

重要性：高

更新模式：只讀

 

log.retention.ms

刪除日誌檔案前保留日誌檔案的毫秒數（單位：毫秒），如果沒有設定，則使用log.retention.minutes中的值。如果設定為-1，則沒有時間限制。

 

型別：長

預設值: null

有效值：

重要性：高

更新模式：全叢集

 

log.roll.hours

新日誌段推出前的最長時間（小時），次要為log.roll.ms屬性。

 

型別：int

預設值：168

有效值：[1，...]

重要性：高

更新模式：只讀

 

log.roll.jitter.hours

從logRollTimeMillis（小時）中減去的最大抖動，次要用於log.roll.jitter.ms屬性。

 

型別：int

預設值：0

有效值：[0,...]

重要性：高

更新模式：只讀

 

log.roll.jitter.ms

從logRollTimeMillis（毫秒）中減去的最大抖動。如果沒有設定，則使用log.roll.jitter.hours中的值。

 

型別：長

預設值: null

有效值：

重要性：高

更新模式：全叢集

 

log.roll.ms

新日誌段推出前的最長時間（毫秒）。如果沒有設定，則使用log.roll.hours中的值。

 

型別：長

預設值: null

有效值：

重要性：高

更新模式：全叢集

 

log.segment.bytes

單個日誌檔案的最大大小

 

型別：int

預設值：1073741824 (1 gibibyte)

有效值： [14，...]

重要性：高

更新模式：全叢集

 

log.segment.delete.delay.ms

從檔案系統中刪除檔案前等待的時間。

 

型別：長

預設：60000（1分鐘

有效值：[0，...]

重要性：高

更新模式：全叢集

 

message.max.bytes

Kafka允許的最大記錄批次大小（如果啟用壓縮，則壓縮後）。如果增加這個大小，並且有比0.10.2更老的消費者，消費者的取數大小也必須增加，這樣才能取到這麼大的記錄批。在最新的訊息格式版本中，為了提高效率，記錄總是被分組成批。在以前的訊息格式版本中，未壓縮的記錄不會被分組成批，在這種情況下，這個限制只適用於單條記錄。這可以通過主題級別的max.message.bytes config來設定每個主題。

 

型別：int

預設值：1048588

有效值：[0，...]

重要性：高

更新模式：全叢集

 

min.insync.replicas

當生產者將acks設定為 "all"(或"-1")時，min.insync.replicas指定了必須確認寫入才算成功的最小複製數。如果不能滿足這個最小數量，那麼生產者將引發一個異常（NotEnoughReplicas或NotEnoughReplicasAfterAppend）。

當一起使用時，min.insync.replicas和acks允許你實施更大的耐久性保證。一個典型的場景是建立一個複製因子為3的主題，將min.insync.replicas設定為2，並以 "all "的acks進行生產。這將確保生產者在大多數副本沒有收到寫入時引發異常。

 

型別：int

預設值：1

有效值：[1,...]

重要性：高

更新模式：全叢集

 

num.io.threads

伺服器用於處理請求的執行緒數，其中可能包括磁碟I/O。

 

型別：int

預設值：8

有效值：[1,...]

重要性：高

更新模式：全叢集

 

num.network.threads

伺服器用於接收來自網路的請求並向網路傳送響應的執行緒數。

 

型別：int

預設值：3

有效值：[1,...]

重要性：高

更新模式：全叢集

 

num.recovery.threads.per.dir。

每個資料目錄的執行緒數，用於啟動時的日誌恢復和關閉時的重新整理。

 

型別：int

預設值：1

有效值：[1,...]

重要性：高

更新模式：全叢集

 

num.replica.alter.log.dirs.threads。

可以在日誌目錄之間移動複製的執行緒數量，其中可能包括磁碟I/O。

 

型別：int

預設值: null

有效值：

重要性：高

更新模式：只讀

 

num.replica.fetchers

用於從源broker複製訊息的fetcher執行緒數量。增加這個值可以增加follower broker的I/O並行度。

 

型別：int

預設值：1

有效值：

重要性：高

更新模式：全叢集

 

offset.metadata.max.bytes.

與偏移提交相關聯的後設資料條目的最大尺寸。

 

型別：int

預設值：4096(4 kibibytes)

有效值：

重要性：高

更新模式：只讀

 

offsets.commit.required.acks

接受提交前所需的acks。一般來說，預設值(-1)不應該被覆蓋。

 

型別：短

預設值：-1

有效值：

重要性：高

更新模式：只讀

 

offsets.commit.timeout.ms

偏移提交將被延遲，直到主題的所有副本收到提交或達到這個超時。

偏移提交將被延遲，直到偏移主題的所有副本收到提交或達到這個超時。這與生產者請求超時類似。

 

型別：int

預設：5000（5秒

有效值：[1，...]

重要性：高

更新模式：只讀

 

offsets.load.buffer.size

當把偏移量載入到快取中時，從偏移量段讀取的批次大小（軟限制，如果記錄太大，則重寫）。

 

型別：int

預設：5242880

有效值：[1，...]

重要性：高

更新模式：只讀

 

offsets.retention.check.interval.ms

檢查過期偏移量的頻率

 

型別：長

預設：600000（10分鐘）。

有效值：[1，...]

重要性：高

 

更新模式：只讀

 

offsets.retention.minutes

當一個消費者組失去所有消費者（即變成空的）後，它的偏移量將在這個保留期內保留，然後被丟棄。對於獨立的消費者（使用手動分配），偏移量將在最後一次提交時間加上這個保留期後過期。

 

型別：int

預設值：10080

有效值：[1，...]

重要性：高

 

更新模式：只讀

 

offsets.topic.compression.codec

偏移主題的壓縮編解碼器--壓縮可用於實現 "原子 "提交。

 

型別：int

預設值：0

有效值：

重要性：高

 

更新模式：只讀

 

offsets.topic.num.partitions

偏移提交主題的分割槽數（部署後不應改變）。

 

型別：int

預設值：50

有效值：[1，...]

重要性：高

 

更新模式：只讀

 

offsets.topic.replication.factor

偏移主題的複製因子（設定更高以確保可用性）。內部主題建立將失敗，直到叢集大小滿足此複製因子要求。

 

型別：短

預設值：3

有效值：[1,...]

重要性：高

 

更新模式：只讀

 

offsets.topic.segment.bytes

偏移主題段的位元組數應保持相對較小，以利於加快日誌壓縮和快取載入速度

 

型別：int

預設值：104857600（100 mebibytes）。

有效值：[1，...]

重要性：高

 

更新模式：只讀

 

port

刪除：只有在沒有設定監聽器時才使用。請使用監聽器代替。

監聽和接受連線的埠。

 

型別：int

預設值：9092

有效值：

重要性：高

 

更新模式：只讀

 

queued.max.requests

在阻塞網路執行緒之前，允許資料層排隊請求的數量。

 

型別：int

預設值：500

有效值：[1，...]

重要性：高

更新模式：只讀

 

quota.consumer.default

已取消。僅在Zookeeper沒有配置動態預設配額時使用。任何以clientId/consumer group區分的消費者，如果每秒獲取的位元組數超過這個值，就會被節流。

 

型別：長

預設：9223372036854775807。

有效值：[1，...]

重要性：高

更新模式：只讀

 

quota.producer.default

已取消。僅在沒有配置動態預設配額時使用，或者在Zookeeper中使用。任何以clientId區分的生產者如果每秒產生的位元組數超過這個值，就會被節流。

 

型別：長

預設：9223372036854775807。

有效值：[1，...]

重要性：高

更新模式：只讀

 

replica.fetch.min.bytes

每個獲取響應的最小位元組數。如果位元組數不夠，則等待時間最多為 replica.fetch.wait.max.ms (broker 配置)。

 

型別：int

預設值：1

有效值：

重要性：高

更新模式：只讀

 

replica.fetch.wait.max.ms

追隨者副本發出的每個取數請求的最大等待時間。該值在任何時候都應始終小於 replica.lag.time.max.ms，以防止低吞吐量主題的 ISR 頻繁縮減。

 

型別：int

預設值：500

有效值：

重要性：高

更新模式：只讀

 

replica.high.watermark.checkpoint.interval.ms

高水印儲存到磁碟的頻率。

 

型別：長

預設：5000（5秒）

有效值：

重要性：高

更新模式：只讀

 

replica.lag.time.max.ms

如果一個跟隨者至少在這段時間內沒有傳送任何fetch請求，或者沒有消耗到領導者的日誌結束偏移量，領導者將把這個跟隨者從isr

 

型別：長

預設：30000（30秒）

有效值：

重要性：高

更新模式：只讀

 

replica.socket.receive.buffer.bytes

網路請求的套接字接收緩衝區

 

型別：int

預設值：65536（64 kibibytes）。

有效值：

重要性：高

更新模式：只讀

 

replica.socket.timeout.ms

網路請求的套接字超時時間，其值應至少為 replica.fetch.wait.max.ms。它的值至少應該是 replica.fetch.wait.max.ms。

 

型別：int

預設：30000（30秒）

有效值：

重要性：高

更新模式：只讀

 

request.timeout.ms

該配置控制客戶端等待請求響應的最長時間。如果在超時之前沒有收到響應，客戶端將在必要時重新傳送請求，或者在重試次數耗盡時失敗。

 

型別：int

預設：30000（30秒）

有效值：

重要性：高

更新模式：只讀

 

socket.receive.buffer.bytes 

socket伺服器套接字的SO_RCVBUF緩衝區。如果值為-1，則使用OS預設值。

 

型別：int

預設值：102400 (100 kibibytes)

有效值：

重要性：高

更新模式：只讀

 

socket.request.max.bytes

套接字請求的最大位元組數。

 

型別：int

預設值：104857600（100 mebibytes）。

有效值：[1，...]

重要性：高

更新模式：只讀

 

socket.send.buffer.bytes

socket伺服器套接字的SO_SNDBUF緩衝區。如果值為-1，則使用OS預設值。

 

型別：int

預設值：102400 (100 kibibytes)

有效值：

重要性：高

更新模式：只讀

 

transaction.max.timeout.ms

交易的最大允許超時時間。如果客戶端請求的交易時間超過了這個時間，那麼broker將在InitProducerIdRequest中返回一個錯誤。這可以防止客戶端的超時時間過大，從而拖延消費者從交易中包含的主題中讀取。

 

型別：int

預設：900000（15分鐘）

有效值：[1，...]

重要性：高

更新模式：只讀

 

transaction.state.log.load.buffer.size

當把生產者id和交易載入到快取中時，從交易日誌段讀取的批次大小（軟限制，如果記錄太大，則重寫）。

 

型別：int

預設：5242880

有效值：[1，...]

重要性：高

更新模式：只讀

 

transaction.state.log.min.isr

重寫事務主題的min.insync.replicas配置。

 

型別：int

預設值：2

有效值：[1,...]

重要性：高

更新模式：只讀

 

transaction.state.log.num.partitions

事務主題的分割槽數（部署後不應改變）。

 

型別：int

預設值：50

有效值：[1，...]

重要性：高

更新模式：只讀

 

transaction.state.log.replication.factor

事務主題的複製因子（設定較高以確保可用性）。內部主題建立將失敗，直到叢集大小滿足此複製因子要求。

 

型別：短

預設值：3

有效值：[1,...]

重要性：高

更新模式：只讀

 

transaction.state.log.segment.bytes

事務主題段的位元組數應保持相對較小，以利於加快日誌壓縮和快取載入速度

 

型別：int

預設值：104857600（100 mebibytes）。

有效值：[1，...]

重要性：高

更新模式：只讀

 

transactional.id.expiration.ms

事務協調器在沒有收到當前事務的任何事務狀態更新的情況下，在其事務id過期前等待的時間，單位為ms。這個設定也會影響生產者id過期--一旦這個時間在給定的生產者id最後一次寫入後過去，生產者id就會過期。請注意，如果由於主題的保留設定，生產者id的最後一次寫入被刪除，那麼生產者id可能會過期更早。

 

型別：int

預設：604800000（7天）

有效值：[1，...]

重要性：高

更新模式：只讀

 

zookeeper.connection.timeout.ms

客戶端等待與zookeeper建立連線的最大時間。如果沒有設定，將使用zookeeper.session.timeout.ms中的值。

 

型別：int

預設值: null

有效值：

重要性：高

更新模式：只讀

 

zookeeper.max.in.flight.requests

在阻止之前，客戶端向Zookeeper傳送的最大未確認請求數。

 

型別：int

預設值：10

有效值：[1，...]

重要性：高

更新模式：只讀

 

zookeeper.session.timeout.ms

Zookeeper會話超時

 

型別：int

預設：18000（18秒）

有效值：

重要性：高

更新模式：只讀

 

zookeeper.set.acl

設定客戶端使用安全ACL

 

型別: 布林型

預設：假

有效值：

重要性：高

更新模式：只讀

 

broker.id.generation.enable

啟用自動生成伺服器上的broker id。當啟用時，預留.broker.max.id的配置值應該被審查。

 

型別：布林值

預設：true

有效值：

重要性：中等

更新模式：只讀

 

broker.rack

broker的機架。這將用於機架感知複製分配，以實現容錯。例子："RACK1"、"us-east-1d"。`RACK1`，`us-east-1d`。

 

型別：字串

預設值: null

有效值：

重要性：中等

更新模式：只讀

 

connections.max.idle.ms

閒置連線超時：伺服器套接字處理器執行緒關閉閒置時間超過這個時間的連線。

 

型別：長

預設：600000（10分鐘）

有效值：

重要性：中等

更新模式：只讀

 

connections.max.reauth.ms

當明確設定為正數時（預設為0，不是正數），當v2.2.0或更高版本的客戶端進行身份驗證時，將向他們傳達一個不超過配置值的會話壽命。broker將斷開任何沒有在會話壽命內重新認證的連線，然後將其用於重新認證以外的任何目的。配置名稱可以選擇用監聽器字首和SASL機制名稱的小寫字母作為字首。例如，listener.name.sasl_ssl.oauthbearer.connection.max.reauth.ms=3600000。

 

型別：長

預設值：0

有效值：

重要性：中等

更新模式：只讀

 

controlled.shutdown.enable

啟用受控關閉伺服器

 

型別: 布林型

預設：true

有效值：

重要性：中等

更新模式：只讀

 

controlled.shutdown.max.retries

受控關機可能因多種原因而失敗。這就決定了發生這種故障時的重試次數。

 

型別：int

預設值：3

有效值：

重要性：中等

更新模式：只讀

 

controlled.shutdown.retry.backoff.ms

在每次重試之前，系統需要時間從導致上一次故障的狀態中恢復過來（控制器失效，複製滯後等）。這個配置決定了重試前的等待時間。

 

型別：長

預設：5000（5秒）

有效值：

重要性：中等

更新模式：只讀

 

controller.socket.timeout.ms

控制器到中間商通道的套接字超時時間。

 

型別：int

預設：30000（30秒）

有效值：

重要性：中等

更新模式：只讀

 

default.replication.factor
自動建立主題的預設複製因子

型別：int
預設值：1
有效值：
重要性：中等
更新模式：只讀

 

delegation.token.expiry.time.ms
需要更新令牌前的有效時間，以毫秒為單位。預設值為1天。

型別：長
預設：86400000（1天）
有效值：[1，...]
重要性：中等
更新模式：只讀

 

delegation.token.master.key
用於生成和驗證授權令牌的主/祕鑰。必須在所有的broker中配置相同的金鑰。如果沒有設定金鑰或將金鑰設定為空字串，則broker將禁用授權令牌支援。

型別：密碼
預設值: null
有效值：
重要性：中等
更新模式：只讀

 

delegation.token.max.lifetime.ms
令牌有最大的使用期限，超過期限就不能再更新。預設值為7天。

型別：長
預設：604800000（7天）
有效值：[1，...]
重要性：中等
更新模式：只讀

 

delete.records.purgatory.purge.interval.requests
刪除記錄請求清理區的清理間隔(以請求次數為單位)

型別：int
預設值：1
有效值：
重要性：中等
更新模式：只讀

 

fetch.max.bytes
我們將為一個獲取請求返回的最大位元組數。必須至少為1024。

型別：int
預設值：57671680 (55 mebibytes)
有效值： [1024，...]
重要性：中等
更新模式：只讀

 

fetch.purgatory.purge.interval.requests
獲取請求淨化器的清理間隔（以請求數為單位）。

型別：int
預設：1000
有效值：
重要性：中等
更新模式：只讀

 

group.initial.rebalance.delay.ms
在執行第一次重新平衡之前，組協調員將等待更多消費者加入新組的時間。較長的延遲意味著可能會減少再平衡，但會增加處理開始前的時間。

型別：int
預設：3000（3秒）
有效值：
重要性：中等
更新模式：只讀

 

group.max.session.timeout.ms
註冊消費者的最大允許會話超時。較長的超時讓消費者有更多的時間來處理心跳之間的訊息，但代價是需要更長的時間來檢測故障。

型別：int
預設：1800000（30分鐘）
有效值：
重要性：中等
更新模式：只讀

 

group.max.size
單個消費者群體可容納的最大消費者數量。

型別：int
預設：2147483647
有效值：[1，...]
重要性：中等
更新模式：只讀

 

group.min.session.timeout.ms
註冊消費者的最小允許會話超時。較短的超時會導致更快的故障檢測，但代價是更頻繁的消費者心跳，這會使broker資源不堪重負。

型別：int
預設：6000（6秒）
有效值：
重要性：中等
更新模式：只讀

 

inter.broker.listener.name
用於broker之間通訊的監聽器的名稱。如果未設定，則監聽器名稱由 security.inter.broker.protocol 定義。同時設定此屬性和 security.inter.broker.protocol 屬性是錯誤的。

型別：字串
預設值: null
有效值：
重要性：中等
更新模式：只讀

 

inter.broker.protocol.version
指定將使用哪個版本的broker間協議。
這通常是在所有broker升級到新版本後進行的。
一些有效值的例子是 0.8.0, 0.8.1, 0.8.1.1, 0.8.2, 0.8.2.0, 0.8.2.1, 0.9.0.0, 0.9.0.1 檢視ApiVersion的完整列表。

型別：字串
預設：2.7-IV2
有效值。 [0.8.0、0.8.1、0.8.2、0.9.0、0.10.0-IV0、0.10.0-IV1、0.10.1-IV0、0.10.1-IV1、0.10.1-IV2、0.10.2-IV0、0.11.0-IV0、0.11.0-IV1、0.11.0-IV2、1.0-IV0、1. 1-IV0、2.0-IV0、2.0-IV1、2.1-IV0、2.1-IV1、2.1-IV2、2.2-IV0、2.2-IV1、2.3-IV0、2.3-IV1、2.4-IV0、2.4-IV1、2.5-IV0、2.6-IV0、2.7-IV0、2.7-IV1、2.7-IV2]
重要性：中等
更新模式：只讀

 

log.cleaner.backoff.ms
當沒有日誌需要清理時的睡眠時間。

型別：長
預設：15000（15秒
有效值：[0，...]
重要性：中等
更新模式：全叢集

 

log.cleaner.dedupe.buffer.size
所有清理執行緒中用於日誌重複資料刪除的總記憶體。

型別：長
預設：134217728
有效：
重要性：中等
更新模式：全叢集

 

log.cleaner.delete.retention.ms
刪除記錄保留多長時間？

型別：長
預設：86400000（1天）。
有效值。
重要性：中等
更新模式：全叢集

 

log.cleaner.enable
啟用伺服器上執行的日誌清理程式。如果使用任何帶有cleanup.policy=compact的主題，包括內部偏移主題，則應啟用。如果禁用，這些主題將不會被壓縮，並會持續增長。

型別：布林值
預設：true
有效值。
重要性：中等
更新模式：只讀

 

log.cleaner.io.buffer.load.factor
日誌清理器重複資料刪除緩衝區的負載係數。重複資料緩衝區滿的百分比。較高的值將允許一次清理更多的日誌，但會導致更多的雜湊碰撞。

型別：雙人
預設值：0.9
有效值。
重要性：中等
更新模式：全叢集

 

log.cleaner.io.buffer.size
所有清理執行緒的日誌清理I/O緩衝區所使用的總記憶體。

型別：int
預設值：524288
有效值：[0，...]
重要性：中等
更新模式：全叢集

 

log.cleaner.io.max.bytes.per.second
日誌清理器將被節流，使其讀寫i/o之和平均小於此值。

型別：雙人
Default: 1.7976931348623157E308
有效值。
重要性：中等
更新模式：全叢集

 

log.cleaner.max.compaction.lag.ms
訊息在日誌中不符合壓實條件的最長時間。僅適用於正在壓縮的日誌。

型別：長
預設：9223372036854775807。
有效值。
重要性：中等
更新模式：全叢集

 

log.cleaner.min.cleanable.ratio
有資格進行清理的日誌的髒日誌與總日誌的最小比率。如果還指定了 log.cleaner.max.compaction.lag.ms 或 log.cleaner.min.compaction.lag.ms 配置，則日誌壓縮器會在以下任一情況下立即認為該日誌符合壓縮條件。(i) 達到 dirty ratio 閾值，並且日誌至少在 log.cleaner.min.compaction.lag.ms 持續時間內有 dirty（未壓實）記錄，或 (ii) 如果日誌至少在 log.cleaner.max.compaction.lag.ms 期間有 dirty（未壓實）記錄，則日誌壓實器認為該日誌符合壓實條件。

型別：雙
預設值：0.5
有效值。
重要性：中等
更新模式：全叢集

 

log.cleaner.min.compaction.lag.ms
訊息在日誌中未被壓縮的最少時間。僅適用於正在壓縮的日誌。

型別：長
預設值：0
有效值。
重要性：中等
更新模式：全叢集

  

 

log.cleaner.threads
用於清理日誌的後臺執行緒數。

型別：int
預設值：1
有效值：[0,...]
重要性：中等
更新模式：全叢集

 

 log.cleanup.policy

超出保留視窗的片段的預設清理策略。逗號分隔的有效策略列表。有效的策略是："刪除 "和 "壓縮"。"刪除 "和 "壓縮"

型別：list
預設：delete
有效值。 [compact, delete]
重要性：中等
更新模式：全叢集

 

log.index.interval.bytes

我們在偏移指數中新增條目的時間間隔。

型別：int
預設值：4096(4 kibibytes)
有效值：[0，...]
重要性：中等
更新模式：全叢集

  

log.index.size.max.bytes
偏移索引的最大大小，以位元組為單位。

型別：int
預設值：10485760(10 mebibytes)
有效值： [4，...]
重要性：中等
更新模式：全叢集

 

 

log.message.format.version
指定broker將使用的訊息格式版本來追加訊息到日誌。該值應該是一個有效的ApiVersion。一些例子是 0.8.2, 0.9.0.0, 0.10.0, 檢視ApiVersion瞭解更多細節。通過設定一個特定的訊息格式版本，使用者證明磁碟上所有現有的訊息都小於或等於指定的版本。不正確地設定這個值會導致使用舊版本的消費者崩潰，因為他們會收到一個他們不理解的格式的訊息。

型別：字串
預設：2.7-IV2
有效值。 [0.8.0、0.8.1、0.8.2、0.9.0、0.10.0-IV0、0.10.0-IV1、0.10.1-IV0、0.10.1-IV1、0.10.1-IV2、0.10.2-IV0、0.11.0-IV0、0.11.0-IV1、0.11.0-IV2、1.0-IV0、1. 1-IV0、2.0-IV0、2.0-IV1、2.1-IV0、2.1-IV1、2.1-IV2、2.2-IV0、2.2-IV1、2.3-IV0、2.3-IV1、2.4-IV0、2.4-IV1、2.5-IV0、2.6-IV0、2.7-IV0、2.7-IV1、2.7-IV2]
重要性：中等
更新模式：只讀

 

 

 

log.message.timestamp.difference.max.ms
broker收到訊息時的時間戳和訊息中指定的時間戳之間允許的最大差異。如果log.message.timestamp.type=CreateTime，如果時間戳的差異超過這個閾值，訊息將被拒絕。如果log.message.timestamp.type=LogAppendTime.允許的最大時間戳差異不應大於log.retain.ms，以避免不必要的頻繁日誌滾動。

型別：長
預設：9223372036854775807。
有效值。
重要性：中等
更新模式：全叢集

 

 

 

log.message.timestamp.type
定義訊息中的時間戳是訊息建立時間還是日誌追加時間。該值應該是`CreateTime`或`LogAppendTime`。

型別：字串
預設值。 CreateTime
有效值。 [CreateTime, LogAppendTime]
重要性：中等
更新模式：全叢集

 

 

 

log.preallocate
建立新段時是否應該預分配檔案？如果你在Windows上使用Kafka，你可能需要將其設定為true。

型別：布林值
預設：假
有效值。
重要性：中等
更新模式：全叢集

 

 

log.retention.check.interval.ms
日誌清理器檢查任何日誌是否符合刪除條件的頻率，以毫秒為單位。

型別：長
預設：300000（5分鐘）
有效值：[1，...]
重要性：中等
更新模式：只讀

 

 

max.connection.creation.rate
我們在任何時候在broker中允許的最大連線建立速率。監聽器級別的限制也可以通過在配置名前加上監聽器字首來配置，例如，listener.name.internal.max.connection.create.rate.broker範圍內的連線速率限制應該根據broker的容量來配置，而監聽器的限制應該根據應用需求來配置。如果達到了監聽器或broker限制，新的連線將被節流，但broker間監聽器除外。只有當達到監聽器級速率限制時，broker間監聽器上的連線才會被節流。

型別：int
預設：2147483647
有效值：[0，...]
重要性：中等
更新模式：全叢集

 

 

 max.connections

我們在任何時候允許的最大連線數。除了使用 max.connections.per.ip 配置的任何 per-ip 限制外，這個限制也會被應用。監聽器級別的限制也可以通過在配置名稱前加上監聽器字首來配置，例如，listener.name.internal.max.connection。Broker範圍的限制應該根據broker的容量來配置，而監聽器的限制應該根據應用需求來配置。如果達到了監聽器或broker的限制，新的連線就會被阻止。即使達到了broker-wide限制，也允許在broker間監聽器上進行連線。在這種情況下，另一個監聽器上最近使用最少的連線將被關閉。

型別：int
預設：2147483647
有效值：[0，...]
重要性：中等
更新模式：全叢集

 

 

 max.connections.per.ip

每個ip地址允許的最大連線數。如果使用max.connections.per.ip.overrides屬性配置了覆蓋項，則可以將其設定為0。如果達到上限，來自該ip地址的新連線將被丟棄。

型別：int
預設：2147483647
有效值：[0，...]
重要性：中等
更新模式：全叢集

 

 

 max.connections.per.ip.overrides

以逗號分隔的每ip或主機名的列表，覆蓋預設的最大連線數。例如："hostName:100,127.0.0.1:200"

型別：字串
預設：""
有效值。
重要性：中等
更新模式：全叢集

 

 

 max.incremental.fetch.session.cache.slots

我們將維持的最大增量取數。

型別：int
預設：1000
有效值：[0，...]
重要性：中等
更新模式：只讀

 

 

 

num.partitions
每個主題的預設日誌分割槽數

型別：int
預設值：1
有效值：[1,...]
重要性：中等
更新模式：只讀

 

 

 

password.encoder.old.secret
用於動態配置密碼編碼的舊密碼。只有在更新祕密時才需要這個。如果指定了，所有動態編碼的密碼都會使用這個舊的祕密進行解碼，並在 broker 啟動時使用 password.encoder.secret 重新編碼。

型別：密碼
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

password.encoder.secret
用於編碼該broker動態配置的密碼的祕密。

型別：密碼
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

principal.builder.class
實現KafkaPrincipalBuilder介面的類的全稱，該介面用於構建授權過程中使用的KafkaPrincipal物件。該配置還支援被廢棄的PrincipalBuilder介面，該介面之前用於通過SSL進行客戶端認證。如果沒有定義Principal builder，預設行為取決於使用的安全協議。對於SSL身份驗證，如果提供了客戶證照，將使用應用於客戶證照中的區別名稱的ssl.principal.mapping.rule所定義的規則推匯出Principal；否則，如果不需要客戶身份驗證，Principal名稱將是ANONYMOUS。對於SASL認證，如果使用GSSAPI，則將使用sasl.kerberos.principal.to.local.rules定義的規則推匯出principal，對於其他機制，則使用SASL認證ID。對於PLAINTEXT，principal將是ANONYMOUS。

型別：類
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

 

 

producer.purgatory.purge.interval.requests
生產者請求淨化器的淨化間隔（以請求數為單位）。

型別：int
預設：1000
有效值。
重要性：中等
更新模式：只讀

 

 

 

queued.max.request.bytes
在不再讀取更多請求之前，允許排隊的位元組數。

型別：長
預設值：-1
有效值。
重要性：中等
更新模式：只讀

 

 

 

replica.fetch.backoff.ms
發生取件分割槽錯誤時的睡眠時間。

型別：int
預設：1000（1秒）
有效值：[0，...]
重要性：中等
更新模式：只讀

 

 

 

replica.fetch.max.bytes
每個分割槽要嘗試獲取的訊息位元組數。這不是一個絕對的最大值，如果取回的第一個非空分割槽的第一個記錄批大於這個值，記錄批仍然會被返回，以確保可以取得進展。broker接受的最大記錄批次大小通過message.max.bytes（broker配置）或max.message.bytes（topic配置）來定義。

型別：int
預設值：1048576(1 mebibyte)
有效值：[0，...]
重要性：中等
更新模式：只讀

 

 

 

replica.fetch.response.max.bytes
整個取回響應的最大位元組數。記錄是分批取回的，如果取回的第一個非空分割槽中的第一個記錄批大於這個值，則仍然會返回該記錄批，以確保可以取得進展。因此，這不是一個絕對的最大值。broker接受的最大記錄批次大小通過message.max.bytes（broker配置）或max.message.bytes（topic配置）來定義。

型別：int
預設值：10485760(10 mebibytes)
有效值：[0，...]
重要性：中等
更新模式：只讀

 

 

 

replica.selector.class
實現 ReplicaSelector 的完全限定類名。這被broker用來尋找首選的讀取副本。預設情況下，我們使用返回領導者的實現。

型別：字串
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

reserved.broker.max.id
broker.id可以使用的最大數量。

型別：int
預設：1000
有效值：[0，...]
重要性：中等
更新模式：只讀

 

 

 

sasl.client.callback.handler.class
實現AuthenticateCallbackHandler介面的SASL客戶端回撥處理程式類的全稱。

型別：類
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

sasl.enabled.mechanisms
Kafka伺服器中啟用的SASL機制列表。該列表可以包含任何安全提供者可用的機制。預設情況下，只有GSSAPI被啟用。

型別：列表
預設值。 GSSAPI
有效值。
重要性：中等
更新模式：每個broker

 

 

 

 

sasl.jaas.config
JAAS登入上下文引數，用於SASL連線，格式為JAAS配置檔案使用的格式。JAAS配置檔案的格式在這裡有介紹。值的格式為：'loginModuleClass controlFlag (optionName=optionValue)*;'。對於broker來說，配置必須以監聽器字首和SASL機制名稱為字首，並以小寫字母表示。例如，listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.exam.ScramLoginModule必填。

型別：密碼
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

 

sasl.kerberos.kinit.cmd
Kerberos kinit 命令路徑。

型別：字串
預設值。 /usr/bin/kinit
有效值。
重要性：中等
更新模式：每個broker

 

 

 

sasl.kerberos.min.time.before.relogin
登入執行緒重新整理嘗試之間的睡眠時間。

型別：長
預設值：60000
有效值。
重要性：中等
更新模式：每個broker

 

 

 

sasl.kerberos.principal.to.local.rules
從主名到短名（通常是作業系統使用者名稱）的對映規則列表。這些規則按順序評估，與主名匹配的第一條規則被用來將其對映為短名。列表中後面的任何規則都會被忽略。預設情況下，{username}/{hostname}@{REALM}形式的主名會被對映到{username}。有關格式的更多細節，請參見安全授權和acls。請注意，如果 principal.builder.class 配置提供了 KafkaPrincipalBuilder 的擴充套件，這個配置將被忽略。

型別：列表
預設值。 DEFAULT
有效值。
重要性：中等
更新模式：每個broker

 

 

sasl.kerberos.service.name
Kafka 執行的 Kerberos 主體名稱。這可以在Kafka的JAAS配置或Kafka的配置中定義。

型別：字串
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

 

 

sasl.kerberos.ticket.renew.jitter
隨機抖動加到續航時間的百分比。

型別：雙倍
預設值：0.05
有效值。
重要性：中等
更新模式：每個broker

 

 

 

sasl.kerberos.ticket.renew.window.factor。
登入執行緒將休眠，直到達到從上次重新整理到票據到期的指定時間視窗係數，這時它將嘗試更新票據。

型別：雙倍
預設值：0.8
有效值。
重要性：中等
更新模式：每個broker

 

 

sasl.login.callback.handler.class
實現AuthenticateCallbackHandler介面的SASL登入回撥處理程式類的完全限定名稱。對於broker來說，登入回撥處理程式配置必須以監聽器字首和小寫的SASL機制名稱為字首。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler。

型別：類
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

 

sasl.login.class
實現Login介面的類的全稱。對於broker來說，login config必須以監聽器字首和SASL機制名稱為字首，並使用小寫。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin。

型別：類
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

sasl.login.refresh.buffer.seconds
重新整理憑證時，在憑證到期前要保持的緩衝時間，以秒為單位。如果重新整理的時間離到期時間比緩衝秒數更近，那麼重新整理時間將被提前，以儘可能多地保持緩衝時間。法定值在0到3600（1小時）之間；如果沒有指定值，則使用預設值300（5分鐘）。如果該值和sasl.login.refresh.min.period.seconds的總和超過了憑證的剩餘壽命，則該值和sasl.login.refresh.min.period.seconds都會被忽略。目前只適用於OAUTHBEARER。

型別：short
預設值：300
有效值。
重要性：中等
更新模式：每個broker

 

 

 

sasl.login.refresh.min.period.seconds
登入重新整理執行緒在重新整理憑證前需要等待的最短時間，以秒為單位。合法值在0到900（15分鐘）之間；如果沒有指定值，則使用預設值60（1分鐘）。如果這個值和sasl.login.refresh.buffer.seconds的總和超過了一個憑證的剩餘壽命，那麼這個值和sasl.login.buffer.seconds都會被忽略。目前只適用於OAUTHBEARER。

型別：short
預設值：60
有效值。
重要性：中等
更新模式：每個broker

 

 

 

sasl.login.refresh.window.factor
登入重新整理執行緒將休眠，直到達到相對於憑證壽命的指定視窗係數，此時將嘗試重新整理憑證。合法值在0.5(50%)到1.0(100%)之間，如果沒有指定值，則使用預設值0.8(80%)。目前僅適用於OAUTHBEARER。

型別：double
預設值：0.8
有效值。
重要性：中等
更新模式：每個broker

 

 

 

sasl.login.refresh.window.jitter
相對於憑證的壽命，加到登入重新整理執行緒的睡眠時間的最大隨機抖動量。合法值在0到0.25（25%）之間，如果沒有指定值，則使用預設值0.05（5%）。目前只適用於OAUTHBEARER。

型別：double
預設值：0.05
有效值。
重要性：中等
更新模式：每個broker

 

 

 

sasl.mechanism.inter.broker.protocol
用於broker之間通訊的SASL機制。預設為GSSAPI。

型別：string
預設值。 GSSAPI
有效值。
重要性：中等
更新模式：每個broker

 

 

 

sasl.server.callback.handler.class
實現AuthenticateCallbackHandler介面的SASL伺服器回撥處理程式類的完全限定名稱。伺服器回撥處理程式必須以監聽器字首和SASL機制名稱為字首，並使用小寫字母。例如，listener.name.sasl_ssl.plain.sasl.server.callback.handler.class=com.example.CustomPlainCallbackHandler。

型別：class
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

security.inter.broker.protocol
用於broker之間通訊的安全協議。有效值是： PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL. 同時設定此屬性和inter.broker.listener.name屬性是錯誤的。

型別：string
預設值。 PLAINTEXT
有效值。
重要性：中等
更新模式：只讀

 

 

 

socket.connection.setup.timeout.max.ms
客戶端等待建立套接字連線的最大時間。連線設定超時時間將隨著每一次連續的連線失敗而成倍增加，直到這個最大值。為了避免連線風暴，超時時間將被應用於0.2的隨機係數，結果是低於計算值20%到高於計算值20%的隨機範圍。

型別：長
預設：127000（127秒）
有效值。
重要性：中等
更新模式：只讀

 

 

socket.connection.setup.timeout.ms
客戶端等待socket連線建立的時間。如果在超時之前沒有建立連線，客戶端將關閉socket通道。

型別：long
預設：10000（10秒）
有效值。
重要性：中等
更新模式：只讀

 

 

 

 

ssl.cipher.suites
密碼套件的列表。這是一個命名的認證、加密、MAC和金鑰交換演算法的組合，用於使用TLS或SSL網路協議協商網路連線的安全設定。預設情況下，支援所有可用的密碼套件。

型別：list
預設：""
有效值。
重要性：中等
更新模式：每個broker

 

 

 

ssl.client.auth
配置kafka broker請求客戶端認證。以下是常用的設定。

ssl.client.auth=required 如果設定為require，則客戶端認證是必須的。
ssl.client.auth=requested 這意味著客戶端認證是可選的，與required不同，如果設定了這個選項，客戶端可以選擇不提供自己的認證資訊。
ssl.client.auth=none 這表示不需要客戶端認證。
型別：string
預設：無
有效值： [required, requested, none]
重要性：中等
更新模式：每個broker

 

 

 

ssl.enabled.protocols
為SSL連線啟用的協議列表。預設值是 "TLSv1.2,TLSv1.3"，當執行Java 11或更新版本時，否則為 "TLSv1.2"。在Java 11的預設值下，如果客戶端和伺服器都支援TLSv1.3，則會優先選擇TLSv1.3，否則會回退到TLSv1.2（假設兩者都至少支援TLSv1.2）。這個預設值在大多數情況下應該是沒有問題的。也可以參考`ssl.protocol`的配置文件。

型別：list
預設值: TLSv1.2
有效值。
重要性：中等
更新模式：每個broker

 

 

ssl.key.password
金鑰儲存檔案中私鑰的密碼，或在`ssl.keystore.key'中指定的PEM金鑰。只有在配置了雙向身份驗證的情況下，客戶端才需要這個密碼。

型別：password
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

 

ssl.keymanager.algorithm
鑰匙管理器工廠用於SSL連線的演算法，預設值是為Java虛擬機器配置的鑰匙管理器工廠演算法。預設值是為Java虛擬機器配置的金鑰管理器工廠演算法。

型別：string
預設值。 SunX509
有效值。
重要性：中等
更新模式：每個broker

 

 

 

ssl.keystore.certificate.chain
證照鏈的格式由'ssl.keystore.type'指定。預設的SSL引擎工廠只支援PEM格式的X.509證照列表。

型別：password
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

 

ssl.keystore.key
私鑰的格式由'ssl.keystore.type'指定。預設SSL引擎工廠只支援PEM格式的PKCS#8金鑰。如果金鑰是加密的，必須使用'ssl.key.password'指定金鑰密碼。

型別：password
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

 

ssl.keystore.location
金鑰儲存檔案的位置。對客戶端來說是可選的，可以用於客戶端的雙向認證。

型別：string
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

 

ssl.keystore.password
金鑰儲存檔案的儲存密碼。這對客戶端來說是可選的，只有在配置了'ssl.keystore.location'時才需要。對於PEM格式，不支援金鑰儲存密碼。

型別：password
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

ssl.keystore.type
金鑰儲存檔案的檔案格式。對客戶端來說是可選的。

型別：string
預設值。 JKS
有效值。
重要性：中等
更新模式：每個broker

 

 

 

 

ssl.protocol
用來生成SSLContext的SSL協議，預設為'TLSv1.3'，否則為'TLSv1.2'。當執行Java 11或更新版本時，預設為'TLSv1.3'，否則為'TLSv1.2'。這個值對於大多數的使用情況來說應該是沒有問題的。在最近的JVM中允許的值是'TLSv1.2'和'TLSv1.3'。TLS'，'TLSv1.1'，'SSL'，'SSLv2'和'SSLv3'在舊的JVM中可能會被支援，但由於已知的安全漏洞，我們不鼓勵使用它們。在這個配置和'ssl.enabled.protocols'的預設值下，如果伺服器不支援'TLSv1.3'，客戶端將降級為'TLSv1.2'。如果這個配置被設定為'TLSv1.2'，即使是ssl.enabled.protocols中的一個值，並且伺服器只支援'TLSv1.3'，客戶端也不會使用'TLSv1.3'。

型別：string
預設值: TLSv1.2
有效值。
重要性：中等
更新模式：每個broker

 

 

ssl.provider
用於SSL連線的安全提供者的名稱。預設值是JVM的預設安全提供者。

型別：string
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

 

 

ssl.trustmanager.algorithm
信任管理器工廠用於SSL連線的演算法。預設值是為Java虛擬機器配置的信任管理器工廠演算法。

型別：string
預設值。 PKIX
有效值。
重要性：中等
更新模式：每個broker

 

 

 

ssl.truststore.certificates
可信證照的格式由'ssl.truststore.type'指定。預設SSL引擎工廠只支援PEM格式的X.509證照。

型別：password
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

ssl.truststore.location
信任儲存檔案的位置。

型別：string
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

 

 

ssl.truststore.password
信任儲存檔案的密碼。如果沒有設定密碼，則仍然使用配置的信任儲存檔案，但完整性檢查被禁用。PEM格式不支援信任儲存密碼。

型別：password
預設值: null
有效值。
重要性：中等
更新模式：每個broker

 

 

 

ssl.truststore.type
信任儲存檔案的檔案格式。

型別：string
預設值。 JKS
有效值。
重要性：中等
更新模式：每個broker

 

 

 

zookeeper.clientCnxnSocket
當使用TLS連線到ZooKeeper時，通常設定為org.apache.zookeeper.ClientCnxnSocketNetty。覆蓋任何通過同名的zookeeper.clientCnxnSocket系統屬性設定的顯式值。

型別：string
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

zookeeper.ssl.client.enable
設定客戶端連線到ZooKeeper時使用TLS。顯式的值會覆蓋任何通過zookeeper.client.secure system屬性設定的值（注意名稱不同）。如果兩者都沒有設定，預設為false；當為true時，必須設定zookeeper.clientCnxnSocket（通常為org.apache.zookeeper.ClientCnxnSocketNetty）；其他需要設定的值可能包括zookeeper.ssl.cipher.suites、zookeeper.ssl.crl.enable、zookeeper.ssl.enabled.protocols、zookeeper.ssl. endpoint.identification.algorithm, zookeeper.ssl.keystore.location, zookeeper.ssl.keystore.password, zookeeper.ssl.keystore.type, zookeeper.ssl.ocsp.enable, zookeeper.ssl.protocol, zookeeper.ssl.truststore.location, zookeeper.ssl.truststore.password, zookeeper.ssl.truststore.type。

型別: boolean
預設：假
有效值。
重要性：中等
更新模式：只讀

 

 

 

zookeeper.ssl.keystore.location
當使用客戶端證照與TLS連線到ZooKeeper時的keystore位置。覆蓋任何通過zookeeper.ssl.keyStore.location系統屬性設定的顯式值(注意是camelCase)。

型別：string
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

zookeeper.ssl.keystore.password
當使用客戶端證照與TLS連線到ZooKeeper時的金鑰儲存密碼。覆蓋任何通過zookeeper.ssl.keyStore.password系統屬性設定的顯式值(注意是camelCase)。注意ZooKeeper不支援與keystore密碼不同的金鑰密碼，所以一定要將keystore中的金鑰密碼設定為與keystore密碼相同，否則連線Zookeeper的嘗試將失敗。

型別：password
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

zookeeper.ssl.keystore.type
當使用客戶端證照與TLS連線到ZooKeeper時的keystore型別。覆蓋任何通過zookeeper.ssl.keyStore.type系統屬性設定的顯式值（注意駱駝大寫）。預設值為null意味著型別將根據keystore的副檔名自動檢測。

型別：string
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

zookeeper.ssl.truststore.location
當使用TLS連線到ZooKeeper時的Truststore位置。覆蓋任何通過zookeeper.ssl.trustStore.location系統屬性設定的顯式值(注意是camelCase)。

型別：string
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

zookeeper.ssl.truststore.password
當使用TLS連線到ZooKeeper時的Truststore密碼。覆蓋任何通過zookeeper.ssl.trustStore.password系統屬性設定的顯式值（注意是camelCase）。

型別：password
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

zookeeper.ssl.truststore.type
當使用TLS連線到ZooKeeper時的Truststore型別。覆蓋任何通過zookeeper.ssl.trustStore.type系統屬性設定的顯式值（注意駱駝大寫）。預設值為null意味著該型別將根據truststore的副檔名自動檢測。

型別：string
預設值: null
有效值。
重要性：中等
更新模式：只讀

 

 

 

alter.config.policy.class.name
應該用於驗證的 alter configs 策略類。該類應該實現org.apache.kafka.server.policy.AlterConfigPolicy介面。

型別：class
預設值: null
有效值。
重要性：低
更新模式：只讀

 

 

 

alter.log.dirs.replication.quota.window.num
為改變日誌目錄複製配額而保留在記憶體中的樣本數量。

型別：int
預設值：11
有效值：[1，...]
重要性：低
更新模式：只讀

 

 

 

alter.log.dirs.replication.quota.window.size.seconds
alter log dirs複製配額的每個樣本的時間跨度。

型別：int
預設值：1
有效值：[1,...]
重要性：低
更新模式：只讀

 

 

 

authorizer.class.name
實現sorg.apache.kafka.server.authorizer.Authorizer介面的類的完全限定名稱，該類被broker用於授權。該配置還支援實現已廢棄的kafka.security.uth.Authorizer trait的授權者，該授權者以前用於授權。

型別：string
預設：""
有效值。
重要性：低
更新模式：只讀

 

 

 

client.quota.callback.class
實現ClientQuotaCallback介面的類的全稱，該類用於確定應用於客戶端請求的配額限制。預設情況下，應用的是 ，或ZooKeeper中儲存的配額。對於任何給定的請求，將應用與會話的使用者主控和請求的client-id相匹配的最具體的配額。

型別：class
預設值: null
有效值。
重要性：低
更新模式：只讀

 

 

 

connection.failed.authentication.delay.ms
認證失敗時的連線關閉延遲：這是認證失敗時連線關閉延遲的時間（毫秒）。該值必須配置為小於 connections.max.idle.ms，以防止連線超時。

型別：int
預設值：100
有效值：[0，...]
重要性：低
更新模式：只讀

 

controller.quota.window.num
控制器突變配額在記憶體中保留的樣本數量。

型別：int
預設值：11
有效值：[1，...]
重要性：低
更新模式：只讀

 

controller.quota.window.size.seconds
控制器突變定額的每個樣本的時間跨度。

型別：int
預設值：1
有效值：[1,...]
重要性：低
更新模式：只讀

 

create.topic.policy.class.name
應該用於驗證的建立主題策略類。該類應該實現org.apache.kafka.server.policy.CreateTopicPolicy介面。

型別：class
預設值: null
有效值。
重要性：低
更新模式：只讀

 

delegation.token.expiry.check.interval.ms
移除過期的授權令牌的掃描間隔。

型別：長
預設：3600000（1小時)
有效值：[1，...]
重要性：低
更新模式：只讀

kafka.metrics.polling.interval.secs
kafka.metrics.reporters實現中可以使用的度量值輪詢間隔（秒）。

型別：int
預設值：10
有效值：[1，...]
重要性：低
更新模式：只讀

 

 

 

kafka.metrics.reporters
作為Yammer metrics自定義報告器的類列表。這些報告器應該實現kafka.metrics.KafkaMetricsReporter trait。如果客戶端想要在自定義報告器上公開JMX操作，自定義報告器需要額外實現一個MBean trait，這個MBean trait擴充套件了kafka.metrics.KafkaMetricsReporterMBean trait，以便註冊的MBean符合標準MBean約定。

型別：list
預設：""
有效值。
重要性：低
更新模式：只讀

 

 

 

listener.security.protocol.map
監聽器名稱和安全協議之間的對映。要想讓同一個安全協議在多個埠或IP中使用，就必須定義這個對映。例如，內部和外部流量可以分開，即使兩者都需要SSL。具體來說，使用者可以將名稱為INTERNAL和EXTERNAL的監聽器和這個屬性定義為。`INTERNAL:SSL,EXTERNAL:SSL`。如圖所示，鍵和值用冒號隔開，對映項用逗號隔開。每個監聽器名稱在地圖中只能出現一次。通過在配置名稱中新增規範化的字首（監聽器名稱為小寫），可以為每個監聽器配置不同的安全（SSL和SASL）設定。例如，如果要為INTERNAL監聽器設定不同的keystore，就可以設定名稱為listener.name.internal.ssl.keystore.location的config。如果沒有設定監聽器名稱的config，config將回落到通用config（即ssl.keystore.location）。

型別：string
預設值。 PLAINTEXT:PLAINTEXT，SSL:SSL，SASL_PLAINTEXT:SASL_PLAINTEXT，SASL_SSL:SASL_SSL。
有效值。
重要性：低
更新模式：每個broker

 

 

 

log.message.downconversion.enable
此配置控制是否啟用訊息格式的向下轉換以滿足消費請求。當設定為false時，broker不會對期待舊訊息格式的消費者執行向下轉換。broker 會對來自此類舊客戶的消費請求作出 UNSUPPORTED_VERSION 錯誤響應。此配置不適用於複製到跟隨者時可能需要的任何訊息格式轉換。

型別：boolean
預設：true
有效值。
重要性：低
更新模式：全叢集

 

 

 

metric.reporters
作為度量報告器使用的類的列表。實現org.apache.kafka.common.metrics.MetricsReporter介面允許插入將被通知新的度量建立的類。JmxReporter總是被包含在註冊JMX統計資料中。

型別：list
預設：""
有效值。
重要性：低
更新模式：全叢集

 

 

 

metrics.num.samples
為計算指標而維護的樣本數量。

型別：int
預設值：2
有效值：[1,...]
重要性：低
更新模式：只讀

 

 

 

metrics.recording.level
指標的最高記錄級別。

型別：string
預設：INFO
有效值。
重要性：低
更新模式：只讀

 

 

metrics.sample.window.ms
度量樣本計算的時間視窗。

型別：長
預設：30000（30秒)
有效值：[1，...]
重要性：低
更新模式：只讀

 

 

 

password.encoder.cipher.algorithm
動態配置密碼的加密演算法。

型別：string
預設情況下，AES/CBC/PKCS5Padding AES/CBC/PKCS5Padding。
有效值。
重要性：低
更新模式：只讀

 

 

 

password.encoder.iterations
動態配置的密碼編碼的迭代次數。

型別：int
預設值：4096
有效值： [1024，...]
重要性：低
更新模式：只讀

 

 

 

password.encoder.key.length
動態配置密碼的金鑰長度。

型別：int
預設值：128
有效值： [8，...]
重要性：低
更新模式：只讀

 

 

password.encoder.keyfactory.algorithm
用於動態配置密碼編碼的SecretKeyFactory演算法，如果有的話，預設為PBKDF2WithHmacSHA512，否則為PBKDF2WithHmacSHA1。預設值為PBKDF2WithHmacSHA512（如果可用），否則為PBKDF2WithHmacSHA1。

型別：string
預設值: null
有效值。
重要性：低
更新模式：只讀

 

 

 

 

quota.window.num
客戶端配額在記憶體中保留的樣本數量。

型別：int
預設值：11
有效值：[1，...]
重要性：低
更新模式：只讀

 

 

 

quota.window.size.seconds
客戶定額的每個樣本的時間跨度。

型別：int
預設值：1
有效值：[1,...]
重要性：低
更新模式：只讀

 

 

replication.quota.window.num
為複製配額而保留在記憶體中的樣本數量。

型別：int
預設值：11
有效值：[1，...]
重要性：低
更新模式：只讀

 

 

 

replication.quota.window.size.seconds
複製定額的每個樣本的時間跨度。

型別：int
預設值：1
有效值：[1,...]
重要性：低
更新模式：只讀

 

 

 

security.providers
一個可配置的建立者類的列表，每個類都返回一個實現安全演算法的提供者。這些類應該實現org.apache.kafka.common.security.ah.SecurityProviderCreator介面。

型別：string
預設值: null
有效值。
重要性：低
更新模式：只讀

 

 

 

ssl.endpoint.identification.algorithm
使用伺服器證照驗證伺服器主機名的端點識別演算法。

型別：string
預設：https
有效值。
重要性：低
更新模式：每個broker

 

 

 

ssl.engine.factory.class
org.apache.kafka.common.security.auth.SslEngineFactory型別的類來提供SSLEngine物件。預設值是org.apache.kafka.common.security.ssl.DefaultSslEngineFactory。

型別：class
預設值: null
有效值。
重要性：低
更新模式：每個broker

 

 

 

ssl.principal.mapping.rules
用於將客戶證照中的區別名稱對映到短名稱的規則列表。這些規則按順序評估，第一條與主名匹配的規則被用來將其對映為短名。列表中的任何後面的規則將被忽略。預設情況下，X.500 證照的區別名稱將是主證照。有關格式的更多細節，請參見安全授權和 acls。請注意，如果 principal.builder.class 配置提供了 KafkaPrincipalBuilder 的擴充套件，這個配置將被忽略。

型別：string
預設值。 預設值: DEFAULT
有效值。
重要性：低
更新模式：只讀

 

 

 

ssl.secure.random.implementation
用於SSL加密操作的SecureRandom PRNG實現。

型別：string
預設值: null
有效值。
重要性：低
更新模式：每個broker

 

 

transaction.abort.timed.out.transaction.cleanup.interval.ms
回滾已超時的事務的時間間隔。

型別：int
預設：10000（10秒)
有效值：[1，...]
重要性：低
更新模式：只讀

 

 

 

transaction.remove.expired.transaction.cleanup.interval.ms
刪除因transactional.id.expertation.ms過期而過期的事務的時間間隔。

型別：int
預設：3600000（1小時)
有效值：[1，...]
重要性：低
更新模式：只讀

 

 

 

zookeeper.ssl.cipher.suites
指定ZooKeeper TLS協商中使用的密碼套件（csv）。覆蓋任何通過zookeeper.ssl.ciphersuites系統屬性設定的顯式值（注意單字 "ciphersuites"）。預設值為null意味著啟用的密碼套件列表是由正在使用的Java執行時決定的。

型別：list
預設值: null
有效值。
重要性：低
更新模式：只讀

 

 

 

 

zookeeper.ssl.crl.enable
指定是否啟用ZooKeeper TLS協議中的證照撤銷列表。覆蓋任何通過zookeeper.ssl.crl系統屬性設定的顯式值（注意是短名）。

型別：boolean
預設：假
有效值。
重要性：低
更新模式：只讀

 

 

 

zookeeper.ssl.enabled.protocols
指定ZooKeeper TLS協商（csv）中啟用的協議。覆蓋任何通過zookeeper.ssl.enabledProtocols系統屬性設定的顯式值（注意駱駝大寫）。預設值為null意味著啟用的協議將是zookeeper.ssl.protocol配置屬性的值。

型別：list
預設值: null
有效值。
重要性：低
更新模式：只讀

 

 

 

zookeeper.ssl.endpoint.identification.algorithm
指定是否在ZooKeeper TLS協商過程中啟用主機名驗證，（不區分大小寫）"https "表示啟用ZooKeeper主機名驗證，顯式的空白值表示禁用（僅為測試目的建議禁用）。明確的值會覆蓋任何通過zookeeper.ssl.hostnameVerification系統屬性設定的 "true "或 "false "值（注意不同的名稱和值，true意味著https，false意味著空白）。

型別：string
預設：HTTPS
有效值。
重要性：低
更新模式：只讀

 

 

zookeeper.ssl.ocsp.enable
指定是否啟用ZooKeeper TLS協議中的線上證照狀態協議。覆蓋任何通過zookeeper.ssl.ocsp系統屬性設定的顯式值（注意是短名）。

型別：boolean
預設：假
有效值。
重要性：低
更新模式：只讀

 

 

 

 

zookeeper.ssl.protocol
指定ZooKeeper TLS協商中使用的協議。一個顯式的值會覆蓋通過同名的zookeeper.ssl.protocol系統屬性設定的任何值。

型別：string
預設值: TLSv1.2
有效值。
重要性：低
更新模式：只讀

 

 

zookeeper.sync.time.ms
一個ZK跟隨者可以落後於一個ZK領導者多遠

型別：int
預設：2000（2秒)
有效值。
重要性：低
更新模式：只讀

 

 

關於broker配置的更多細節可以在scala類kafka.server.KafkaConfig中找到。

 

3.1.1 更新broker配置

從Kafka 1.1版本開始，部分broker配置可以在不重新啟動broker的情況下進行更新。請參閱Broker Configs中的動態更新模式列，瞭解每個broker配置的更新模式。

• 只讀。需要重啟broker才能更新
• 每家broker。可為每個broker動態更新
• 全群集。可作為全群組的預設值動態更新。也可以作為每個broker的值進行更新，以便測試。

要改變當前broker id 0的broker配置（例如，日誌清理執行緒的數量）。

 

  > bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config log.cleaner.threads=2

 

要描述當前動態broker配置的broker id 0：

  > bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --describe

 

要刪除config覆蓋，並恢復到broker id 0的靜態配置或預設值（例如，日誌清理執行緒的數量）。

  > bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --delete-config log.cleaner.threads

 

某些配置可能會被配置為整個群集的預設值，以保持整個群集的一致值。叢集中的所有broker將處理叢集預設更新。例如，要更新所有broker上的日誌清理執行緒。

  > bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-default --alter --add-config log.cleaner.threads=2

 

要描述當前配置的動態全叢集預設配置。

  > bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-default --describe

 

所有在群集級別上可配置的配置值也可以在每個路由器級別上配置（例如用於測試）。如果一個配置值在不同級別定義，則使用以下優先順序。

• 在ZooKeeper中的動態儲存每個broker配置。
• 動態的全叢集預設配置儲存在ZooKeeper中。
• 從server.properties中靜態配置broker
• Kafka預設值，見broker配置

動態更新密碼設定

動態更新的密碼配置值在ZooKeeper中儲存前會被加密。broker配置password.encoder.secret必須在server.properties中配置以啟用動態更新密碼配置。不同的broker的secret可能不同。

用於密碼編碼的祕密可能會隨著broker的滾動重啟而輪換。目前ZooKeeper中用於編碼密碼的舊祕密必須在靜態broker配置password.encoder.old.secret中提供，新祕密必須在password.encoder.secret中提供。所有儲存在ZooKeeper中的動態密碼配置將在broker啟動時用新的祕密重新編碼。

在Kafka 1.1.x中，當使用kafka-configs.sh更新配置時，必須在每個alter請求中提供所有動態更新的密碼配置，即使密碼配置沒有被改變。這個限制將在未來的版本中被移除。

 

在開始broker之前更新ZooKeeper的密碼設定

從Kafka 2.0.0開始，kafka-configs.sh可以在啟動broker進行引導之前，使用ZooKeeper更新動態broker配置。這使得所有的密碼配置都以加密的形式儲存，避免了在server.properties中清除密碼的需要。如果在alter命令中包含任何密碼配置，還必須指定broker配置password.encoder.secret。也可以指定其他加密引數。密碼編碼器配置將不會在ZooKeeper中持續存在。例如，要在broker 0上儲存監聽器INTERNAL的SSL金鑰密碼。

> bin/kafka-configs.sh --zookeeper localhost:2182 --zk-tls-config-file zk_tls_config.properties --entity-type brokers --entity-name 0 --alter --add-config
    'listener.name.internal.ssl.key.password=key-password,password.encoder.secret=secret,password.encoder.iterations=8192'

配置監聽器.name.internal.ssl.key.password將使用提供的編碼器配置以加密的形式持久化在ZooKeeper中。編碼器的祕密和迭代不會持續在ZooKeeper中。

更新現有監聽器的SSL金鑰庫

broker可以配置有效期較短的SSL金鑰儲存，以降低證照洩露的風險。金鑰儲存可以動態更新，而無需重新啟動broker。配置名稱必須以監聽器字首listener.name.{listenerName}為字首，這樣就只更新特定監聽器的keystore配置。以下配置可以在每個broker級別的單個alter請求中更新。

• ssl.keystore.type
• ssl.keystore.location
• ssl.keystore.password
• ssl.key.password

如果監聽器是broker之間的監聽器，只有當新的keystore被為該監聽器配置的truststore信任時，才允許更新。對於其他監聽器，broker不會對金鑰store進行信任驗證。證照必須由簽署舊證照的同一證照頒發機構簽署，以避免任何客戶端驗證的失敗。

更新現有監聽器的SSL Truststore

brokertruststores可以動態更新，而不需要重新啟動broker來新增或刪除證照。更新後的truststore將用於驗證新的客戶端連線。配置名稱必須以監聽器字首listener.name.{listenerName}為字首，這樣只有特定監聽器的truststore配置才會更新。以下配置可以在每個broker級別的單個alter請求中更新。

• ssl.truststore.type
• ssl.truststore.location
• ssl.truststore.password

如果監聽器是broker之間的監聽器，只有當該監聽器的現有keystore被新的truststore信任時，才允許更新。對於其他監聽器，更新前，中間商不進行信任驗證。從新的信任store中刪除用於簽署客戶端證照的CA證照會導致客戶端認證失敗。

 

更新預設主題配置

broker使用的預設主題配置選項可以在不重啟broker的情況下更新。這些配置被應用於沒有主題配置覆蓋的主題，相當於每個主題的配置。這些配置中的一個或多個可以在所有broker使用的叢集預設級別被覆蓋。

• log.segment.bytes
• log.roll.ms
• log.roll.hours
• log.roll.jitter.ms
• log.roll.jitter.hours
• log.index.size.max.bytes
• log.flush.interval.messages
• log.flush.interval.ms
• log.retention.bytes
• log.retention.ms
• log.retention.minutes
• log.retention.hours
• log.index.interval.bytes
• log.cleaner.delete.retention.ms
• log.cleaner.min.compaction.lag.ms
• log.cleaner.max.compaction.lag.ms
• log.cleaner.min.cleanable.ratio
• log.cleanup.policy
• log.segment.delete.delay.ms
• unclean.leader.election.enable
• min.insync.replicas
• max.message.bytes
• compression.type
• log.preallocate
• log.message.timestamp.type
• log.message.timestamp.difference.max.ms

從Kafka 2.0.0版本開始，當動態更新配置unclean.leader.election.enhance時，控制器會自動啟用unclean.leader.election.enhance。在Kafka 1.1.x版本中，對unclean.leader.election.enable的更改只有在新控制器當選時才會生效。可以通過執行控制器重新選舉來強制執行。

> bin/zookeeper-shell.sh localhost
  rmr /controller

更新日誌清理器配置

日誌清理配置可以在所有broker使用的叢集預設級別動態更新。這些更改將在下一次日誌清理迭代時生效。這些配置中的一個或多個可以被更新。

• log.cleaner.threads
• log.cleaner.io.max.bytes.per.second
• log.cleaner.dedupe.buffer.size
• log.cleaner.io.buffer.size
• log.cleaner.io.buffer.load.factor
• log.cleaner.backoff.ms

更新執行緒配置

broker使用的各種執行緒池的大小可以在所有broker使用的叢集預設級別動態更新。更新限制在currentSize / 2到currentSize * 2的範圍內，以確保配置更新被優雅地處理。

• num.network.threads
• num.io.threads
• num.replica.fetchers
• num.recovery.threads.per.data.dir
• log.cleaner.threads
• background.threads

更新連線配額配置

broker對給定 IP/主機允許的最大連線數可以在所有broker使用的叢集預設級別動態更新。這些變化將適用於新連線的建立，現有的連線數將被新的限制所考慮。

• max.connections.per.ip
• max.connections.per.ip.overrides

新增和刪除監聽器

監聽器可以被動態地新增或刪除。當新增新的監聽器時，必須以監聽器字首listener.name.{listenerName}.的監聽器配置來提供監聽器的安全配置。如果新的監聽器使用SASL，必須使用JAAS配置屬性sasl.jaas.config提供監聽器的JAAS配置，並加上監聽器和機制字首。詳情請參見Kafkabroker的JAAS配置。

在Kafka 1.1.x版本中，broker間監聽器使用的監聽器可能無法動態更新。要將broker間監聽器更新為新的監聽器，可以在所有broker上新增新的監聽器，而不需要重新啟動broker。然後需要滾動重啟來更新inter.broker.listener.name。

除了新監聽器的所有安全配置外，以下配置可以在每個broker級別動態更新。

• listeners
• advertised.listeners
• listener.security.protocol.map

broker之間的監聽器必須使用靜態broker配置inter.broker.listener.name或inter.broker.security.protocol進行配置。

 

3.2 主題級配置

與主題相關的配置既有伺服器預設值，也有可選的每個主題覆蓋值。如果沒有給出每個主題的配置，則使用伺服器預設值。覆蓋可以在建立主題時通過給出一個或多個--config選項來設定。這個例子建立了一個名為my-topic的主題，並自定義了最大訊息大小和重新整理率。

> bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic my-topic --partitions 1 \
      --replication-factor 1 --config max.message.bytes=64000 --config flush.messages=1

覆蓋也可以在以後使用 alter configs 命令進行更改或設定。這個例子更新了my-topic的最大訊息大小。

> bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic
      --alter --add-config max.message.bytes=128000

要檢查主題上過載的設定，你可以執行以下操作

  > bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic --describe

 

要刪除過載的設定，您可以執行以下操作

> bin/kafka-configs.sh --bootstrap-server localhost:9092  --entity-type topics --entity-name my-topic
      --alter --delete-config max.message.bytes

以下是主題級的配置。在伺服器預設屬性標題下給出了該屬性的伺服器預設配置。給定的伺服器預設配置值只適用於沒有明確的主題配置覆蓋的主題。

 

cleanup.policy
字串，可以是 "刪除 "或 "壓縮"，或者兩者都是。此字串指定對舊日誌段使用的保留策略。預設策略（"刪除"）將在達到保留時間或大小限制時丟棄舊片段。緊湊 "設定將啟用主題上的日誌壓縮。

型別：list
預設：delete
有效值。[compact, delete]
伺服器預設屬性：log.cleanup.policy。
重要性：中等

 

compression.type
指定給定主題的最終壓縮型別。此配置接受標準的壓縮編解碼器（'gzip'、'snappy'、'lz4'、'zstd'）。此外，它還接受'uncompressed'，這相當於沒有壓縮；以及'producer'，這意味著保留製作者設定的原始壓縮編解碼器。

型別：string
預設：producer
有效值。 [uncompressed, zstd, lz4, snappy, gzip, producer]
伺服器預設屬性：compression.type
重要性：中等

 

delete.retention.ms
為日誌壓縮主題保留刪除墓碑標記的時間。如果消費者從偏移量0開始讀取，這個設定還給出了消費者必須完成讀取的時間界限，以確保他們得到最後階段的有效快照（否則，刪除墓碑可能會在完成掃描之前被收集）。

型別：long
預設：86400000（1天）。
有效值：[0，...]
伺服器預設屬性：log.cleaner.delete.retention.ms
重要性：中等

 

file.delete.delay.ms
從檔案系統中刪除檔案前等待的時間。

型別：long
預設：60000（1分鐘)
有效值：[0，...]
伺服器預設屬性：log.segment.delete.delay.ms
重要性：中等

 

flush.messages
這個設定允許指定一個時間間隔，在這個時間間隔內，我們將強制對寫入日誌的資料進行fsync。例如，如果設定為1，我們將在每條訊息後進行fsync；如果設定為5，我們將在每五條訊息後進行fsync。一般情況下，我們建議你不要設定這個，使用複製來保證永續性，並允許作業系統的後臺重新整理功能，因為它更有效率。這個設定可以在每個主題的基礎上被覆蓋（見每個主題配置部分）。

型別：長
預設：9223372036854775807。
有效值：[0，...]
伺服器預設屬性：log.flush.interval.messages
重要性：中等

 

flush.ms
這個設定允許指定一個時間間隔，在這個時間間隔內，我們將強制對寫入日誌的資料進行fsync。例如，如果設定為1000，我們將在1000毫秒後進行fsync。一般情況下，我們建議你不要設定這個，使用複製來提高耐用性，並允許作業系統的後臺重新整理功能，因為它更有效。

型別：long
預設：9223372036854775807。
有效值：[0，...]
伺服器預設屬性：log.flush.interval.ms
重要性：中等

 

follower.replication.throttled.replicas
一個副本的列表，對於這些副本，日誌複製應該在follower端進行節流。該列表應該以[PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:...的形式描述一組副本，或者使用萬用字元'*'來節制這個主題的所有副本。

型別：list
預設：""
有效值。 [partitionId]:[brokerId],[partitionId]:[brokerId],...
伺服器預設屬性：follower.replication.throttled.replicas
重要性：中等

 

 

index.interval.bytes
這個設定控制了Kafka向其偏移索引新增索引項的頻率。預設設定確保我們大約每4096個位元組為一條訊息建立索引。更多的索引允許讀取跳轉到更接近日誌中的準確位置，但會使索引更大。你可能不需要改變這個設定。

型別：int
預設值：4096(4 kibibytes)
有效值：[0，...]
伺服器預設屬性：log.index.interval.bytes
重要性：中等

 

 

leader.replication.throttled.replicas
複製的列表，對於這些複製，日誌複製應該在領導側進行節流。該列表應以[PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:...的形式描述一組副本，或者使用萬用字元'*'來節制這個主題的所有副本。

型別：list
預設：""
有效值。 [partitionId]:[brokerId],[partitionId]:[brokerId],...
伺服器預設屬性：leader.replication.throttled.replicas
重要性：中等

 

 

 

max.compaction.lag.ms
訊息在日誌中不符合壓實條件的最長時間。僅適用於正在壓縮的日誌。

型別：long
預設：9223372036854775807
有效值：[1，...]
伺服器預設屬性：log.cleaner.max.compaction.lag.ms
重要性：中等

 

 

max.message.bytes
Kafka允許的最大記錄批次大小（如果啟用壓縮，則壓縮後）。如果增加這個大小，並且有比0.10.2更老的消費者，消費者的取數大小也必須增加，這樣才能取到這麼大的記錄批。在最新的訊息格式版本中，為了提高效率，記錄總是被分組成批。在以前的訊息格式版本中，未壓縮的記錄不會被分組成批，在這種情況下，這個限制只適用於單個記錄。

型別：int
預設值：1048588
有效值：[0，...]
伺服器預設屬性： message.max.bytes
重要性：中等

 

 

message.format.version
指定broker將使用的訊息格式版本來追加訊息到日誌。該值應該是一個有效的ApiVersion。一些例子是 0.8.2, 0.9.0.0, 0.10.0, 檢視ApiVersion瞭解更多細節。通過設定一個特定的訊息格式版本，使用者證明磁碟上所有現有的訊息都小於或等於指定的版本。不正確地設定這個值會導致使用舊版本的消費者崩潰，因為他們會收到一個他們不理解的格式的訊息。

型別：string
預設：2.7-IV2
有效值。 [0.8.0、0.8.1、0.8.2、0.9.0、0.10.0-IV0、0.10.0-IV1、0.10.1-IV0、0.10.1-IV1、0.10.1-IV2、0.10.2-IV0、0.11.0-IV0、0.11.0-IV1、0.11.0-IV2、1.0-IV0、1. 1-IV0、2.0-IV0、2.0-IV1、2.1-IV0、2.1-IV1、2.1-IV2、2.2-IV0、2.2-IV1、2.3-IV0、2.3-IV1、2.4-IV0、2.4-IV1、2.5-IV0、2.6-IV0、2.7-IV0、2.7-IV1、2.7-IV2]
伺服器預設屬性：log.message.format.version
重要性：中等

 

 

message.timestamp.difference.max.ms
broker收到訊息時的時間戳和訊息中指定的時間戳之間允許的最大差異。如果 message.timestamp.type=CreateTime，如果時間戳的差異超過這個閾值，訊息將被拒絕。如果 message.timestamp.type=LogAppendTime，這個配置會被忽略。

型別：long
預設：9223372036854775807
有效值：[0，...]
伺服器預設屬性：log.message.timestamp.difference.max.ms
重要性：中等

 

 

message.timestamp.type
定義訊息中的時間戳是訊息建立時間還是日誌追加時間。該值應該是`CreateTime`或`LogAppendTime`。

型別：string
預設值: CreateTime
有效值: [CreateTime, LogAppendTime]
伺服器預設屬性：log.message.timestamp.type
重要性：中等

 

 

min.cleanable.dirty.ratio
此配置可控制日誌壓縮器嘗試清理日誌的頻率（假設已啟用日誌壓縮）。預設情況下，我們將避免清理日誌中超過 50% 的日誌已被壓縮。這個比率限制了重複的日誌所浪費的最大空間（在50%時，最多有50%的日誌可能是重複的）。更高的比率意味著更少、更有效的清理，但意味著日誌中浪費的空間更多。如果還指定了max.compaction.lag.ms或min.compaction.lag.ms配置，那麼日誌壓縮器認為只要達到以下任一條件，該日誌就有資格進行壓縮。(i) 達到 dirty ratio 閾值，並且日誌至少在 min.compaction.lag.ms 持續時間內有 dirty（未壓縮）記錄，或 (ii) 如果日誌最多在 max.compaction.lag.ms 期間有 dirty（未壓縮）記錄，則日誌壓縮器認為有資格進行壓縮。

型別：double
預設值：0.5
有效值：[0,...,1]
伺服器預設屬性：log.cleaner.min.cleanable.ratio
重要性：中等

  

 min.compaction.lag.ms

訊息在日誌中未壓縮的最短時間。僅適用於正在壓縮的日誌。

型別：long
預設值：0
有效值：[0,...]
伺服器預設屬性：log.cleaner.min.compaction.lag.ms
重要性：中等

  

 

min.insync.replicas
當生產者將acks設定為 "all"(或"-1")時，這個配置指定了必須確認寫入才能被認為是成功的最低數量的複製。如果不能滿足這個最小數量，那麼生產者將引發一個異常（NotEnoughReplicas或NotEnoughReplicasAfterAppend）。
當一起使用時，min.insync.replicas和acks允許你實施更大的耐久性保證。一個典型的場景是建立一個複製因子為3的主題，將min.insync.replicas設定為2，並以 "all "的acks進行生產。這將確保生產者在大多數副本沒有收到寫入時引發異常。

型別：int
預設值：1
有效值：[1,...]
伺服器預設屬性：min.insync.replicas
重要性：中等

  

 

preallocate
當建立一個新的日誌段時，如果我們應該在磁碟上預分配檔案，則為真。

型別：boolean
預設：false
有效值:
伺服器預設屬性：log.preallocate
重要性：中等

  

retention.bytes
如果我們使用 "刪除 "保留策略，此配置可控制分割槽（由日誌段組成）的最大大小，然後我們才會丟棄舊的日誌段以釋放空間。預設情況下，沒有大小限制，只有時間限制。由於該限制是在分割槽級別執行的，因此將其乘以分割槽的數量來計算以位元組為單位的主題保留。

型別：long
預設值：-1
有效值:
伺服器預設屬性：log.retaining.bytes
重要性：中等

 

 

 

retention.ms
如果我們使用 "刪除 "保留策略，此配置可控制我們在丟棄舊的日誌段以釋放空間之前保留日誌的最長時間。這代表了消費者必須在多長時間內讀取其資料的SLA。如果設定為-1，則不適用時間限制。

型別：long
預設：604800000（7天）
有效值：[-1,...]
伺服器預設屬性：log.retention.ms
重要性：中等

  

 

segment.bytes
此配置控制日誌的段檔案大小。保留和清理總是以檔案為單位進行的，因此較大的段大小意味著較少的檔案，但對保留的精細控制較少。

型別：int
預設值：1073741824 (1 gibibyte)
有效值： [14，...]
伺服器預設屬性：log.segment.bytes
重要性：中等

 

 

segment.index.bytes
這個配置控制了將偏移量對映到檔案位置的索引的大小。我們預先分配這個索引檔案，只有在日誌滾動後才會將其縮小。一般來說，你不應該需要改變這個設定。

型別：int
預設值：10485760(10 mebibytes)
有效值：[0，...]
伺服器預設屬性：log.index.size.max.bytes
重要性：中等

 

 

segment.jitter.ms
從預定的段滾動時間中減去的最大隨機抖動，以避免雷鳴般的段滾動群。

型別：long
預設值：0
有效值：[0,...]
伺服器預設屬性：log.roll.jitter.ms
重要性：中等

  

 

segment.ms
這個配置控制了一段時間後，即使段檔案沒有滿，Kafka也會強制滾動日誌，以確保留存可以刪除或壓縮舊資料。

型別：long
預設：604800000（7天）
有效值：[1，...]
伺服器預設屬性：log.roll.ms
重要性：中等

 

 

unclean.leader.election.enable
表示是否啟用不在 ISR 集中的副本作為最後手段被選為領導者，即使這樣做可能會導致資料丟失。

型別：boolean
預設：false
有效值
伺服器預設屬性：unclean.leader.election.enable
重要性：中等

 

 

message.downconversion.enable
此配置控制是否啟用訊息格式的向下轉換以滿足消費請求。當設定為false時，broker不會對期待舊訊息格式的消費者執行向下轉換。broker 會對來自此類舊客戶的消費請求作出 UNSUPPORTED_VERSION 錯誤響應。此配置不適用於複製到跟隨者時可能需要的任何訊息格式轉換。

型別：boolean
預設：true
有效值：
伺服器預設屬性：log.message.downconversion.enable
重要性：低

 

 

3.3 生產者配置

下面是生產者的配置：

 

 

key.serializer
實現org.apache.kafka.common.serialization.Serializer介面的key的Serializer類。

型別：class
預設值:
有效值:
重要性：高

 

 

value.serializer
實現 org.apache.kafka.common.serialization.Serializer 介面的值的 Serializer 類。

型別：class
預設值:
有效值:
重要性：高

 

 

acks
生產者要求領導人在認為請求完成之前收到的確認次數。這控制了傳送記錄的耐久性。允許以下設定。

acks=0 如果設定為0，那麼生產者將完全不等待伺服器的任何確認。記錄將立即被新增到套接字緩衝區中，並被視為已傳送。在這種情況下，不能保證伺服器已經收到了記錄，重試配置也不會生效（因為客戶端一般不會知道任何失敗）。每條記錄回饋的偏移量將始終設定為-1。
acks=1 這意味著領導者將把記錄寫到它的本地日誌中，但不需要等待所有跟隨者的完全確認就會做出回應。在這種情況下，如果領導者在確認記錄後，但在追隨者複製記錄之前立即失敗，那麼記錄將丟失。
acks=all 這意味著領導者將等待所有同步複製的記錄確認。這保證了只要至少有一個同步複製體還活著，記錄就不會丟失。這是最強的可用保證。這相當於 acks=-1 設定。
型別 : string
預設值：1
有效值：[all, -1, 0, 1]
重要性：高

 

 

bootstrap.servers
用於建立Kafka叢集初始連線的主機/埠對的列表。客戶端將使用所有的伺服器，不管這裡指定了哪些伺服器用於引導--這個列表隻影響用於發現全部伺服器集的初始主機。這個列表的形式應該是 host1:port1,host2:port2,....。因為這些伺服器只是用於初始連線，以發現完整的叢集成員（可能會動態變化），所以這個列表不需要包含完整的伺服器集（不過，你可能需要多個伺服器，以防某個伺服器當機）。

型別：list
預設：""
有效值：non-null string
重要性：高

 

 

buffer.memory
生產者可以用來緩衝等待傳送到伺服器的記錄的總記憶體位元組數。如果記錄的傳送速度超過了伺服器的傳送速度，那麼生產者就會緩衝max.block.ms，之後就會丟擲一個異常。

這個設定應該與生產者將使用的總記憶體大致對應，但並不是一個硬約束，因為生產者使用的記憶體並不都是用來緩衝的。一些額外的記憶體將被用於壓縮（如果啟用了壓縮）以及維護飛行中的請求。

型別：long
預設：33554432
有效值：[0，...]
重要性：高

 

 

compression.type
生產者生成的所有資料的壓縮型別。預設值是none（即無壓縮）。有效值為none、gzip、snappy、lz4或zstd。壓縮的是整批的資料，所以批處理的功效也會影響壓縮比（批處理越多意味著壓縮效果越好）。

型別：string
預設：none
有效值:
重要性：高

 

 

retries
設定一個大於零的值，將導致客戶端重新傳送任何傳送失敗的記錄，並可能出現短暫的錯誤。請注意，這種重試與客戶端在收到錯誤後重新傳送記錄沒有區別。允許重試而不將max.in.flight.request.per.connection設定為1，將有可能改變記錄的順序，因為如果向一個分割槽傳送兩批記錄，第一批失敗並重試，但第二批成功，那麼第二批的記錄可能會先出現。另外需要注意的是，如果delivery.timeout.ms配置的超時時間在成功確認前先過期，那麼在重試次數用完之前，produce請求就會失敗。一般來說，使用者最好不要設定這個配置，而是使用delivery.timeout.ms來控制重試行為。

型別：int
預設：2147483647
有效值： [0，...，2147483647]
重要性：高

  

 

ssl.key.password
金鑰儲存檔案中私鑰的密碼，或在`ssl.keystore.key'中指定的PEM金鑰。只有在配置了雙向身份驗證的情況下，客戶端才需要這個密碼。

型別：password
預設值: null
有效值:
重要性：高

 

 

ssl.keystore.certificate.chain
證照鏈的格式由'ssl.keystore.type'指定。預設的SSL引擎工廠只支援PEM格式的X.509證照列表。

型別：password
預設值: null
有效值:
重要性：高

 

ssl.keystore.key
私鑰的格式由'ssl.keystore.type'指定。預設SSL引擎工廠只支援PEM格式的PKCS#8金鑰。如果金鑰是加密的，必須使用'ssl.key.password'指定金鑰密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

 

ssl.keystore.location
金鑰儲存檔案的位置。對客戶端來說是可選的，可以用於客戶端的雙向認證。

型別：string
預設值: null
有效值:
重要性：高

 

 

ssl.keystore.password
金鑰儲存檔案的儲存密碼。這對客戶端來說是可選的，只有在配置了'ssl.keystore.location'時才需要。對於PEM格式，不支援金鑰儲存密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

 

ssl.truststore.certificates
可信證照的格式由'ssl.truststore.type'指定。預設SSL引擎工廠只支援PEM格式的X.509證照。

型別：password
預設值: null
有效值。
重要性：高

 

 

 

ssl.truststore.location
信任儲存檔案的位置。

型別：string
預設值: null
有效值。
重要性：高

 

 

ssl.truststore.password
信任儲存檔案的密碼。如果沒有設定密碼，則仍然使用配置的信任儲存檔案，但完整性檢查被禁用。PEM格式不支援信任儲存密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

batch.size
每當多個記錄被髮送到同一個分割槽時，生產者會嘗試將記錄一起批處理成較少的請求。這有助於提高客戶端和伺服器的效能。這個配置控制預設的批處理大小，單位是位元組。

不會嘗試將大於此大小的記錄批量化。

傳送給broker的請求將包含多個批次，每個具有可傳送資料的分割槽都有一個批次。

批量小會使批處理不常見，並可能會降低吞吐量（批量為零會完全禁止批處理）。一個非常大的批次大小可能會更浪費地使用記憶體，因為我們總是會分配一個指定的批次大小的緩衝區，以應對額外的記錄。

型別：int
預設值：16384
有效值：[0，...]
重要性：中等

 

 

 

client.dns.lookup
控制客戶端如何使用DNS查詢。如果設定為use_all_dns_ips，則依次連線到每個返回的IP地址，直到成功建立連線。斷開連線後，會使用下一個IP。一旦所有的IP都被使用過一次，客戶端就會再次解析主機名中的IP（然而，JVM和作業系統都會快取DNS名稱查詢）。如果設定為resolve_canonical_bootstrap_servers_only，則將每個引導地址解析成一個canonical名稱列表。在引導階段之後，這和use_all_dns_ips的行為是一樣的。如果設定為預設（已廢棄），即使查詢返回多個IP地址，也會嘗試連線到查詢返回的第一個IP地址。

型別：string
預設值: use_all_dns_ips
有效值。 [default, use_all_dns_ips, resolve_canonical_bootstrap_servers_only] 。
重要性：中等

 

 

client.id
一個ID字串，在發出請求時傳遞給伺服器。這樣做的目的是為了在伺服器端請求日誌中包含一個邏輯應用程式名稱，從而能夠跟蹤請求的來源，而不僅僅是ip/埠。

型別：string
預設：""
有效值。
重要性：中等

 

 

connections.max.idle.ms
在該配置指定的毫秒數之後關閉空閒連線。

型別：long
預設：540000（9分鐘)
有效值:
重要性：中等

 

 

delivery.timeout.ms
呼叫send()返回後報告成功或失敗的時間的上限。這限制了記錄在傳送前被延遲的總時間，等待broker確認的時間（如果預期），以及允許的可重複傳送失敗的時間。如果遇到不可恢復的錯誤，重試次數已經用盡，或者記錄被新增到一個達到較早傳送到期期限的批次中，生產者可能會報告未能在這個配置之前傳送記錄。這個配置的值應該大於或等於 request.timeout.ms 和 linger.ms 之和。

型別：int
預設：120000（2分鐘)
有效值：[0，...]
重要性：中等

 

 

linger.ms
製作者將請求傳輸之間到達的所有記錄歸為一個單一的批量請求。通常只有在負載下，當記錄到達的速度超過了它們的傳送速度時，才會出現這種情況。然而在某些情況下，即使在中等負載下，客戶端也可能希望減少請求的數量。這個設定通過新增少量的人為延遲來實現--也就是說，生產者不會立即傳送一條記錄，而是會等待到給定的延遲，以允許其他記錄被髮送，這樣就可以將這些記錄一起打包傳送。這可以被認為是類似於TCP中的Nagle演算法。這個設定給出了批處理延遲的上限：一旦我們得到一個分割槽的 batch.size 值的記錄，不管這個設定如何，它都會立即被髮送，但是如果我們為這個分割槽積累的位元組數少於這個數，我們就會在指定的時間內 "滯留"，等待更多記錄的出現。這個設定預設為0（即沒有延遲）。例如，設定linger.ms=5，會減少傳送請求的數量，但在沒有負載的情況下，傳送的記錄會增加5ms的延遲。

型別：long
預設值：0
有效值：[0,...]
重要性：中等

 

 

max.block.ms
該配置控制KafkaProducer的send()、partitionsFor()、initTransactions()、sendOffsetsToTransaction()、commitTransaction()和abortTransaction()方法阻塞的時間。對於send()來說，這個超時限制了等待後設資料獲取和緩衝區分配的總時間（使用者提供的序列器或分割槽器中的阻塞不計入這個超時）。對於partitionsFor()來說，如果後設資料不可用，這個超時就會限制等待後設資料的時間。與事務相關的方法總是阻塞，但如果事務協調器不能被發現或沒有在超時內響應，則可能超時。

型別：long
預設：60000（1分鐘)
有效值：[0，...]
重要性：中等

  

 

max.request.size
請求的最大大小，單位是位元組。這個設定將限制製作者在一次請求中傳送的記錄批次數量，以避免傳送巨大的請求。這實際上也是對未壓縮的最大記錄批次大小的一個上限。請注意，伺服器有自己的記錄批量大小的上限（如果啟用了壓縮，則在壓縮後），可能與此不同。

型別：int
預設值：1048576
有效值：[0，...]
重要性：中等

  

 

partitioner.class
Partitioner類，實現了org.apache.kafka.client.producer.Partitioner介面。

型別：class
預設值：org.apache.kafka.client.producer.internals.DefaultPartitioner。
有效值:
重要性：中等

  

 

receive.buffer.bytes
讀取資料時要使用的TCP接收緩衝區(SO_RCVBUF)的大小。如果該值為-1，則使用OS預設值。

型別：int
預設值：32768（32 kibibytes）
有效值：[-1,...]
重要性：中等

  

 

request.timeout.ms
該配置控制客戶端等待請求響應的最長時間。如果在超時之前沒有收到響應，客戶端將在必要時重新傳送請求，或者在重試次數用盡時失敗請求。這個值應該大於 replica.lag.time.max.ms（一種broker配置），以減少由於不必要的生產者重試而導致訊息重複的可能性。

型別：int
預設：30000（30秒)
有效值：[0，...]
重要性：中等

 

 

sasl.client.callback.handler.class
實現AuthenticateCallbackHandler介面的SASL客戶端回撥處理程式類的全稱。

型別：class
預設值: null
有效值:
重要性：中等

  

 

sasl.jaas.config
JAAS登入上下文引數，用於SASL連線，格式為JAAS配置檔案使用的格式。JAAS配置檔案的格式在這裡有介紹。值的格式為：'loginModuleClass controlFlag (optionName=optionValue)*;'。對於broker來說，配置必須以監聽器字首和SASL機制名稱為字首，並以小寫字母表示。例如，listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.exam.ScramLoginModule必填。

型別：password
預設值: null
有效值。
重要性：中等

 

 

sasl.kerberos.service.name
Kafka 執行的 Kerberos 主體名稱。這可以在Kafka的JAAS配置或Kafka的配置中定義。

型別：string
預設值: null
有效值。
重要性：中等

 

 

sasl.login.callback.handler.class
實現AuthenticateCallbackHandler介面的SASL登入回撥處理程式類的完全限定名稱。對於broker來說，登入回撥處理程式配置必須以監聽器字首和小寫的SASL機制名稱為字首。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler。

型別：class
預設值: null
有效值。
重要性：中等

  

sasl.login.class
實現Login介面的類的全稱。對於broker來說，login config必須以監聽器字首和SASL機制名稱為字首，並使用小寫。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin。

型別：class
預設值: null
有效值。
重要性：中等

 

 

 

sasl.mechanism
用於客戶端連線的SASL機制。這可以是任何有安全提供者的機制。GSSAPI是預設機制。

型別：string
預設值。 GSSAPI
有效值。
重要性：中等

 

 

security.protocol
用於與broker通訊的協議。有效值是： PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.

型別：string
預設值。 PLAINTEXT
有效值。
重要性：中等

 

 

send.buffer.bytes
傳送資料時要使用的TCP傳送緩衝區(SO_SNDBUF)的大小。如果該值為-1，則使用OS預設值。

型別：int
預設值：131072 (128 kibibytes)
有效值：[-1,...]
重要性：中等

 

 

socket.connection.setup.timeout.max.ms
客戶端等待建立套接字連線的最大時間。連線設定超時時間將隨著每一次連續的連線失敗而成倍增加，直到這個最大值。為了避免連線風暴，超時時間將被應用於0.2的隨機係數，結果是低於計算值20%到高於計算值20%的隨機範圍。

型別：long
預設：127000（127秒)
有效值:
重要性：中等

 

 

socket.connection.setup.timeout.ms
客戶端等待socket連線建立的時間。如果在超時之前沒有建立連線，客戶端將關閉socket通道。

型別：long
預設：10000（10秒)
有效值。
重要性：中等

 

ssl.enabled.protocols
為SSL連線啟用的協議列表。預設值是 "TLSv1.2,TLSv1.3"，當執行Java 11或更新版本時，否則為 "TLSv1.2"。在Java 11的預設值下，如果客戶端和伺服器都支援TLSv1.3，則會優先選擇TLSv1.3，否則會回退到TLSv1.2（假設兩者都至少支援TLSv1.2）。這個預設值在大多數情況下應該是沒有問題的。也可以參考`ssl.protocol`的配置文件。

型別：list
預設值: TLSv1.2
有效值。
重要性：中等

 

 

 

ssl.keystore.type
金鑰儲存檔案的檔案格式。對客戶端來說是可選的。

型別：string
預設值。 JKS
有效值。
重要性：中等

 

 

ssl.protocol
用來生成SSLContext的SSL協議，預設為'TLSv1.3'，否則為'TLSv1.2'。當執行Java 11或更新版本時，預設為'TLSv1.3'，否則為'TLSv1.2'。這個值對於大多數的使用情況來說應該是沒有問題的。在最近的JVM中允許的值是'TLSv1.2'和'TLSv1.3'。TLS'，'TLSv1.1'，'SSL'，'SSLv2'和'SSLv3'在舊的JVM中可能會被支援，但由於已知的安全漏洞，我們不鼓勵使用它們。在這個配置和'ssl.enabled.protocols'的預設值下，如果伺服器不支援'TLSv1.3'，客戶端將降級為'TLSv1.2'。如果這個配置被設定為'TLSv1.2'，即使是ssl.enabled.protocols中的一個值，並且伺服器只支援'TLSv1.3'，客戶端也不會使用'TLSv1.3'。

型別：string
預設值: TLSv1.2
有效值。
重要性：中等

 

 

ssl.provider
用於SSL連線的安全提供者的名稱。預設值是JVM的預設安全提供者。

型別：string
預設值: null
有效值。
重要性：中等

  

 

ssl.truststore.type
信任儲存檔案的檔案格式。

型別：string
預設值。 JKS
有效值。
重要性：中等

 

 

enable.idempotence
當設定為'true'時，生產者將確保每條訊息的副本正好寫在流中。如果為'false'，生產者因broker故障等原因重試，可能會將重試的訊息重複寫入流中。注意，啟用idempotence需要max.in.flight.request.per.connection小於或等於5，重試大於0，acks必須是'all'。如果使用者沒有明確設定這些值，將選擇合適的值。如果設定了不相容的值，將丟擲一個ConfigException。

型別：boolean
預設：假
有效值。
重要性：低

 

 

interceptor.classes
作為攔截器使用的類的列表。實現org.apache.kafka.clients.producer.ProducerInterceptor介面，可以讓你在記錄釋出到Kafka叢集之前，攔截（並可能突變）生產者收到的記錄。預設情況下，沒有攔截器。

型別：list
預設：""
有效值：非空字串
重要性：低

 

max.in.flight.requests.per.connection
客戶端在阻斷之前在單個連線上傳送的未確認請求的最大數量。請注意，如果此設定大於1，並且傳送失敗，則有可能因重試而重新排序訊息（即，如果啟用了重試）。

型別：int
預設值：5
有效值：[1,...]
重要性：低

 

 

metadata.max.age.ms
即使我們沒有看到任何分割槽領導權變化，我們也會強制重新整理後設資料，以主動發現任何新的broker或分割槽的時間，以毫秒為單位。

型別：長
預設：300000（5分鐘)
有效值：[0，...]
重要性：低

 

 

 

metadata.max.idle.ms
控制生產者為空閒的主題快取後設資料的時間。如果一個主題最後一次被生產出來後的時間超過了後設資料的空閒時間，那麼這個主題的後設資料就會被遺忘，下一次訪問它時將強制執行後設資料獲取請求。

型別：長
預設：300000（5分鐘)
有效值：[5000，...]
重要性：低

 

 

 

metric.reporters
作為度量報告器使用的類的列表。實現org.apache.kafka.common.metrics.MetricsReporter介面允許插入將被通知新的度量建立的類。JmxReporter總是被包含在註冊JMX統計資料中。

型別：list
預設：""
有效值：非空字串
重要性：低

 

metrics.num.samples
為計算指標而維護的樣本數量。

型別：int
預設值：2
有效值：[1,...]
重要性：低

 

 

 

metrics.recording.level
指標的最高記錄級別。

型別：string
預設：INFO
有效值：[INFO, DEBUG, TRACE]
重要性：低

 

 

 

metrics.sample.window.ms
度量樣本計算的時間視窗。

型別：長
預設：30000（30秒)
有效值：[0，...]
重要性：低

 

 

reconnect.backoff.max.ms
當重新連線到一個反覆連線失敗的broker時，等待的最大時間，以毫秒為單位。如果提供，每臺主機的backoff將在每一次連續連線失敗時以指數形式增加，直到這個最大值。在計算背離增加後，20%的隨機抖動被新增到避免連線風暴中。

型別：長
預設：1000（1秒)
有效值：[0，...]
重要性：低

 

 

reconnect.backoff.ms
試圖重新連線到給定主機前的基本等待時間。這可以避免在一個緊密的迴圈中重複連線到主機。這個backoff適用於客戶端到broker的所有連線嘗試。

型別：long
預設值：50
有效值：[0，...]
重要性：低

 

 

retry.backoff.ms
試圖重試給定主題分割槽的失敗請求前的等待時間。這可以避免在某些失敗情況下，在一個緊密的迴圈中重複傳送請求。

型別：long
預設值：100
有效值：[0，...]
重要性：低

 

 

sasl.kerberos.kinit.cmd
Kerberos kinit 命令路徑。

型別：string
預設值:/usr/bin/kinit
有效值:
重要性：低

 

 

sasl.kerberos.min.time.before.relogin
登入執行緒重新整理嘗試之間的睡眠時間。

型別：long
預設值：60000
有效值。
重要性：低

  

 

sasl.kerberos.ticket.renew.jitter
隨機抖動加到續航時間的百分比。

型別：double
預設值：0.05
有效值。
重要性：低

  

 

sasl.kerberos.ticket.renew.window.factor
登入執行緒將休眠，直到達到從上次重新整理到票據到期的指定時間視窗係數，這時它將嘗試更新票據。

型別：double
預設值：0.8
有效值。
重要性：低

  

 

sasl.login.refresh.buffer.seconds
重新整理憑證時，在憑證到期前要保持的緩衝時間，以秒為單位。如果重新整理的時間離到期時間比緩衝秒數更近，那麼重新整理時間將被提前，以儘可能多地保持緩衝時間。法定值在0到3600（1小時）之間；如果沒有指定值，則使用預設值300（5分鐘）。如果該值和sasl.login.refresh.min.period.seconds的總和超過了憑證的剩餘壽命，則該值和sasl.login.refresh.min.period.seconds都會被忽略。目前只適用於OAUTHBEARER。

型別：short
預設值：300
有效值：[0,...,3600]
重要性：低

  

 

sasl.login.refresh.min.period.seconds
登入重新整理執行緒在重新整理憑證前需要等待的最短時間，以秒為單位。合法值在0到900（15分鐘）之間；如果沒有指定值，則使用預設值60（1分鐘）。如果這個值和sasl.login.refresh.buffer.seconds的總和超過了一個憑證的剩餘壽命，那麼這個值和sasl.login.buffer.seconds都會被忽略。目前只適用於OAUTHBEARER。

型別：short
預設值：60
有效值： [0,...,900]
重要性：低

 

 

sasl.login.refresh.window.factor
登入重新整理執行緒將休眠，直到達到相對於憑證壽命的指定視窗係數，此時將嘗試重新整理憑證。合法值在0.5(50%)到1.0(100%)之間，如果沒有指定值，則使用預設值0.8(80%)。目前僅適用於OAUTHBEARER。

型別：double
預設值：0.8
有效值： [0.5,...,1.0]
重要性：低

  

 

sasl.login.refresh.window.jitter
相對於憑證的壽命，加到登入重新整理執行緒的睡眠時間的最大隨機抖動量。合法值在0到0.25（25%）之間，如果沒有指定值，則使用預設值0.05（5%）。目前只適用於OAUTHBEARER。

型別：double
預設值：0.05
有效值：[0.0,...,0.25]
重要性：低

 

 

security.providers
一個可配置的建立者類的列表，每個類都返回一個實現安全演算法的提供者。這些類應該實現org.apache.kafka.common.security.ah.SecurityProviderCreator介面。

型別：string
預設值: null
有效值。
重要性：低

 

 

ssl.cipher.suites
密碼套件的列表。這是一個命名的認證、加密、MAC和金鑰交換演算法的組合，用於使用TLS或SSL網路協議協商網路連線的安全設定。預設情況下，支援所有可用的密碼套件。

型別：list
預設值: null
有效值。
重要性：低

  

 

ssl.endpoint.identification.algorithm
使用伺服器證照驗證伺服器主機名的端點識別演算法。

型別：string
預設：https
有效值。
重要性：低

 

 

ssl.engine.factory.class
org.apache.kafka.common.security.auth.SslEngineFactory型別的類來提供SSLEngine物件。預設值是org.apache.kafka.common.security.ssl.DefaultSslEngineFactory。

型別：class
預設值: null
有效值。
重要性：低

 

 

ssl.keymanager.algorithm
鑰匙管理器工廠用於SSL連線的演算法，預設值是為Java虛擬機器配置的鑰匙管理器工廠演算法。預設值是為Java虛擬機器配置的金鑰管理器工廠演算法。

型別：string
預設值。 SunX509
有效值。
重要性：低

 

 

ssl.secure.random.implementation
用於SSL加密操作的SecureRandom PRNG實現。

型別：string
預設值: null
有效值。
重要性：低

 

 

ssl.trustmanager.algorithm
信任管理器工廠用於SSL連線的演算法。預設值是為Java虛擬機器配置的信任管理器工廠演算法。

型別：string
預設值。 PKIX
有效值。
重要性：低

 

 

transaction.timeout.ms
事務協調器在主動中止正在進行的事務之前，等待生產者的事務狀態更新的最大時間，單位為ms。如果這個值大於broker中的transaction.max.timeout.ms設定，請求將以InvalidTxnTimeoutException錯誤失敗。

型別：int
預設：60000（1分鐘)
有效值。
重要性：低

 

 

transactional.id
用於事務交付的TransactionalId。這可以實現跨越多個生產者會話的可靠性語義，因為它允許客戶端保證使用相同TransactionalId的事務在開始任何新事務之前已經完成。如果沒有提供TransactionalId，那麼生產者只能進行冪等交付。如果配置了TransactionalId，則會隱含enable.idempotence。預設情況下，TransactionId沒有配置，這意味著不能使用事務。請注意，預設情況下，事務需要至少三個broker的叢集，這是生產中的推薦設定；對於開發，你可以改變這一點，通過調整broker設定transaction.state.log.replication.factor。

型別：string
預設值: null
有效值：非空字串
重要性：低

 

3.4 消費者配置

下面是消費者的配置：

 

 

key.deserializer
實現org.apache.kafka.common.serialization.Deserializer介面的key的Deserializer類。

型別：class
預設值。
有效值。
重要性：高

 

 

value.deserializer
實現 org.apache.kafka.common.serialization.Deserializer 介面的值的 Deserializer 類。

型別：class
預設值。
有效值。
重要性：高

 

 

bootstrap.servers
用於建立Kafka叢集初始連線的主機/埠對的列表。客戶端將使用所有的伺服器，不管這裡指定了哪些伺服器用於引導--這個列表隻影響用於發現全部伺服器集的初始主機。這個列表的形式應該是 host1:port1,host2:port2,....。因為這些伺服器只是用於初始連線，以發現完整的叢集成員（可能會動態變化），所以這個列表不需要包含完整的伺服器集（不過，你可能需要多個伺服器，以防某個伺服器當機）。

型別：list
預設：""
有效值：非空字串
重要性：高

  

 

fetch.min.bytes
伺服器對一個取數請求應返回的最小資料量。如果沒有足夠的資料，請求將等待積累這麼多資料後再回復請求。預設設定為1個位元組，意味著只要有一個位元組的資料可用，取回請求就會被響應，或者取回請求超時等待資料到達。將其設定為大於1會導致伺服器等待更多的資料積累，這可以提高伺服器的吞吐量，但代價是一些額外的延遲。

型別：int
預設值：1
有效值：[0,...]
重要性：高

 

 

group.id
一個唯一的字串，用於標識此消費者所屬的消費者組。如果消費者通過使用 subscribe(topic) 或基於 Kafka 的偏移管理策略使用組管理功能，則需要此屬性。

型別：string
預設值: null
有效值。
重要性：高

 

 

heartbeat.interval.ms
使用Kafka的群組管理設施時，消費者協調人的預期心跳間隔時間。心跳用於確保消費者的會話保持活躍，並在新消費者加入或離開組時方便重新平衡。該值必須設定為低於session.timeout.ms，但通常不應設定為高於該值的1/3。它可以調整得更低，以控制正常重新平衡的預期時間。

型別：int
預設：3000（3秒)
有效值。
重要性：高

 

 

max.partition.fetch.bytes
伺服器將返回的每個分割槽的最大資料量。消費者會分批取回記錄。如果取回的第一個非空分割槽中的第一個記錄批次大於此限制，則仍將返回該批次，以確保消費者能夠取得進展。broker接受的最大記錄批次大小通過 message.max.bytes（broker 配置）或 max.message.bytes（topic 配置）來定義。請參閱 fetch.max.bytes 來限制消費者請求的大小。

型別：int
預設值：1048576(1 mebibyte)
有效值：[0，...]
重要性：高

 

 

session.timeout.ms
當使用Kafka的組管理設施時，用於檢測客戶端故障的超時。客戶端會定期傳送心跳來向broker表示其活躍度。如果在該會話超時結束前，broker沒有收到心跳，那麼broker將從組中刪除該客戶端，並啟動重新平衡。請注意，該值必須在broker配置中通過 group.min.session.timeout.ms 和 group.max.session.timeout.ms 配置的允許範圍內。

型別：int
預設：10000（10秒)
有效值。
重要性：高

 

 

ssl.key.password
金鑰儲存檔案中私鑰的密碼，或在`ssl.keystore.key'中指定的PEM金鑰。只有在配置了雙向身份驗證的情況下，客戶端才需要這個密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

 

ssl.keystore.certificate.chain
證照鏈的格式由'ssl.keystore.type'指定。預設的SSL引擎工廠只支援PEM格式的X.509證照列表。

型別：password
預設值: null
有效值。
重要性：高

 

 

ssl.keystore.key
私鑰的格式由'ssl.keystore.type'指定。預設SSL引擎工廠只支援PEM格式的PKCS#8金鑰。如果金鑰是加密的，必須使用'ssl.key.password'指定金鑰密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

ssl.keystore.location
金鑰儲存檔案的位置。對客戶端來說是可選的，可以用於客戶端的雙向認證。

型別：字串
預設值: null
有效值。
重要性：高

 

 

 

ssl.keystore.password
金鑰儲存檔案的儲存密碼。這對客戶端來說是可選的，只有在配置了'ssl.keystore.location'時才需要。對於PEM格式，不支援金鑰儲存密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

ssl.truststore.certificate
可信證照的格式由'ssl.truststore.type'指定。預設SSL引擎工廠只支援PEM格式的X.509證照。

型別：password
預設值: null
有效值。
重要性：高

 

 

ssl.truststore.location
信任儲存檔案的位置。

型別：字串
預設值: null
有效值。
重要性：高

 

 

ssl.truststore.password
信任儲存檔案的密碼。如果沒有設定密碼，則仍然使用配置的信任儲存檔案，但完整性檢查被禁用。PEM格式不支援信任儲存密碼。

型別：password
預設值: null
有效值。
重要性：高

 

allow.auto.create.topics
當訂閱或分配一個主題時，允許在broker上自動建立主題。只有當broker使用`auto.create.topic.enable`broker配置允許時，才會自動建立被訂閱的主題。當使用老於0.11.0的broker時，此配置必須設定為 "false"。

型別：布林值
預設：true
有效值。
重要性：中等

 

 

 

auto.offset.reset
當Kafka中沒有初始偏移量或者當前偏移量在伺服器上不存在了（比如因為該資料已經被刪除），該怎麼辦。

最早：自動將偏移量重置為最早的偏移量。
latest：自動將偏移量重置為最新的偏移量。
none：如果消費者的組沒有找到以前的偏移量，則向消費者丟擲異常。
其他任何東西：向消費者丟擲異常。
型別：字串
預設：latest
有效值：[latest, earliest, none]
重要性：中等

  

 

client.dns.lookup
控制客戶端如何使用DNS查詢。如果設定為use_all_dns_ips，則依次連線到每個返回的IP地址，直到成功建立連線。斷開連線後，會使用下一個IP。一旦所有的IP都被使用過一次，客戶端就會再次解析主機名中的IP（然而，JVM和作業系統都會快取DNS名稱查詢）。如果設定為resolve_canonical_bootstrap_servers_only，則將每個引導地址解析成一個canonical名稱列表。在引導階段之後，這和use_all_dns_ips的行為是一樣的。如果設定為預設（已廢棄），即使查詢返回多個IP地址，也會嘗試連線到查詢返回的第一個IP地址。

型別：字串
預設值: use_all_dns_ips
有效值。 [default, use_all_dns_ips, resolve_canonical_bootstrap_servers_only] 。
重要性：中等

  

 

connections.max.idle.ms
在該配置指定的毫秒數之後關閉空閒連線。

型別：long
預設：540000（9分鐘）
有效值。
重要性：中等

  

 

default.api.timeout.ms
指定客戶端API的超時時間（以毫秒為單位）。此配置被用作所有未指定超時引數的客戶端操作的預設超時。

型別：int
預設：60000（1分鐘)
有效值：[0，...]
重要性：中等

  

 

enable.auto.commit
如果為真，消費者的偏移量將在後臺定期提交。

型別：布林值
預設：true
有效值。
重要性：中等

 

 

exclude.internal.topics
是否應將與訂閱模式相匹配的內部主題從訂閱中排除。總是可以明確地訂閱一個內部主題。

型別：布林值
預設：true
有效值。
重要性：中等

  

 

fetch.max.bytes
伺服器對於一個取數請求應該返回的最大資料量。消費者會分批取回記錄，如果取回的第一個非空分割槽中的第一個記錄批次大於這個值，則仍會返回該記錄批次，以保證消費者能夠取得進展。因此，這不是一個絕對的最大值。broker接受的最大記錄批次大小是通過message.max.bytes（broker配置）或max.message.bytes（topic配置）來定義的。請注意，消費者會並行執行多個獲取。

型別：int
預設值：52428800（50 mebibytes）。
有效值：[0，...]
重要性：中等

 

 

group.instance.id
終端使用者提供的消費者例項的唯一識別符號。只允許使用非空字串。如果設定，消費者將被視為靜態成員，這意味著在任何時候，消費者組中只允許有一個具有此ID的例項。這可以與較大的會話超時結合使用，以避免因短暫的不可用性（如程式重啟）而引起的組重新平衡。如果不設定，消費者將作為動態成員加入組，這是傳統行為。

型別：字串
預設值: null
有效值。
重要性：中等

 

 

isolation.level
控制如何讀取以事務方式寫入的訊息。如果設定為read_committed，consumer.poll()將只返回已經提交的事務性訊息。如果設定為read_uncommitted（預設值），consumer.poll()將返回所有訊息，甚至是已經中止的事務性訊息。非事務性訊息在任何一種模式下都會無條件返回。

訊息總是按偏移量順序返回。因此，在read_committed模式下，consumer.poll()將只返回直到最後一個穩定偏移量（LSO）的訊息，也就是比第一個開啟的事務的偏移量小的那個。特別是在屬於正在進行的事務的訊息之後出現的任何訊息將被扣留，直到相關事務完成。因此，當存在飛行中的事務時，read_committed消費者將無法讀到高水印。

此外，當處於read_committed時，seekToEnd方法將返回LSO的

型別：字串
預設值：read_uncommitted
有效值：[read_committed, read_uncommitted]。 [read_committed, read_uncommitted]
重要性：中等

  

 

max.poll.interval.ms
使用消費者組管理時，poll()呼叫之間的最大延遲。這對消費者在獲取更多記錄之前可以閒置的時間設定了一個上限。如果poll()在這個超時時間到期前沒有被呼叫，那麼消費者被認為失敗，組將重新平衡，以便將分割槽重新分配給另一個成員。對於使用非空的group.instance.id的消費者，如果達到這個超時，分割槽將不會立即被重新分配。相反，消費者將停止傳送心跳，分割槽將在 session.timeout.ms 過期後重新分配。這反映了已關閉的靜態消費者的行為。

型別：int
預設：300000（5分鐘)
有效值：[1，...]
重要性：中等

 

 

max.poll.records
單次呼叫poll()時返回的最大記錄數。

型別：int
預設值：500
有效值：[1，...]
重要性：中等

 

 

partition.assignment.strategy
支援的分割槽分配策略的類名或類型別列表，按偏好排序，當使用分組管理時，客戶端將使用這些策略在消費者例項之間分配分割槽所有權。

除了下面指定的預設類之外，您還可以使用org.apache.kafka.clients.consumer.RoundRobinAssignorclass對消費者進行分割槽的迴圈分配。

實現org.apache.kafka.clients.consumer.ConsumerPartitionAssignor介面可以讓你插入一個自定義的分配策略。

型別：list
預設值：class org.apache.kafka.client.consumer.RangeAssignor。
有效值：非空字串
重要性：中等

 

receive.buffer.bytes
讀取資料時要使用的TCP接收緩衝區(SO_RCVBUF)的大小。如果該值為-1，則使用OS預設值。

型別：int
預設值：65536（64 kibibytes)
有效值：[-1,...]
重要性：中等

 

 

request.timeout.ms
該配置控制客戶端等待請求響應的最長時間。如果在超時之前沒有收到響應，客戶端將在必要時重新傳送請求，或者在重試次數耗盡時失敗。

型別：int
預設：30000（30秒)
有效值：[0，...]
重要性：中等

 

 

 

sasl.client.callback.handler.class
實現AuthenticateCallbackHandler介面的SASL客戶端回撥處理程式類的全稱。

型別：class
預設值: null
有效值。
重要性：中等

 

 

sasl.jaas.config
JAAS登入上下文引數，用於SASL連線，格式為JAAS配置檔案使用的格式。JAAS配置檔案的格式在這裡有介紹。值的格式為：'loginModuleClass controlFlag (optionName=optionValue)*;'。對於broker來說，配置必須以監聽器字首和SASL機制名稱為字首，並以小寫字母表示。例如，listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.exam.ScramLoginModule必填。

型別：password
預設值: null
有效值。
重要性：中等

 

 

sasl.kerberos.service.name
Kafka 執行的 Kerberos 主體名稱。這可以在Kafka的JAAS配置或Kafka的配置中定義。

型別：string
預設值: null
有效值。
重要性：中等

 

sasl.login.callback.handler.class
實現AuthenticateCallbackHandler介面的SASL登入回撥處理程式類的完全限定名稱。對於broker來說，登入回撥處理程式配置必須以監聽器字首和小寫的SASL機制名稱為字首。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler。

型別：class
預設值: null
有效值。
重要性：中等

 

 

 

sasl.login.class
實現Login介面的類的全稱。對於broker來說，login config必須以監聽器字首和SASL機制名稱為字首，並使用小寫。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin。

型別：類
預設值: null
有效值。
重要性：中等

  

 

sasl.mechanism
用於客戶端連線的SASL機制。這可以是任何有安全提供者的機制。GSSAPI是預設機制。

型別：string
預設值。 GSSAPI
有效值。
重要性：中等

 

 

security.protocol
用於與broker通訊的協議。有效值是： PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.

型別：string
預設值。 PLAINTEXT
有效值。
重要性：中等

 

send.buffer.bytes
傳送資料時要使用的TCP傳送緩衝區(SO_SNDBUF)的大小。如果該值為-1，則使用OS預設值。

型別：int
預設值：131072 (128 kibibytes)
有效值：[-1,...]
重要性：中等

 

 

socket.connection.setup.timeout.max.ms
客戶端等待建立套接字連線的最大時間。連線設定超時時間將隨著每一次連續的連線失敗而成倍增加，直到這個最大值。為了避免連線風暴，超時時間將被應用於0.2的隨機係數，結果是低於計算值20%到高於計算值20%的隨機範圍。

型別：long
預設：127000（127秒)
有效值。
重要性：中等

 

 

 

socket.connection.setup.timeout.ms
客戶端等待socket連線建立的時間。如果在超時之前沒有建立連線，客戶端將關閉socket通道。

型別：long
預設：10000（10秒)
有效值。
重要性：中等

 

ssl.enabled.protocols
為SSL連線啟用的協議列表。預設值是 "TLSv1.2,TLSv1.3"，當執行Java 11或更新版本時，否則為 "TLSv1.2"。在Java 11的預設值下，如果客戶端和伺服器都支援TLSv1.3，則會優先選擇TLSv1.3，否則會回退到TLSv1.2（假設兩者都至少支援TLSv1.2）。這個預設值在大多數情況下應該是沒有問題的。也可以參考`ssl.protocol`的配置文件。

型別：list
預設值: TLSv1.2
有效值。
重要性：中等

 

 

 

 

ssl.keystore.type
金鑰儲存檔案的檔案格式。對客戶端來說是可選的。

型別：string
預設值。 JKS
有效值。
重要性：中等

 

 

ssl.protocol
用來生成SSLContext的SSL協議，預設為'TLSv1.3'，否則為'TLSv1.2'。當執行Java 11或更新版本時，預設為'TLSv1.3'，否則為'TLSv1.2'。這個值對於大多數的使用情況來說應該是沒有問題的。在最近的JVM中允許的值是'TLSv1.2'和'TLSv1.3'。TLS'，'TLSv1.1'，'SSL'，'SSLv2'和'SSLv3'在舊的JVM中可能會被支援，但由於已知的安全漏洞，我們不鼓勵使用它們。在這個配置和'ssl.enabled.protocols'的預設值下，如果伺服器不支援'TLSv1.3'，客戶端將降級為'TLSv1.2'。如果這個配置被設定為'TLSv1.2'，即使是ssl.enabled.protocols中的一個值，並且伺服器只支援'TLSv1.3'，客戶端也不會使用'TLSv1.3'。

型別：string
預設值: TLSv1.2
有效值。
重要性：中等

 

 

ssl.provider
用於SSL連線的安全提供者的名稱。預設值是JVM的預設安全提供者。

型別：string
預設值: null
有效值。
重要性：中等

 

 

 

ssl.truststore.type
信任儲存檔案的檔案格式。

型別：string
預設值。 JKS
有效值。
重要性：中等

 

 

auto.commit.interval.ms
如果 enable.auto.commit 設定為 true，消費者偏移量自動提交到 Kafka 的頻率，以毫秒為單位。

型別：int
預設：5000（5秒)
有效值：[0，...]
重要性：低

 

 

check.crcs
自動檢查所消耗記錄的CRC32。這確保了資訊沒有發生線上或磁碟上的損壞。這個檢查會增加一些開銷，所以在追求極致效能的情況下，可能會被禁用。

型別：布林值
預設：true
有效值。
重要性：低

 

 

client.id
一個ID字串，在發出請求時傳遞給伺服器。這樣做的目的是為了在伺服器端請求日誌中包含一個邏輯應用程式名稱，從而能夠跟蹤請求的來源，而不僅僅是ip/埠。

型別：字串
預設：""
有效值。
重要性：低

 

 

client.rack
該客戶端的機架識別符號。這可以是任何字串值，表示該客戶端的物理位置。它與broker配置'broker.rack'相對應。

型別：字串
預設：""
有效值。
重要性：低

 

 

fetch.max.wait.ms
如果沒有足夠的資料來立即滿足fetch.min.bytes給出的要求，伺服器在回覆fetch請求前會阻塞的最大時間。

型別：int
預設值：500
有效值：[0，...]
重要性：低

  

 

interceptor.classes
作為攔截器使用的類的列表。實現org.apache.kafka.clients.consumer.ConsumerInterceptor介面可以讓你攔截（並可能突變）消費者收到的記錄。預設情況下，沒有攔截器。

型別：列表
預設：""
有效值：非空字串
重要性：低

  

metadata.max.age.ms
即使我們沒有看到任何分割槽領導權變化，我們也會強制重新整理後設資料，以主動發現任何新的broker或分割槽的時間，以毫秒為單位。

型別：長
預設：300000（5分鐘)
有效值：[0，...]
重要性：低

  

 

metric.reporters
作為度量報告器使用的類的列表。實現org.apache.kafka.common.metrics.MetricsReporter介面允許插入將被通知新的度量建立的類。JmxReporter總是被包含在註冊JMX統計資料中。

型別：列表
預設：""
有效值：非空字串
重要性：低

  

 

metrics.num.samples
為計算指標而維護的樣本數量。

型別：int
預設值：2
有效值：[1,...]
重要性：低

 

 

metrics.recording.level
指標的最高記錄級別。

型別：字串
預設：INFO
有效值：[INFO, DEBUG, TRACE]
重要性：低

  

 

metrics.sample.window.ms
度量樣本計算的時間視窗。

型別：長
預設：30000（30秒)
有效值：[0，...]
重要性：低

 

 

reconnect.backoff.max.ms
當重新連線到一個反覆連線失敗的broker時，等待的最大時間，以毫秒為單位。如果提供，每臺主機的backoff將在每一次連續連線失敗時以指數形式增加，直到這個最大值。在計算背離增加後，20%的隨機抖動被新增到避免連線風暴中。

型別：長
預設：1000（1秒)
有效值：[0，...]
重要性：低

 

 

reconnect.backoff.ms
試圖重新連線到給定主機前的基本等待時間。這可以避免在一個緊密的迴圈中重複連線到主機。這個backoff適用於客戶端到broker的所有連線嘗試。

型別：長
預設值：50
有效值：[0，...]
重要性：低

  

 

retry.backoff.ms
試圖重試給定主題分割槽的失敗請求前的等待時間。這可以避免在某些失敗情況下，在一個緊密的迴圈中重複傳送請求。

型別：long
預設值：100
有效值：[0，...]
重要性：低

 

 

Sasl.kerberos.kinit.cmd
Kerberos kinit 命令路徑。

型別：字串
預設值。 /usr/bin/kinit
有效值。
重要性：低

 

 

sasl.kerberos.min.time.before.relogin
登入執行緒重新整理嘗試之間的睡眠時間。

型別：long
預設值：60000
有效值。
重要性：低

 

 

sasl.kerberos.ticket.review.jitter
隨機抖動加到續航時間的百分比。

型別：double
預設值：0.05
有效值。
重要性：低

 

 

sasl.kerberos.ticket.renew.window.factor
登入執行緒將休眠，直到達到從上次重新整理到票據到期的指定時間視窗係數，這時它將嘗試更新票據。

型別：double
預設值：0.8
有效值。
重要性：低

 

 

sasl.login.refresh.buffer.seconds
重新整理憑證時，在憑證到期前要保持的緩衝時間，以秒為單位。如果重新整理的時間離到期時間比緩衝秒數更近，那麼重新整理時間將被提前，以儘可能多地保持緩衝時間。法定值在0到3600（1小時）之間；如果沒有指定值，則使用預設值300（5分鐘）。如果該值和sasl.login.refresh.min.period.seconds的總和超過了憑證的剩餘壽命，則該值和sasl.login.refresh.min.period.seconds都會被忽略。目前只適用於OAUTHBEARER。

型別：short
預設值：300
有效值：[0,...,3600]
重要性：低

 

 

sasl.login.refresh.min.period.seconds
登入重新整理執行緒在重新整理憑證前需要等待的最短時間，以秒為單位。合法值在0到900（15分鐘）之間；如果沒有指定值，則使用預設值60（1分鐘）。如果這個值和sasl.login.refresh.buffer.seconds的總和超過了一個憑證的剩餘壽命，那麼這個值和sasl.login.buffer.seconds都會被忽略。目前只適用於OAUTHBEARER。

型別：short
預設值：60
有效值： [0,...,900]
重要性：低

 

 

sasl.login.refresh.window.factor
登入重新整理執行緒將休眠，直到達到相對於憑證壽命的指定視窗係數，此時將嘗試重新整理憑證。合法值在0.5(50%)到1.0(100%)之間，如果沒有指定值，則使用預設值0.8(80%)。目前僅適用於OAUTHBEARER。

型別：double
預設值：0.8
有效值：[0.5,...,1.0]
重要性：低

 

 

sasl.login.refresh.window.jitter
相對於憑證的壽命，加到登入重新整理執行緒的睡眠時間的最大隨機抖動量。合法值在0到0.25（25%）之間，如果沒有指定值，則使用預設值0.05（5%）。目前只適用於OAUTHBEARER。

型別：double
預設值：0.05
有效值： [0.0,...,0.25]
重要性：低

 

 

security.providers
一個可配置的建立者類的列表，每個類都返回一個實現安全演算法的提供者。這些類應該實現org.apache.kafka.common.security.ah.SecurityProviderCreator介面。

型別：字串
預設值: null
有效值。
重要性：低

  

ssl.cipher.suites
密碼套件的列表。這是一個命名的認證、加密、MAC和金鑰交換演算法的組合，用於使用TLS或SSL網路協議協商網路連線的安全設定。預設情況下，支援所有可用的密碼套件。

型別：列表
預設值: null
有效值。
重要性：低

 

 

 

ssl.endpoint.identification.algorithm
使用伺服器證照驗證伺服器主機名的端點識別演算法。

型別：字串
預設：https
有效值。
重要性：低

 

 

ssl.engine.factory.class
org.apache.kafka.common.security.auth.SslEngineFactory型別的類來提供SSLEngine物件。預設值是org.apache.kafka.common.security.ssl.DefaultSslEngineFactory。

型別：class
預設值: null
有效值。
重要性：低

 

 

ssl.keymanager.algorithm
鑰匙管理器工廠用於SSL連線的演算法，預設值是為Java虛擬機器配置的鑰匙管理器工廠演算法。預設值是為Java虛擬機器配置的金鑰管理器工廠演算法。

型別：字串
預設值。 SunX509
有效值。
重要性：低

 

 

ssl.secure.random.implementation
用於SSL加密操作的SecureRandom PRNG實現。

型別：字串
預設值: null
有效值。
重要性：低

 

 

ssl.trustmanager.algorithm
信任管理器工廠用於SSL連線的演算法。預設值是為Java虛擬機器配置的信任管理器工廠演算法。

型別：字串
預設值。 PKIX
有效值。
重要性：低

 

 

 

3.5 Kafka連線配置

 

下面是Kafka 連線框架的配置。

 

 

config.storage.topic
儲存聯結器配置的Kafka主題的名稱。

型別：字串
預設值。
有效值。
重要性：高

 

 

group.id
標識此 Worker 所屬的 Connect 群集組的唯一字串。

型別：字串
預設值。
有效值。
重要性：高

 

 

key.converter
轉換器類用於轉換Kafka Connect格式和寫入Kafka的序列化形式。這控制了向Kafka寫入或從Kafka讀取的訊息中鍵的格式，由於這與聯結器無關，所以允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。

型別：類
預設值。
有效值。
重要性：高

 

 

 

offset.storage.topic
儲存聯結器偏移量的Kafka主題的名稱。

型別：字串
預設值。
有效值。
重要性：高

 

 

status.storage.topic
儲存聯結器和任務狀態的Kafka主題的名稱。

型別：字串
預設值。
有效值。
重要性：高

 

 

value.converter
轉換器類用於轉換Kafka Connect格式和寫入Kafka的序列化形式。這控制了向Kafka寫入或從Kafka讀取的訊息中的值的格式，由於這與聯結器無關，所以允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。

型別：類
預設值。
有效值。
重要性：高

 

 

bootstrap.servers
用於建立Kafka叢集初始連線的主機/埠對的列表。客戶端將使用所有的伺服器，不管這裡指定了哪些伺服器用於引導--這個列表隻影響用於發現全部伺服器集的初始主機。這個列表的形式應該是 host1:port1,host2:port2,....。因為這些伺服器只是用於初始連線，以發現完整的叢集成員（可能會動態變化），所以這個列表不需要包含完整的伺服器集（不過，你可能需要多個伺服器，以防某個伺服器當機）。

型別：list
預設：localhost:9092
有效值。
重要性：高

 

 

heartbeat.interval.ms
使用Kafka的群組管理設施時，對群組協調人的預期心跳間隔時間。心跳用於確保工作者的會話保持活躍，並在新成員加入或離開組時便於重新平衡。該值必須設定為低於session.timeout.ms，但通常不應設定為高於該值的1/3。它可以調整得更低，以控制正常重新平衡的預期時間。

型別：int
預設：3000（3秒)
有效值。
重要性：高

 

 

rebalance.timeout.ms
重新平衡開始後，每個 Worker 加入組的最大允許時間。這基本上是對所有任務重新整理任何未決資料和提交偏移所需時間的限制。如果超過了超時時間，那麼該工作者將被從組中移除，這將導致偏移提交失敗。

型別：int
預設：60000（1分鐘)
有效值。
重要性：高

  

 

session.timeout.ms
用於檢測 Worker 故障的超時時間。Worker 會定期傳送心跳，以向 broker 顯示其活躍度。如果在該會話超時結束前，broker沒有收到心跳，那麼broker將從組中刪除該 Worker 並啟動重新平衡。請注意，該值必須在 broker 配置中通過 group.min.session.timeout.ms 和 group.max.session.timeout.ms 配置的允許範圍內。

型別：int
預設：10000（10秒)
有效值。
重要性：高

  

 

ssl.key.password
金鑰儲存檔案中私鑰的密碼，或在`ssl.keystore.key'中指定的PEM金鑰。只有在配置了雙向身份驗證的情況下，客戶端才需要這個密碼。

型別：password
預設值: null
有效值。
重要性：高

  

 

ssl.keystore.certificate.chain
證照鏈的格式由'ssl.keystore.type'指定。預設的SSL引擎工廠只支援PEM格式的X.509證照列表。

型別：password
預設值: null
有效值。
重要性：高

  

 

ssl.keystore.key
私鑰的格式由'ssl.keystore.type'指定。預設SSL引擎工廠只支援PEM格式的PKCS#8金鑰。如果金鑰是加密的，必須使用'ssl.key.password'指定金鑰密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

ssl.keystore.location
金鑰儲存檔案的位置。對客戶端來說是可選的，可以用於客戶端的雙向認證。

型別：字串
預設值: null
有效值。
重要性：高

  

 

ssl.keystore.password
金鑰儲存檔案的儲存密碼。這對客戶端來說是可選的，只有在配置了'ssl.keystore.location'時才需要。對於PEM格式，不支援金鑰儲存密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

ssl.truststore.certificate
可信證照的格式由'ssl.truststore.type'指定。預設SSL引擎工廠只支援PEM格式的X.509證照。

型別：password
預設值: null
有效值。
重要性：高

 

 

ssl.truststore.location
信任儲存檔案的位置。

型別：字串
預設值: null
有效值。
重要性：高

  

ssl.truststore.password
信任儲存檔案的密碼。如果沒有設定密碼，則仍然使用配置的信任儲存檔案，但完整性檢查被禁用。PEM格式不支援信任儲存密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

 

client.dns.lookup
控制客戶端如何使用DNS查詢。如果設定為use_all_dns_ips，則依次連線到每個返回的IP地址，直到成功建立連線。斷開連線後，會使用下一個IP。一旦所有的IP都被使用過一次，客戶端就會再次解析主機名中的IP（然而，JVM和作業系統都會快取DNS名稱查詢）。如果設定為resolve_canonical_bootstrap_servers_only，則將每個引導地址解析成一個canonical名稱列表。在引導階段之後，這和use_all_dns_ips的行為是一樣的。如果設定為預設（已廢棄），即使查詢返回多個IP地址，也會嘗試連線到查詢返回的第一個IP地址。

型別：字串
預設值: use_all_dns_ips
有效值。 [default, use_all_dns_ips, resolve_canonical_bootstrap_servers_only] 。
重要性：中等

 

 

connections.max.idle.ms
在該配置指定的毫秒數之後關閉空閒連線。

型別：long
預設：540000（9分鐘)
有效值。
重要性：中等

 

 

connector.client.config.override.policy
ConnectorClientConfigOverridePolicy的實現類名或別名。定義哪些客戶端配置可以被聯結器覆蓋。預設的實現是`None`。框架中其他可能的策略包括`全部`和`主要`。

型別：字串
預設值。 無
有效值。
重要性：中等

 

 

receive.buffer.bytes
讀取資料時使用的TCP接收緩衝區(SO_RCVBUF)的大小。如果該值為-1，則使用OS預設值。

型別：int
預設值：32768（32 kibibytes）
有效值：[0，...]
重要性：中等

 

request.timeout.ms
該配置控制客戶端等待請求響應的最長時間。如果在超時之前沒有收到響應，客戶端將在必要時重新傳送請求，或者在重試次數耗盡時失敗。

型別：int
預設：40000（40秒)
有效值：[0，...]
重要性：中等

 

 

 

sasl.client.callback.handler.class
實現AuthenticateCallbackHandler介面的SASL客戶端回撥處理程式類的全稱。

型別：類
預設值: null
有效值。
重要性：中等

 

 

sasl.jaas.config
JAAS登入上下文引數，用於SASL連線，格式為JAAS配置檔案使用的格式。JAAS配置檔案的格式在這裡有介紹。值的格式為：'loginModuleClass controlFlag (optionName=optionValue)*;'。對於broker來說，配置必須以監聽器字首和SASL機制名稱為字首，並以小寫字母表示。例如，listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.exam.ScramLoginModule必填。

型別：password
預設值: null
有效值。
重要性：中等

 

 

sasl.kerberos.service.name。
Kafka 執行的 Kerberos 主體名稱。這可以在Kafka的JAAS配置或Kafka的配置中定義。

型別：字串
預設值: null
有效值。
重要性：中等

 

 

sasl.login.callback.handler.class。
實現AuthenticateCallbackHandler介面的SASL登入回撥處理程式類的完全限定名稱。對於broker來說，登入回撥處理程式配置必須以監聽器字首和小寫的SASL機制名稱為字首。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler。

型別：類
預設值: null
有效值。
重要性：中等

  

 

sasl.login.class
實現Login介面的類的全稱。對於broker來說，login config必須以監聽器字首和SASL機制名稱為字首，並使用小寫。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin。

型別：類
預設值: null
有效值。
重要性：中等

 

 

sasl.mechanism
用於客戶端連線的SASL機制。這可以是任何有安全提供者的機制。GSSAPI是預設機制。

型別：字串
預設值。 GSSAPI
有效值。
重要性：中等

 

 

security.protocol
用於與broker通訊的協議。有效值是： PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.

型別：字串
預設值。 PLAINTEXT
有效值。
重要性：中等

 

 

send.buffer.bytes

傳送資料時要使用的TCP傳送緩衝區(SO_SNDBUF)的大小。如果該值為-1，則使用OS預設值。

型別：int
預設值：131072 (128 kibibytes)
有效值：[0，...]
重要性：中等

 

ssl.enabled.protocols
為SSL連線啟用的協議列表。預設值是 "TLSv1.2,TLSv1.3"，當執行Java 11或更新版本時，否則為 "TLSv1.2"。在Java 11的預設值下，如果客戶端和伺服器都支援TLSv1.3，則會優先選擇TLSv1.3，否則會回退到TLSv1.2（假設兩者都至少支援TLSv1.2）。這個預設值在大多數情況下應該是沒有問題的。也可以參考`ssl.protocol`的配置文件。

型別：列表
預設值: TLSv1.2
有效值。
重要性：中等

 

 

ssl.keystore.type
金鑰儲存檔案的檔案格式。對客戶端來說是可選的。

型別：字串
預設值。 JKS
有效值。
重要性：中等

 

 

 

 

ssl.protocol
用來生成SSLContext的SSL協議，預設為'TLSv1.3'，否則為'TLSv1.2'。當執行Java 11或更新版本時，預設為'TLSv1.3'，否則為'TLSv1.2'。這個值對於大多數的使用情況來說應該是沒有問題的。在最近的JVM中允許的值是'TLSv1.2'和'TLSv1.3'。TLS'，'TLSv1.1'，'SSL'，'SSLv2'和'SSLv3'在舊的JVM中可能會被支援，但由於已知的安全漏洞，我們不鼓勵使用它們。在這個配置和'ssl.enabled.protocols'的預設值下，如果伺服器不支援'TLSv1.3'，客戶端將降級為'TLSv1.2'。如果這個配置被設定為'TLSv1.2'，即使是ssl.enabled.protocols中的一個值，並且伺服器只支援'TLSv1.3'，客戶端也不會使用'TLSv1.3'。

型別：字串
預設值: TLSv1.2
有效值。
重要性：中等

 

 

ssl.provider
用於SSL連線的安全提供者的名稱。預設值是JVM的預設安全提供者。

型別：字串
預設值: null
有效值。
重要性：中等

 

 

ssl.truststore.type
信任儲存檔案的檔案格式。

型別：字串
預設值。 JKS
有效值。
重要性：中等

 

 

 

worker.sync.timeout.ms
當worker與其他worker不同步，需要重新同步配置時，最多等待這個時間，然後才會放棄，離開組，等待一個後退期再重新加入。

型別：int
預設：3000（3秒)
有效值。
重要性：中等

 

 

worker.unsync.backoff.ms
當worker與其他worker不同步，並且在worker.sync.timeout.ms內未能趕上時，在重新加入之前，要離開Connect叢集這麼長時間。

型別：int
預設：300000（5分鐘)
有效值。
重要性：中等

 

 

access.control.allow.methods
通過設定 Access-Control-Allow-Methods 標頭，設定支援跨源請求的方法。Access-Control-Allow-Methods頭的預設值允許GET、POST和HEAD的跨源請求。

型別：字串
預設：""
有效值。
重要性：低

 

 

access.control.allow.origin
為REST API請求設定Access-Control-Allow-Origin頭的值。要啟用跨源訪問，請將其設定為應允許訪問API的應用程式的域，或'*'允許從任何域訪問。預設值只允許從REST API的域進行訪問。

型別：字串
預設：""
有效值。
重要性：低

 

 

admin.listeners
管理REST API將監聽的以逗號分隔的URI列表。支援的協議是HTTP和HTTPS。一個空的或空白的字串將禁用此功能。預設行為是使用常規監聽器（由'listeners'屬性指定）。

型別：列表
預設值: null
有效值：org.apache.kafka.connect.runtime.WorkerConfig$AdminListenersValidator@7b1d7fff。
重要性：低

 

 

client.id
一個ID字串，在發出請求時傳遞給伺服器。這樣做的目的是為了在伺服器端請求日誌中包含一個邏輯應用程式名稱，從而能夠跟蹤請求的來源，而不僅僅是ip/埠。

型別：字串
預設：""
有效值。
重要性：低

  

 

config.providers
ConfigProvider類的逗號分隔的名稱，按照指定的順序載入和使用。通過實現介面ConfigProvider，您可以替換聯結器配置中的變數引用，例如對於外部化的祕密。

型別：列表
預設：""
有效值。
重要性：低

  

 

config.storage.replication.factor
建立配置儲存主題時使用的複製因子。

型別：short
預設值：3
有效值。 正數，不大於Kafka叢集中的broker數量，或-1使用broker的預設值。
重要性：低

  

 

connect.protocol
Kafka連線協議的相容性模式

型別：字串
預設值：sessioned
有效值： [eager, compatible, sessioned]
重要性：低

  

 

header.converter
HeaderConverter類用於在Kafka Connect格式和寫入Kafka的序列化形式之間進行轉換。這控制了向Kafka寫入或從Kafka讀取的訊息中頭值的格式，由於這與聯結器無關，所以允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。預設情況下，SimpleHeaderConverter用於將頭值序列化為字串，並通過推斷模式反序列化它們。

型別：類
預設值：org.apache.kafka.connect.storage.SimpleHeaderConverter。
有效值。
重要性：低

 

 

inter.worker.key.generation.algorithm
用於生成內部請求金鑰的演算法。

型別：字串
預設值：HmacSHA256
有效值。 workerJVM支援的任何KeyGenerator演算法。
重要性：低

  

 

inter.worker.key.size
用於簽署內部請求的金鑰大小，以位元為單位。如果為空，將使用金鑰生成演算法的預設金鑰大小。

型別：int，如果為空，則使用金鑰生成演算法的預設金鑰大小。
預設值: null
有效值。
重要性：低

 

inter.worker.key.ttl.ms
用於內部請求驗證的生成的會話金鑰的TTL（毫秒）。

型別：int
預設：3600000（1小時)
有效值： [0，...，2147483647]
重要性：低

 

 

 

inter.worker.signature.algorithm
用於簽署內部請求的演算法

型別：字串
預設值：HmacSHA256
有效值。 worker 所在機器JVM支援的任何MAC演算法。
重要性：低

  

 

inter.worker.verification.algorithms
核實內部請求的允許演算法清單。

型別：清單
預設值：HmacSHA256
有效值。 一個或多個MAC演算法的列表，每個演算法都由worker機器JVM支援。
重要性：低

 

internal.key.converter
轉換器類用於轉換Kafka Connect格式和寫入Kafka的序列化形式。這控制了向Kafka寫入或從Kafka讀取的訊息中鍵的格式，由於這與聯結器無關，所以允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。這個設定控制了框架使用的內部記賬資料的格式，如配置和偏移量，所以使用者通常可以使用任何功能的Converter實現。已廢棄；將在下一個版本中刪除。

型別：類
預設值：org.apache.kafka.connect.json.JsonConverter。
有效值。
重要性：低

 

 

 

internal.value.converter
轉換器類用於轉換Kafka Connect格式和寫入Kafka的序列化形式。這控制了向Kafka寫入或從Kafka讀取的訊息中的值的格式，由於這與聯結器無關，它允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。該設定控制框架使用的內部記賬資料的格式，如配置和偏移量，因此使用者通常可以使用任何功能的轉換器實現。已廢棄；將在下一個版本中刪除。

型別：類
預設值：org.apache.kafka.connect.json.JsonConverter。
有效值。
重要性：低

 

 

listeners
REST API將監聽的以逗號分隔的URI列表。支援的協議是HTTP和HTTPS。
指定hostname為0.0.0.0以繫結到所有介面。
將hostname留空以繫結到預設介面。
合法列表的例子。HTTP://myhost:8083,HTTPS://myhost:8084。

型別：清單
預設值: null
有效值。
重要性：低

 

metadata.max.age.ms
即使我們沒有看到任何分割槽領導權變化，我們也會強制重新整理後設資料，以主動發現任何新的broker或分割槽的時間，以毫秒為單位。

型別：long
預設：300000（5分鐘)
有效值：[0，...]
重要性：低

 

 

 

metric.reporters
作為度量報告器使用的類的列表。實現org.apache.kafka.common.metrics.MetricsReporter介面允許插入將被通知新的度量建立的類。JmxReporter總是被包含在註冊JMX統計資料中。

型別：列表
預設：""
有效值。
重要性：低

 

 

metrics.num.samples
為計算指標而維護的樣本數量。

型別：int
預設值：2
有效值：[1,...]
重要性：低

 

 

metrics.recording.level
指標的最高記錄級別。

型別：字串
預設：INFO
有效值： [INFO, DEBUG]
重要性：低

 

 

metrics.sample.window.ms
度量樣本計算的時間視窗。

型別：long
預設：30000（30秒)
有效值：[0，...]
重要性：低

 

offset.flush.interval.ms
嘗試提交任務的偏移量的時間間隔。

型別：long
預設：60000（1分鐘)
有效值。
重要性：低

 

  

 

offset.flush.timeout.ms
等待記錄重新整理和分割槽偏移資料提交到偏移儲存的最大毫秒數，然後取消程式並在未來嘗試中恢復要提交的偏移資料。

型別：long
預設：5000（5秒)
有效值。
重要性：低

 

 

offset.storage.partitions
建立偏移儲存主題時使用的分割槽數量。

型別：int
預設值：25
有效值：正數，或-1使用broker的預設值。
重要性：低

 

 

offset.storage.replication.factor
建立偏移儲存主題時使用的複製因子。

型別：short
預設值：3
有效值。 正數，不大於Kafka叢集中的broker數量，或-1使用broker的預設值。
重要性：低

 

 

plugin.path
由逗號(,)分隔的包含外掛(聯結器、轉換器、轉換)的路徑列表。該列表應該由頂級目錄組成，其中包括以下任意組合。
a) 緊接著包含有外掛和它們的依賴關係的罐子的目錄。
b) uber-jars與外掛和它們的依賴關係。
c) 緊接著包含外掛類及其依賴關係的包目錄結構的目錄。
注意：將遵循符號連結來發現依賴關係或外掛。
例如：plugin.path=/usr/local/share/java,/usr/local/share/kafka/plugins,/opt/connectors。
不要在此屬性中使用配置提供者變數，因為在初始化配置提供者並用於替換變數之前，worker的掃描器會使用原始路徑。

型別：列表
預設值: null
有效值。
重要性：低

 

 

reconnect.backoff.max.ms
當重新連線到一個反覆連線失敗的broker時，等待的最大時間，以毫秒為單位。如果提供，每臺主機的backoff將在每一次連續連線失敗時以指數形式增加，直到這個最大值。在計算背離增加後，20%的隨機抖動被新增到避免連線風暴中。

型別：long
預設：1000（1秒)
有效值：[0，...]
重要性：低

 

 

reconnect.backoff.ms
試圖重新連線到給定主機前的基本等待時間。這可以避免在一個緊密的迴圈中重複連線到主機。這個backoff適用於客戶端到broker的所有連線嘗試。

型別：long
預設值：50
有效值：[0，...]
重要性：低

 

 

 

response.http.headers.config
REST API HTTP響應頭的規則

型別：字串
預設：""
有效值。 逗號分隔的頁首規則，其中每個頁首規則的形式為"[行動][頁首名稱]:[頁首值]"，如果頁首規則的任何部分包含逗號，則可選擇用雙引號包圍。
重要性：低

 

 

rest.advertised.host.name
如果設定了這個，這就是將提供給其他worker連線的主機名。

型別：字串
預設值: null
有效值。
重要性：低

 

 

rest.advertised.listener
設定公告的監聽器（HTTP或HTTPS），該監聽器將提供給其他工作者使用。

型別：字串
預設值: null
有效值。
重要性：低

 

 

 

rest.advertised.port
如果設定了這個埠，這就是給其他worker連線的埠。

型別：int
預設值: null
有效值。
重要性：低

 

rest.extension.classes
ConnectRestExtension類的逗號分隔的名稱，按照指定的順序載入和呼叫。實現介面ConnectRestExtension允許您向Connect的REST API中注入使用者定義的資源，如過濾器。通常用於新增自定義能力，如日誌記錄、安全等。

型別：列表
預設：""
有效值。
重要性：低

 

 

 

rest.host.name
REST API的主機名。如果設定了這個，它將只繫結到這個介面。

型別：字串
預設值: null
有效值。
重要性：低

 

 

rest.port
REST API的監聽埠。

型別：int
預設值：8083
有效值。
重要性：低

 

 

retry.backoff.ms
試圖重試給定主題分割槽的失敗請求前的等待時間。這可以避免在某些失敗情況下，在一個緊密的迴圈中重複傳送請求。

型別：long
預設值：100
有效值：[0，...]
重要性：低

 

 

sasl.kerberos.kinit.cmd
Kerberos kinit 命令路徑。

型別：字串
預設值。 /usr/bin/kinit
有效值。
重要性：低

  

 

sasl.kerberos.min.time.before.relogin
登入執行緒重新整理嘗試之間的睡眠時間。

型別：long
預設值：60000
有效值。
重要性：低

  

 

sasl.kerberos.ticket.renew.jitter
隨機抖動加到續航時間的百分比。

型別：double
預設值：0.05
有效值。
重要性：低

  

 

sasl.kerberos.ticket.renew.window.factor
登入執行緒將休眠，直到達到從上次重新整理到票據到期的指定時間視窗係數，這時它將嘗試更新票據。

型別：double
預設值：0.8
有效值。
重要性：低

  

 

sasl.login.refresh.buffer.seconds
重新整理憑證時，在憑證到期前要保持的緩衝時間，以秒為單位。如果重新整理的時間離到期時間比緩衝秒數更近，那麼重新整理時間將被提前，以儘可能多地保持緩衝時間。法定值在0到3600（1小時）之間；如果沒有指定值，則使用預設值300（5分鐘）。如果該值和sasl.login.refresh.min.period.seconds的總和超過了憑證的剩餘壽命，則該值和sasl.login.refresh.min.period.seconds都會被忽略。目前只適用於OAUTHBEARER。

型別：short
預設值：300
有效值：[0,...,3600]
重要性：低

 

 

sasl.login.refresh.min.period.seconds
登入重新整理執行緒在重新整理憑證前需要等待的最短時間，以秒為單位。合法值在0到900（15分鐘）之間；如果沒有指定值，則使用預設值60（1分鐘）。如果這個值和sasl.login.refresh.buffer.seconds的總和超過了一個憑證的剩餘壽命，那麼這個值和sasl.login.buffer.seconds都會被忽略。目前只適用於OAUTHBEARER。

型別：short
預設值：60
有效值：[0，...，900]
重要性：低

  

 

sasl.login.refresh.window.factor。
登入重新整理執行緒將休眠，直到達到相對於憑證壽命的指定視窗係數，此時將嘗試重新整理憑證。合法值在0.5(50%)到1.0(100%)之間，如果沒有指定值，則使用預設值0.8(80%)。目前僅適用於OAUTHBEARER。

型別：double
預設值：0.8
有效值：[0.5,...,1.0]
重要性：低

 

 

sasl.login.refresh.window.jitter
相對於憑證的壽命，加到登入重新整理執行緒的睡眠時間的最大隨機抖動量。合法值在0到0.25（25%）之間，如果沒有指定值，則使用預設值0.05（5%）。目前只適用於OAUTHBEARER。

型別：double
預設值：0.05
有效值：[0.0,...,0.25]
重要性：低

 

 

scheduled.rebalance.max.delay.ms
為了等待一個或多個離職worker返回，在重新平衡和重新分配他們的聯結器和任務到組之前所安排的最大延遲。在此期間，已離職worker的聯結器和任務仍未分配。

型別：int
預設：300000（5分鐘)
有效值： [0，...，2147483647]
重要性：低

  

 

socket.connection.setup.timeout.max.ms
客戶端等待建立套接字連線的最大時間。連線設定超時時間將隨著每一次連續的連線失敗而成倍增加，直到這個最大值。為了避免連線風暴，超時時間將被應用於0.2的隨機係數，結果是低於計算值20%到高於計算值20%的隨機範圍。

型別：long
預設：127000（127秒)
有效值：[0，...]
重要性：低

 

 

socket.connection.setup.timeout.ms
客戶端等待socket連線建立的時間。如果在超時之前沒有建立連線，客戶端將關閉socket通道。

型別：長
預設：10000（10秒)
有效值：[0，...]
重要性：低

 

 

ssl.cipher.suites
密碼套件的列表。這是一個命名的認證、加密、MAC和金鑰交換演算法的組合，用於使用TLS或SSL網路協議協商網路連線的安全設定。預設情況下，支援所有可用的密碼套件。

型別：列表
預設值: null
有效值。
重要性：低

 

 

ssl.client.auth
配置kafka broker請求客戶端認證。以下是常用的設定。

ssl.client.auth=required 如果設定為require，則客戶端認證是必須的。
ssl.client.auth=requested 這意味著客戶端認證是可選的，與required不同，如果設定了這個選項，客戶端可以選擇不提供自己的認證資訊。
ssl.client.auth=none 這表示不需要客戶端認證。
型別：字串
預設：無
有效值。
重要性：低

 

 

ssl.endpoint.identification.algorithm
使用伺服器證照驗證伺服器主機名的端點識別演算法。

型別：字串
預設：https
有效值。
重要性：低

 

 

ssl.engine.factory.class
org.apache.kafka.common.security.auth.SslEngineFactory型別的類來提供SSLEngine物件。預設值是org.apache.kafka.common.security.ssl.DefaultSslEngineFactory。

型別：類
預設值: null
有效值。
重要性：低

 

 

ssl.keymanager.algorithm
鑰匙管理器工廠用於SSL連線的演算法，預設值是為Java虛擬機器配置的鑰匙管理器worker程式演算法。預設值是為Java虛擬機器配置的金鑰管理器工廠演算法。

型別：字串
預設值。 SunX509
有效值。
重要性：低

 

 

ssl.secure.random.implementation
用於SSL加密操作的SecureRandom PRNG實現。

型別：字串
預設值: null
有效值。
重要性：低

 

 

ssl.trustmanager.algorithm
信任管理器工廠用於SSL連線的演算法。預設值是為Java虛擬機器配置的信任管理器工廠演算法。

型別：字串
預設值。 PKIX
有效值。
重要性：低

 

 

status.storage.partitions
建立狀態儲存主題時使用的分割槽數量。

型別：int
預設值：5
有效值：正數，或-1使用broker的預設值。
重要性：低

  

 

status.storage.replication.factor
建立狀態儲存主題時使用的複製因子。

型別：short
預設值：3
有效值。 正數，不大於Kafka叢集中的broker數量，或-1使用broker的預設值。
重要性：低

 

task.shutdown.graceful.timeout.ms
等待任務優雅關閉的時間。這是總的時間量，而不是每個任務。所有任務都被觸發關機，然後依次等待。

型別：long
預設：5000（5秒）
有效值。
重要性：低

 

 

 

topic.creation.enable
當源聯結器配置了`topic.create.`屬性時，是否允許自動建立源聯結器使用的主題。每個任務將使用管理客戶端來建立它的主題，而不是依賴Kafkabroker來自動建立主題。

型別：布林值
預設：true
有效值。
重要性：低

 

 

topic.tracking.allow.reset
如果設定為 "true"，它允許使用者請求重置每個聯結器的活動主題集。

型別：布林值
預設：true
有效值。
重要性：低

 

 

topic.tracking.enable
啟用在執行時跟蹤每個聯結器的活動主題集。

型別：布林值
預設：true
有效值。
重要性：低

 

 

3.5.1 源聯結器配置

下面是源聯結器的配置。

 

 

 

name
該聯結器的全域性唯一名稱。

型別：字串
預設值。
有效值：非空字串，不含ISO控制字元。
重要性：高

 

 

connector.class
該聯結器類的名稱或別名。必須是org.apache.kafka.connect.connector.Connector的子類。如果聯結器是org.apache.kafka.connect.file.FileStreamSinkConnector，你可以指定這個全名，或者使用 "FileStreamSink "或 "FileStreamSinkConnector "來使配置更短一些。

型別：字串
預設值。
有效值。
重要性：高

 

 

tasks.max
該聯結器可使用的最大任務數。

型別：int
預設值：1
有效值：[1,...]
重要性：高

 

 

 

key.converter
轉換器類用於轉換Kafka Connect格式和寫入Kafka的序列化形式。這控制了向Kafka寫入或從Kafka讀取的訊息中鍵的格式，由於這與聯結器無關，所以允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。

型別：類
預設值: null
有效值。
重要性：低

 

value.converter
轉換器類用於轉換Kafka Connect格式和寫入Kafka的序列化形式。這控制了向Kafka寫入或從Kafka讀取的訊息中的值的格式，由於這與聯結器無關，所以允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。

型別：類
預設值: null
有效值。
重要性：低

 

 

 

header.converter
HeaderConverter類用於在Kafka Connect格式和寫入Kafka的序列化形式之間進行轉換。這控制了向Kafka寫入或從Kafka讀取的訊息中頭值的格式，由於這與聯結器無關，所以允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。預設情況下，SimpleHeaderConverter用於將頭值序列化為字串，並通過推斷模式反序列化它們。

型別：類
預設值: null
有效值。
重要性：低

 

 

config.action.reload
當外部配置提供者的變化導致聯結器的配置屬性發生變化時，Connect應該對聯結器採取的行動。值為'none'表示Connect將不做任何操作。值為'restart'表示Connect應該使用更新的配置屬性重新啟動/重新載入聯結器.如果外部配置提供者表示某個配置值將在未來過期，那麼實際上可能會在未來安排重新啟動。

型別：字串
預設：restart
有效值。 [none, restart]
重要性：低

 

 

transforms
要應用於記錄的轉換的別名。

型別：列表
預設：""
有效值：非空字串，唯一的轉換別名。
重要性：低

 

 

predicates
變換所使用的謂詞的別名。

型別：列表
預設：""
有效值：非空字串，唯一的謂詞別名。
重要性：低

  

 

errors.retry.timeout
失敗後重新嘗試操作的最大持續時間，以毫秒為單位。預設值是0，表示不嘗試重試。使用-1表示無限次重試。

型別：long
預設值：0
有效值。
重要性：中等

  

 

errors.retry.delay.max.ms
連續重試嘗試之間的最大持續時間，單位為毫秒。一旦達到這個限制，抖動將被新增到延遲中，以防止雷鳴般的群組問題。

型別：long
預設：60000（1分鐘)
有效值。
重要性：中等

  

 

errors.tolerance
在聯結器操作期間容忍錯誤的行為。'none'是預設值，表示任何錯誤都會導致聯結器任務立即失敗；'all'會改變行為，跳過有問題的記錄。

型別：字串
預設：none
有效值。 [none, all]
重要性：中等

  

 

errors.log.enable
如果為 "true"，則將每個錯誤以及失敗操作和問題記錄的詳細資訊寫入 Connect 應用程式日誌。預設為'false'，因此只有不能容忍的錯誤才會被報告。

型別：布林值
預設：false
有效值。
重要性：中等

 

 

errors.log.include.messages
是否在日誌中包含導致失敗的連線記錄。預設為'false'，這將防止記錄鍵、值和標題被寫入日誌檔案，儘管一些資訊（如主題和分割槽號）仍將被記錄。

型別：布林值
預設：false
有效值。
重要性：中等

  

 

topic.creation.groups
由源聯結器建立的主題配置組。

型別：清單
預設：""
有效值：非空字串，唯一的主題建立組。
重要性：低

 

3.5.2 sink聯結器配置

下面是sink聯結器的配置。

 

 

名稱
該聯結器的全域性唯一名稱。

型別：字串
預設值。
有效值：非空字串，不含ISO控制字元。
重要性：高

 

 

connector.class
該聯結器類的名稱或別名。必須是org.apache.kafka.connect.connector.Connector的子類。如果聯結器是org.apache.kafka.connect.file.FileStreamSinkConnector，你可以指定這個全名，或者使用 "FileStreamSink "或 "FileStreamSinkConnector "來使配置更短一些。

型別：字串
預設值。
有效值。
重要性：高

  

 

tasks.max
該聯結器可使用的最大任務數。

型別：int
預設值：1
有效值：[1,...]
重要性：高

 

 

topics
消耗的主題清單，用逗號隔開。

型別：清單
預設：""
有效值。
重要性：高

 

 

topics.regex
正規表示式給出要消耗的題目。在下面，regex被編譯成java.util.regex.Pattern。只能指定 topics 或 topics.regex 中的一個。

型別：字串
預設：""
有效值：有效的regex
重要性：高

 

 

key.converter
轉換器類用於轉換Kafka Connect格式和寫入Kafka的序列化形式。這控制了向Kafka寫入或從Kafka讀取的訊息中鍵的格式，由於這與聯結器無關，所以允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。

型別：類
預設值: null
有效值。
重要性：低

 

value.converter
轉換器類用於轉換Kafka Connect格式和寫入Kafka的序列化形式。這控制了向Kafka寫入或從Kafka讀取的訊息中的值的格式，由於這與聯結器無關，所以允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。

型別：類
預設值: null
有效值。
重要性：低

 

 

 

header.converter
HeaderConverter類用於在Kafka Connect格式和寫入Kafka的序列化形式之間進行轉換。這控制了向Kafka寫入或從Kafka讀取的訊息中頭值的格式，由於這與聯結器無關，所以允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。預設情況下，SimpleHeaderConverter用於將頭值序列化為字串，並通過推斷模式反序列化它們。

型別：類
預設值: null
有效值。
重要性：低

 

 

config.action.reload
當外部配置提供者的變化導致聯結器的配置屬性發生變化時，Connect應該對聯結器採取的行動。值為'none'表示Connect將不做任何操作。值為'restart'表示Connect應該使用更新的配置屬性重新啟動/重新載入聯結器.如果外部配置提供者表示某個配置值將在未來過期，那麼實際上可能會在未來安排重新啟動。

型別：字串
預設：restart
有效值。[none, restart]
重要性：低

 

 

transforms
要應用於記錄的轉換的別名。

型別：列表
預設：""
有效值：非空字串，唯一的轉換別名。
重要性：低

 

 

predicates
變換所使用的謂詞的別名。

型別：列表
預設：""
有效值：非空字串，唯一的謂詞別名。
重要性：低

 

errors.retry.timeout
失敗後重新嘗試操作的最大持續時間，以毫秒為單位。預設值是0，表示不嘗試重試。使用-1表示無限次重試。

型別：長
預設值：0
有效值。
重要性：中等

 

  

 

errors.retry.delay.max.ms
連續重試嘗試之間的最大持續時間，單位為毫秒。一旦達到這個限制，抖動將被新增到延遲中，以防止雷鳴般的群組問題。

型別：long
預設：60000（1分鐘
有效值。
重要性：中等

 

 

errors.tolerance
在聯結器操作期間容忍錯誤的行為。'none'是預設值，表示任何錯誤都會導致聯結器任務立即失敗；'all'會改變行為，跳過有問題的記錄。

型別：字串
預設：none
有效值。 [none，all]
重要性：中等

 

 

errors.log.enable
如果為 "true"，則將每個錯誤以及失敗操作和問題記錄的詳細資訊寫入 Connect 應用程式日誌。預設為'false'，因此只有不能容忍的錯誤才會被報告。

型別：布林值
預設：false
有效值。
重要性：中等

 

 

error.log.include.message
是否在日誌中包含導致失敗的連線記錄。預設為'false'，這將防止記錄鍵、值和標題被寫入日誌檔案，儘管一些資訊（如主題和分割槽號）仍將被記錄。

型別：布林值
預設：false
有效值。
重要性：中等

 

 

errors.deadletterqueue.topic.name
將用作死信佇列（DLQ）的主題名稱，用於處理由該sink或其轉換或轉換器處理時導致錯誤的訊息。預設情況下，主題名稱為空白，這意味著DLQ中不會記錄任何訊息。

型別：字串
預設：""
有效值。
重要性：中等

 

 

error.deadletterqueue.topic.replication.factor。
當死信佇列主題還不存在時，用於建立死信佇列主題的複製因子。

型別：short
預設值：3
有效值。
重要性：中等

 

 

 

errors.deadletterqueue.context.headers.enable
如果為真，將包含錯誤上下文的頭鍵新增到寫入死信佇列的訊息中。為了避免與原始記錄中的報頭衝突，所有的錯誤上下文報頭鍵，所有的錯誤上下文報頭鍵將以__connect.errors開頭。

型別：布林值
預設：false
有效值。
重要性：中等

 

3.6 Kafka流配置

下面是Kafka Streams客戶端庫的配置。

 

 

application.id
流處理應用程式的識別符號。在Kafka叢集中必須是唯一的。它被用作1）預設的client-id字首，2）用於成員管理的group-id，3）changelog主題字首。

型別：字串
預設值。
有效值。
重要性：高

 

 

bootstrap.servers
用於建立Kafka叢集初始連線的主機/埠對的列表。客戶端將使用所有的伺服器，不管這裡指定了哪些伺服器用於引導--這個列表隻影響用於發現全部伺服器集的初始主機。這個列表的形式應該是 host1:port1,host2:port2,....。因為這些伺服器只是用於初始連線，以發現完整的叢集成員（可能會動態變化），所以這個列表不需要包含完整的伺服器集（不過，你可能需要多個伺服器，以防某個伺服器當機）。

型別：列表
預設值。
有效值。
重要性：高

 

 

 

replication.factor
流處理應用程式建立的變更日誌主題和重新分割槽主題的複製因子。

型別：int
預設值：1
有效值。
重要性：高

 

 

state.dir
狀態儲存的目錄位置。此路徑對於共享相同底層檔案系統的每個流例項必須是唯一的。

型別：字串
預設值。 /tmp/kafka-streams。
有效值。
重要性：高

 

 

acceptable.recovery.lag
客戶端被認為趕上活動任務的最大可接受滯後（追趕的偏移數）.對於給定的工作量，應該對應於遠低於一分鐘的恢復時間。必須至少為0。

型別：long
預設值：10000
有效值：[0，...]
重要性：中等

 

 

cache.max.bytes.buffering
所有執行緒中用於緩衝的最大記憶體位元組數。

型別：long
預設值：10485760
有效值：[0，...]
重要性：中等

 

 

client.id
一個ID字首字串，用於內部消費者、生產者和還原消費者的客戶端ID，模式為'-StreamThread--'。

型別：字串
預設：""
有效值。
重要性：中等

 

 

default.deserialization.exception.handler
實現org.apache.kafka.streams.errors.DeserializationExceptionHandler介面的異常處理類。

型別：類
預設：org.apache.kafka.streams.errors.LogAndFailExceptionHandler。
有效值。
重要性：中等

  

 

default.key.serde
實現org.apache.kafka.common.serialization.Serde介面的key的預設序列化器/反序列化器類。注意，當使用windowed serde類時，需要通過'default.windowed.key.serde.inner'或'default.windowed.value.serde.inner'來設定實現org.apache.kafka.common.serialization.Serde介面的內部serde類。

型別：類
預設值：org.apache.kafka.common.serialization.Serdes$ByteArraySerde。
有效值。
重要性：中等

  

 

default.production.exception.handler
實現org.apache.kafka.streams.errors.ProductionExceptionHandler介面的異常處理類。

型別：類
預設：org.apache.kafka.streams.errors.DefaultProductionExceptionHandler。
有效值。
重要性：中等

  

default.timestamp.extractor
預設的時間戳提取器類，實現了org.apache.kafka.streams.processor.TimestampExtractor介面。

型別：類
預設值：org.apache.kafka.streams.processor.FailOnInvalidTimestamp。
有效值。
重要性：中等

 

  

 

default.value.serde
實現org.apache.kafka.common.serialization.Serde介面的值的預設序列化器/反序列化器類。注意，當使用windowed serde類時，需要通過'default.windowed.key.serde.inner'或'default.windowed.value.serde.inner'來設定實現org.apache.kafka.common.serialization.Serde介面的內部serde類。

型別：類
預設值：org.apache.kafka.common.serialization.Serdes$ByteArraySerde。
有效值。
重要性：中等

 

 

default.windowed.key.serde.inner
視窗化鍵的內部類的預設序列化器/反序列化器。必須實現org.apache.kafka.common.serialization.Serde介面。

型別：類
預設值: null
有效值。
重要性：中等

  

 

default.windowed.value.serde.inner
視窗值內部類的預設序列化器/反序列化器。必須實現org.apache.kafka.common.serialization.Serde介面。

型別：類
預設值: null
有效值。
重要性：中等

 

 

max.task.idle.ms
當不是所有分割槽緩衝區都包含記錄時，流任務保持空閒的最大時間（毫秒），以避免潛在的跨多個輸入流的無序記錄處理。

型別：long
預設值：0
有效值。
重要性：中等

 

 

max.warmup.replicas
一次可以分配的最大暖機副本數量（超出配置的num.standbys的額外備用），目的是在一個例項上保持任務可用，同時在另一個被重新分配的例項上暖機。用於節制多少額外的broker流量和叢集狀態可以用於高可用性。必須至少為1。

型別：int
預設值：2
有效值：[1,...]
重要性：中

  

 

num.standby.replicas
每個任務的備用副本數量。

型別：int
預設值：0
有效值。
重要性：中等

 

 

num.stream.threads
執行流處理的執行緒數。

型別：int
預設值：1
有效值。
重要性：中等

 

 

processing.guarantee
應該使用的處理保證。可能的值是 at_least_once (預設)，exactly_once (需要broker版本 0.11.0 或更高)，和 exactly_once_beta (需要broker版本 2.5 或更高)。需要注意的是，exactly-once處理需要至少三個broker的叢集，預設情況下，這是生產中的推薦設定；對於開發，你可以通過調整broker設定transaction.state.log.replication.factor和transaction.state.log.min.isr來改變這個設定。

型別：字串
預設：at_least_once
有效值。 [at_least_once, exactly_once, exactly_once_beta]
重要性：中等

 

 

security.protocol
用於與broker通訊的協議。有效值是： PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.

型別：字串
預設值。 PLAINTEXT
有效值。
重要性：中等

 

task.timeout.ms
任務因內部錯誤而停滯的最大時間，以毫秒為單位，並重試，直到發出錯誤。對於0毫秒的超時，任務會在第一次內部錯誤時引發錯誤。對於任何大於0ms的超時，任務將在引發錯誤之前至少重試一次。

型別：長
預設：300000（5分鐘)
有效值：[0，...]
重要性：中等

 

 

 

topology.optimization
一個告訴Kafka Streams是否應該優化拓撲的配置，預設情況下是禁用的。

型別：字串
預設：none
有效值: [none, all]
重要性：中等

 

 

application.server
主機:埠對，指向一個使用者定義的端點，該端點可用於該KafkaStreams例項的狀態儲存發現和互動式查詢。

型別：字串
預設：""
有效值。
重要性：低

 

 

buffered.records.per.partition
每個分割槽要緩衝的最大記錄數。

型別：int
預設：1000
有效值。
重要性：低

 

 

built.in.metrics.version
要使用的內建指標的版本。

型別：字串
預設：latest
有效值。 [0.10.0-2.4，latest]
重要性：低

 

 

commit.interval.ms
儲存處理器位置的頻率，以毫秒為單位。(注意，如果processing.guarantee設定為exactly_once，預設值為100，否則預設值為30000)。

型別：long
預設：30000（30秒)
有效值：[0，...]
重要性：低

  

 

connections.max.idle.ms
在該配置指定的毫秒數之後關閉空閒連線。

型別：long
預設：540000（9分鐘)
有效值。
重要性：低

 

 

metadata.max.age.ms
即使我們沒有看到任何分割槽領導權變化，我們也會強制重新整理後設資料，以主動發現任何新的broker或分割槽的時間，以毫秒為單位。

型別：long
預設：300000（5分鐘)
有效值：[0，...]
重要性：低

 

metric.reporters
作為度量報告器使用的類的列表。實現org.apache.kafka.common.metrics.MetricsReporter介面允許插入將被通知新的度量建立的類。JmxReporter總是被包含在註冊JMX統計資料中。

型別：列表
預設：""
有效值。
重要性：低

 

 

 

metrics.num.samples
為計算指標而維護的樣本數量。

型別：int
預設值：2
有效值：[1,...]
重要性：低

 

 

metrics.recording.level
指標的最高記錄級別。

型別：字串
預設：INFO
有效值：[INFO, DEBUG, TRACE] [INFO, DEBUG, TRACE]
重要性：低

 

 

metrics.sample.window.ms
度量樣本計算的時間視窗。

型別：long
預設：30000（30秒)
有效值：[0，...]
重要性：低

 

 

 

partition.grouper
實現org.apache.kafka.streams.processor.PartitionGrouper介面的分割槽聚類。警告：該配置已被廢棄，並將在3.0.0版本中被移除。

型別：類
預設值：org.apache.kafka.streams.processor.DefaultPartitionGrouper。
有效值。
重要性：低

 

 

poll.ms
塊等待輸入的時間，以毫秒為單位。

型別：long
預設值：100
有效值。
重要性：低

 

 

probing.rebalance.interval.ms
在觸發再平衡以探查已完成預熱並準備成為活動狀態的預熱副本之前，等待的最大時間（毫秒）。探測再平衡將繼續被觸發，直到任務平衡。必須至少為1分鐘。

型別：long
預設：600000（10分鐘）
有效值： [60000,...]
重要性：低

 

 

 

receive.buffer.bytes
讀取資料時要使用的TCP接收緩衝區(SO_RCVBUF)的大小。如果該值為-1，則使用OS預設值。

型別：int
預設值：32768（32 kibibytes）。
有效值：[-1,...]
重要性：低

 

reconnect.backoff.max.ms
當重新連線到一個反覆連線失敗的broker時，等待的最大時間，以毫秒為單位。如果提供，每臺主機的backoff將在每一次連續連線失敗時以指數形式增加，直到這個最大值。在計算背離增加後，20%的隨機抖動被新增到避免連線風暴中。

型別：long
預設：1000（1秒)
有效值：[0，...]
重要性：低

 

 

 

reconnect.backoff.ms
試圖重新連線到給定主機前的基本等待時間。這可以避免在一個緊密的迴圈中重複連線到主機。這個backoff適用於客戶端到broker的所有連線嘗試。

型別：long
預設值：50
有效值：[0，...]
重要性：低

 

 

request.timeout.ms
該配置控制客戶端等待請求響應的最長時間。如果在超時之前沒有收到響應，客戶端將在必要時重新傳送請求，或者在重試次數耗盡時失敗。

型別：int
預設：40000（40秒)
有效值：[0，...]
重要性：低

 

retries
設定一個大於零的值將導致客戶端重新傳送任何失敗的請求，並可能出現短暫的錯誤。建議將該值設定為零或`MAX_VALUE`，並使用相應的超時引數來控制客戶端重試請求的時間。

型別：int
預設值：0
有效值：[0,...,2147483647]
重要性：低

 

 

 

retry.backoff.ms
試圖重試給定主題分割槽的失敗請求前的等待時間。這可以避免在某些失敗情況下，在一個緊密的迴圈中重複傳送請求。

型別：long
預設值：100
有效值：[0，...]
重要性：低

  

 

rocksdb.config.setter
一個實現org.apache.kafka.streams.state.RocksDBConfigSetter介面的Rocks DB配置設定器類或類名。

型別：類
預設值: null
有效值。
重要性：低

  

send.buffer.bytes
傳送資料時要使用的TCP傳送緩衝區(SO_SNDBUF)的大小。如果該值為-1，則使用OS預設值。

型別：int
預設值：131072 (128 kibibytes)
有效值：[-1,...]
重要性：低

 

  

 

state.cleanup.delay.ms
分割槽遷移後，在刪除狀態之前要等待的時間，以毫秒為單位。只有在至少state.cleanup.delay.ms內未被修改的狀態目錄才會被刪除。

型別：長
預設：600000（10分鐘）。
有效值。
重要性：低

  

 

upgrade.from
允許以向後相容的方式升級。當從[0.10.0, 1.1]升級到2.0+，或者從[2.0, 2.3]升級到2.4+時，需要這個配置。當從2.4升級到更新的版本時，不需要指定這個配置。預設值是`null`。接受的值是 "0.10.0"、"0.10.1"、"0.10.2"、"0.11.0"、"1.0"、"1.1"、"2.0"、"2.1"、"2.2"、"2.3"（從相應的舊版本升級）。

型別：字串
預設值: null
有效值。 [空、0.10.0、0.10.1、0.10.2、0.11.0、1.0、1.1、2.0、2.1、2.2、2.3]
重要性：低

 

 

windowstore.changelog.additional.retention.ms
新增到一個windows維護Ms，以確保資料不會過早從日誌中刪除。允許時鐘漂移。預設為1天

型別：long
預設：86400000（1天）
有效值。
重要性：低

  

 

3.7 管理設定

下面是Kafka Admin客戶端庫的配置。

 

 

 

bootstrap.server
用於建立Kafka叢集初始連線的主機/埠對的列表。客戶端將使用所有的伺服器，不管這裡指定了哪些伺服器用於引導--這個列表隻影響用於發現全部伺服器集的初始主機。這個列表的形式應該是 host1:port1,host2:port2,....。因為這些伺服器只是用於初始連線，以發現完整的叢集成員（可能會動態變化），所以這個列表不需要包含完整的伺服器集（不過，你可能需要多個伺服器，以防某個伺服器當機）。

型別：列表
預設值。
有效值。
重要性：高

 

 

ssl.key.password
金鑰儲存檔案中私鑰的密碼，或在`ssl.keystore.key'中指定的PEM金鑰。只有在配置了雙向身份驗證的情況下，客戶端才需要這個密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

ssl.keystore.certificate.chain
證照鏈的格式由'ssl.keystore.type'指定。預設的SSL引擎工廠只支援PEM格式的X.509證照列表。

型別：password
預設值: null
有效值。
重要性：高

  

 

ssl.keystore.key
私鑰的格式由'ssl.keystore.type'指定。預設SSL引擎工廠只支援PEM格式的PKCS#8金鑰。如果金鑰是加密的，必須使用'ssl.key.password'指定金鑰密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

ssl.keystore.location
金鑰儲存檔案的位置。對客戶端來說是可選的，可以用於客戶端的雙向認證。

型別：字串
預設值: null
有效值。
重要性：高

 

ssl.keystore.password
金鑰儲存檔案的儲存密碼。這對客戶端來說是可選的，只有在配置了'ssl.keystore.location'時才需要。對於PEM格式，不支援金鑰儲存密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

ssl.truststore.certificate
可信證照的格式由'ssl.truststore.type'指定。預設SSL引擎工廠只支援PEM格式的X.509證照。

型別：password
預設值: null
有效值。
重要性：高

 

 

ssl.truststore.location
信任儲存檔案的位置。

型別：字串
預設值: null
有效值。
重要性：高

 

 

 

ssl.truststore.password
信任儲存檔案的密碼。如果沒有設定密碼，則仍然使用配置的信任儲存檔案，但完整性檢查被禁用。PEM格式不支援信任儲存密碼。

型別：password
預設值: null
有效值。
重要性：高

 

 

client.dns.lookup
控制客戶端如何使用DNS查詢。如果設定為use_all_dns_ips，則依次連線到每個返回的IP地址，直到成功建立連線。斷開連線後，會使用下一個IP。一旦所有的IP都被使用過一次，客戶端就會再次解析主機名中的IP（然而，JVM和作業系統都會快取DNS名稱查詢）。如果設定為resolve_canonical_bootstrap_servers_only，則將每個引導地址解析成一個canonical名稱列表。在引導階段之後，這和use_all_dns_ips的行為是一樣的。如果設定為預設（已廢棄），即使查詢返回多個IP地址，也會嘗試連線到查詢返回的第一個IP地址。

型別：字串
預設值: use_all_dns_ips
有效值。 [default, use_all_dns_ips, resolve_canonical_bootstrap_servers_only] 。
重要性：中等

 

client.id
一個ID字串，在發出請求時傳遞給伺服器。這樣做的目的是為了在伺服器端請求日誌中包含一個邏輯應用程式名稱，從而能夠跟蹤請求的來源，而不僅僅是ip/埠。

型別：字串
預設：""
有效值。
重要性：中等

 

 

 

connections.max.idle.ms
在該配置指定的毫秒數之後關閉空閒連線。

型別：long
預設：300000（5分鐘)
有效值。
重要性：中等

 

 

default.api.timeout.ms
指定客戶端API的超時時間（以毫秒為單位）。此配置被用作所有未指定超時引數的客戶端操作的預設超時。

型別：int
預設：60000（1分鐘)
有效值：[0，...]
重要性：中等

  

 

receive.buffer.bytes
讀取資料時要使用的TCP接收緩衝區(SO_RCVBUF)的大小。如果該值為-1，則使用OS預設值。

型別：int
預設值：65536（64 kibibytes）。
有效值：[-1,...]
重要性：中等

 

request.timeout.ms
該配置控制客戶端等待請求響應的最長時間。如果在超時之前沒有收到響應，客戶端將在必要時重新傳送請求，或者在重試次數耗盡時失敗。

型別：int
預設：30000（30秒)
有效值：[0，...]
重要性：中等

 

 

 

sasl.client.callback.handler.class
實現AuthenticateCallbackHandler介面的SASL客戶端回撥處理程式類的全稱。

型別：類
預設值: null
有效值。
重要性：中等

 

 

sasl.jaas.config
JAAS登入上下文引數，用於SASL連線，格式為JAAS配置檔案使用的格式。JAAS配置檔案的格式在這裡有介紹。值的格式為：'loginModuleClass controlFlag (optionName=optionValue)*;'。對於broker來說，配置必須以監聽器字首和SASL機制名稱為字首，並以小寫字母表示。例如，listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.exam.ScramLoginModule必填。

型別：password
預設值: null
有效值。
重要性：中等

 

sasl.kerberos.service.name。
Kafka 執行的 Kerberos 主體名稱。這可以在Kafka的JAAS配置或Kafka的配置中定義。

型別：字串
預設值: null
有效值。
重要性：中等

 

 

 

sasl.login.callback.handler.class。
實現AuthenticateCallbackHandler介面的SASL登入回撥處理程式類的完全限定名稱。對於broker來說，登入回撥處理程式配置必須以監聽器字首和小寫的SASL機制名稱為字首。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler。

型別：類
預設值: null
有效值。
重要性：中等

 

 

 

sasl.login.class
實現Login介面的類的全稱。對於broker來說，login config必須以監聽器字首和SASL機制名稱為字首，並使用小寫。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin。

型別：類
預設值: null
有效值。
重要性：中等

 

sasl.mechanism
用於客戶端連線的SASL機制。這可以是任何有安全提供者的機制。GSSAPI是預設機制。

型別：字串
預設值。 GSSAPI
有效值。
重要性：中等

 

 

 

security.protocol
用於與broker通訊的協議。有效值是： PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.

型別：字串
預設值。 PLAINTEXT
有效值。
重要性：中等

 

 

 

send.buffer.bytes
傳送資料時要使用的TCP傳送緩衝區(SO_SNDBUF)的大小。如果該值為-1，則使用OS預設值。

型別：int
預設值：131072 (128 kibibytes)
有效值：[-1,...]
重要性：中等

 

 

socket.connection.setup.timeout.max.ms
客戶端等待建立套接字連線的最大時間。連線設定超時時間將隨著每一次連續的連線失敗而成倍增加，直到這個最大值。為了避免連線風暴，超時時間將被應用於0.2的隨機係數，結果是低於計算值20%到高於計算值20%的隨機範圍。

型別：long
預設：127000（127秒
有效值。
重要性：中等

 

socket.connection.setup.timeout.ms
客戶端等待socket連線建立的時間。如果在超時之前沒有建立連線，客戶端將關閉socket通道。

型別：long
預設：10000（10秒
有效值。
重要性：中等

 

 

 

ssl.enabled.protocols
為SSL連線啟用的協議列表。預設值是 "TLSv1.2,TLSv1.3"，當執行Java 11或更新版本時，否則為 "TLSv1.2"。在Java 11的預設值下，如果客戶端和伺服器都支援TLSv1.3，則會優先選擇TLSv1.3，否則會回退到TLSv1.2（假設兩者都至少支援TLSv1.2）。這個預設值在大多數情況下應該是沒有問題的。也可以參考`ssl.protocol`的配置文件。

型別：列表
預設值: TLSv1.2
有效值。
重要性：中等

 

 

ssl.keystore.type
金鑰儲存檔案的檔案格式。對客戶端來說是可選的。

型別：字串
預設值。 JKS
有效值。
重要性：中等

 

ssl.protocol
用來生成SSLContext的SSL協議，預設為'TLSv1.3'，否則為'TLSv1.2'。當執行Java 11或更新版本時，預設為'TLSv1.3'，否則為'TLSv1.2'。這個值對於大多數的使用情況來說應該是沒有問題的。在最近的JVM中允許的值是'TLSv1.2'和'TLSv1.3'。TLS'，'TLSv1.1'，'SSL'，'SSLv2'和'SSLv3'在舊的JVM中可能會被支援，但由於已知的安全漏洞，我們不鼓勵使用它們。在這個配置和'ssl.enabled.protocols'的預設值下，如果伺服器不支援'TLSv1.3'，客戶端將降級為'TLSv1.2'。如果這個配置被設定為'TLSv1.2'，即使是ssl.enabled.protocols中的一個值，並且伺服器只支援'TLSv1.3'，客戶端也不會使用'TLSv1.3'。

型別：字串
預設值: TLSv1.2
有效值。
重要性：中等

 

  

ssl.provider
用於SSL連線的安全提供者的名稱。預設值是JVM的預設安全提供者。

型別：字串
預設值: null
有效值。
重要性：中等

 

  

 

ssl.truststore.type
信任儲存檔案的檔案格式。

型別：字串
預設值。 JKS
有效值。
重要性：中等

  

metadata.max.age.ms
即使我們沒有看到任何分割槽領導權變化，我們也會強制重新整理後設資料，以主動發現任何新的broker或分割槽的時間，以毫秒為單位。

型別：長
預設：300000（5分鐘)
有效值：[0，...]
重要性：低

 

  

 

metric.reporters
作為度量報告器使用的類的列表。實現org.apache.kafka.common.metrics.MetricsReporter介面允許插入將被通知新的度量建立的類。JmxReporter總是被包含在註冊JMX統計資料中。

型別：列表
預設：""
有效值。
重要性：低

 

 

metrics.num.samples
為計算指標而維護的樣本數量。

型別：int
預設值：2
有效值：[1,...]
重要性：低

  

 

metrics.recording.level
指標的最高記錄級別。

型別：字串
預設：INFO
有效值：[INFO, DEBUG, TRACE] [INFO, DEBUG, TRACE]
重要性：低

 

 

metrics.sample.window.ms
度量樣本計算的時間視窗。

型別：long
預設：30000（30秒)
有效值：[0，...]
重要性：低

 

 

reconnect.backoff.max.ms
當重新連線到一個反覆連線失敗的broker時，等待的最大時間，以毫秒為單位。如果提供，每臺主機的backoff將在每一次連續連線失敗時以指數形式增加，直到這個最大值。在計算背離增加後，20%的隨機抖動被新增到避免連線風暴中。

型別：long
預設：1000（1秒)
有效值：[0，...]
重要性：低

  

 

reconnect.backoff.ms
試圖重新連線到給定主機前的基本等待時間。這可以避免在一個緊密的迴圈中重複連線到主機。這個backoff適用於客戶端到broker的所有連線嘗試。

型別：long
預設值：50
有效值：[0，...]
重要性：低

 

 

retries
設定一個大於零的值將導致客戶端重新傳送任何失敗的請求，並可能出現短暫的錯誤。建議將該值設定為零或`MAX_VALUE`，並使用相應的超時引數來控制客戶端重試請求的時間。

型別：int
預設：2147483647
有效值： [0，...，2147483647]
重要性：低

 

 

retry.backoff.ms
試圖重試一個失敗的請求前的等待時間。這可以避免在某些失敗情況下，在一個緊密的迴圈中重複傳送請求。

型別：long
預設值：100
有效值：[0，...]
重要性：低

 

 

sasl.kerberos.kinit.cmd
Kerberos kinit 命令路徑。

型別：字串
預設值。 /usr/bin/kinit
有效值。
重要性：低

 

sasl.kerberos.min.time.before.relogin
登入執行緒重新整理嘗試之間的睡眠時間。

型別：long
預設值：60000
有效值。
重要性：低

 

 

 

sasl.kerberos.ticket.renew.jitter
隨機抖動加到續航時間的百分比。

型別：double
預設值：0.05
有效值。
重要性：低

 

 

sasl.kerberos.ticket.renew.window.factor
登入執行緒將休眠，直到達到從上次重新整理到票據到期的指定時間視窗係數，這時它將嘗試更新票據。

型別：double
預設值：0.8
有效值。
重要性：低

 

 

sasl.login.refresh.buffer.seconds
重新整理憑證時，在憑證到期前要保持的緩衝時間，以秒為單位。如果重新整理的時間離到期時間比緩衝秒數更近，那麼重新整理時間將被提前，以儘可能多地保持緩衝時間。法定值在0到3600（1小時）之間；如果沒有指定值，則使用預設值300（5分鐘）。如果該值和sasl.login.refresh.min.period.seconds的總和超過了憑證的剩餘壽命，則該值和sasl.login.refresh.min.period.seconds都會被忽略。目前只適用於OAUTHBEARER。

型別：short
預設值：300
有效值：[0,...,3600]
重要性：低

 

 

sasl.login.refresh.min.period.seconds
登入重新整理執行緒在重新整理憑證前需要等待的最短時間，以秒為單位。合法值在0到900（15分鐘）之間；如果沒有指定值，則使用預設值60（1分鐘）。如果這個值和sasl.login.refresh.buffer.seconds的總和超過了一個憑證的剩餘壽命，那麼這個值和sasl.login.buffer.seconds都會被忽略。目前只適用於OAUTHBEARER。

型別：short
預設值：60
有效值：[0，...，900]
重要性：低

 

 

sasl.login.refresh.window.factor
登入重新整理執行緒將休眠，直到達到相對於憑證壽命的指定視窗係數，此時將嘗試重新整理憑證。合法值在0.5(50%)到1.0(100%)之間，如果沒有指定值，則使用預設值0.8(80%)。目前僅適用於OAUTHBEARER。

型別：double
預設值：0.8
有效值：[0.5,...,1.0]
重要性：低

  

 

sasl.login.refresh.window.jitter
相對於憑證的壽命，加到登入重新整理執行緒的睡眠時間的最大隨機抖動量。合法值在0到0.25（25%）之間，如果沒有指定值，則使用預設值0.05（5%）。目前只適用於OAUTHBEARER。

型別：double
預設值：0.05
有效值：[0.0,...,0.25]
重要性：低

 

 

security.providers
一個可配置的建立者類的列表，每個類都返回一個實現安全演算法的提供者。這些類應該實現org.apache.kafka.common.security.ah.SecurityProviderCreator介面。

型別：字串
預設值: null
有效值。
重要性：低

 

 

ssl.cipher.suites
密碼套件的列表。這是一個命名的認證、加密、MAC和金鑰交換演算法的組合，用於使用TLS或SSL網路協議協商網路連線的安全設定。預設情況下，支援所有可用的密碼套件。

型別：列表
預設值: null
有效值。
重要性：低

 

ssl.endpoint.identification.algorithm
使用伺服器證照驗證伺服器主機名的端點識別演算法。

型別：字串
預設：https
有效值。
重要性：低

 

 

 

ssl.engine.factory.class
org.apache.kafka.common.security.auth.SslEngineFactory型別的類來提供SSLEngine物件。預設值是org.apache.kafka.common.security.ssl.DefaultSslEngineFactory。

型別：類
預設值: null
有效值。
重要性：低

 

 

ssl.keymanager.algorithm
鑰匙管理器工廠用於SSL連線的演算法，預設值是為Java虛擬機器配置的鑰匙管理器工廠演算法。預設值是為Java虛擬機器配置的金鑰管理器工廠演算法。

型別：字串
預設值。 SunX509
有效值。
重要性：低

 

 

 

ssl.secure.random.implementation
用於SSL加密操作的SecureRandom PRNG實現。

型別：字串
預設值: null
有效值。
重要性：低

 

 

ssl.trustmanager.algorithm
信任管理器工廠用於SSL連線的演算法。預設值是為Java虛擬機器配置的信任管理器工廠演算法。

型別：字串
預設值。 PKIX
有效值。
重要性：低

 

4.設計

4.1 動機

我們設計Kafka是為了能夠作為一個統一的平臺來處理一個大公司可能擁有的所有實時資料來源。要做到這一點，我們必須考慮一套相當廣泛的用例。

它必須具備高吞吐量，以支援大容量的事件流，如實時日誌聚合。

它需要優雅地處理大量的資料積壓，以支援來自離線系統的定期資料負載。

這也意味著系統必須處理低延遲交付，以處理更多傳統的訊息傳遞用例。

我們希望支援對這些feeds進行分割槽、分散式、實時處理，以建立新的衍生feeds。這激勵了我們的分割槽和消費者模型。

最後，在將資料流送入其他資料系統進行服務的情況下，我們知道系統必須能夠保證在機器出現故障時的容錯性。

支援這些用途使得我們設計出了一個具有一些獨特元素的系統，更類似於資料庫日誌，而不是傳統的訊息系統。我們將在下面的章節中概述該設計的一些元素。

 

4.2 永續性

別擔心檔案系統!

Kafka嚴重依賴檔案系統來儲存和快取訊息。人們普遍認為 "磁碟很慢"，這讓人們懷疑持久化結構是否能提供有競爭力的效能。事實上磁碟比人們預期的慢和快都要快得多，這取決於如何使用磁碟；而設計得當的磁碟結構往往可以和網路一樣快。

關於磁碟效能的關鍵事實是，在過去的十年裡，硬碟的吞吐量與磁碟尋道的延遲一直在分化。因此，在6塊7200rpm SATA RAID-5陣列的JBOD配置上，線性寫入的效能約為600MB/秒，但隨機寫入的效能只有約100k/秒--相差6000多倍。這些線性讀寫是所有使用模式中最可預測的，並且由作業系統進行了大量優化。現代作業系統提供了讀前和寫後技術，以大塊倍數預取資料，並將較小的邏輯寫入分組為大的物理寫入。關於這個問題的進一步討論可以在這篇ACM Queue文章中找到，實際上他們發現順序磁碟訪問在某些情況下可以比隨機記憶體訪問更快!

為了補償這種效能上的分歧，現代作業系統在使用主記憶體進行磁碟快取方面變得越來越積極。現代作業系統會很樂意將所有的空閒記憶體轉移到磁碟快取中，而當記憶體被回收時，幾乎沒有效能上的損失。所有的磁碟讀寫都會經過這個統一的快取。如果不使用直接的I/O，就不能輕易關閉這個功能，所以即使一個程式維護了資料的程式內快取，這些資料也很可能會在OS的pagecache中重複，實際上是把所有的東西都儲存了兩次。

此外，我們是在JVM之上構建的，任何花過時間研究Java記憶體使用的人都知道兩件事。

1. 物件的記憶體開銷是非常大的，往往是儲存的資料大小的兩倍（或者更糟）。
2. 隨著堆內資料的增加，Java垃圾收集變得越來越費事和緩慢。

由於這些因素，使用檔案系統和依靠pagecache比維護記憶體中的快取或其他結構更優越--我們通過對所有空閒記憶體的自動訪問，至少使可用的快取增加一倍，而且通過儲存一個緊湊的位元組結構而不是單個物件，很可能再增加一倍。這樣做的結果是，在32GB的機器上，可以獲得高達28-30GB的快取，而不會受到GC的懲罰。此外，即使服務重啟，這個快取也會保持溫熱，而程式中的快取則需要在記憶體中重建（對於10GB的快取來說，可能需要10分鐘），否則就需要從一個完全冷的快取開始（這很可能意味著糟糕的初始效能）。這也極大地簡化了程式碼，因為所有維持快取和檔案系統之間一致性的邏輯現在都在作業系統中，這往往比一次性的程式內嘗試更有效、更正確。如果你的磁碟使用傾向於線性讀取，那麼read-ahead有效地在每次磁碟讀取時用有用的資料預先填充這個快取。

這表明了一種非常簡單的設計：與其在記憶體中保持儘可能多的資料，並在空間耗盡時慌忙將其全部衝到檔案系統中，不如反過來。所有的資料都會立即寫入檔案系統上的一個永續性日誌，而不一定要衝到磁碟上。實際上，這只是意味著它被轉移到核心的pagecache中。

這種以pagecache為中心的設計風格在Varnish設計的一篇文章中有所描述（還有一點傲慢）。

固定的時間就足夠了

訊息系統中使用的永續性資料結構通常是每個消費者佇列，並有一個相關的BTree或其他通用的隨機訪問資料結構來維護訊息的後設資料。BTree是目前最通用的資料結構，它使得在訊息系統中支援各種各樣的事務性和非事務性語義成為可能。不過它們的成本確實相當高：Btree的操作是O(log N)。通常O(log N)被認為基本等同於恆定時間，但對於磁碟操作來說，這並不是真的。磁碟搜尋的速度是10毫秒一次，而且每個磁碟一次只能做一次搜尋，所以並行性是有限的。因此，即使是少量的磁碟尋道也會導致非常高的開銷。由於儲存系統將非常快的快取操作和非常慢的物理磁碟操作混合在一起，所以樹形結構的觀察效能往往是隨著資料的增加而固定快取的超線性的--也就是說，你的資料增加一倍，情況就會比慢一倍要糟糕得多。

直觀地講，一個永續性佇列可以建立在簡單的檔案讀取和追加上，就像常見的日誌解決方案一樣。這種結構的優點是，所有的操作都是O(1)，讀不會阻塞寫或彼此。這具有明顯的效能優勢，因為效能與資料大小完全解耦--一臺伺服器現在可以充分利用一些廉價的、低轉速的1+TB SATA硬碟。雖然這些硬碟的尋道效能較差，但對於大型讀寫來說，它們的效能還是可以接受的，而且價格只有1/3，容量只有3倍。

在沒有任何效能損失的情況下，可以訪問幾乎無限的磁碟空間，這意味著我們可以提供一些通常在訊息系統中找不到的功能。例如，在Kafka中，我們可以將訊息保留相對較長的時間（比如一週），而不是在訊息消耗完後立即嘗試刪除它們。這為消費者帶來了很大的靈活性，我們將進行描述。

 

4.3 效率

我們在效率方面下了很大功夫。我們的主要用例之一是處理網路活動資料，這是非常大的工作量：每個頁面瀏覽可能會產生幾十次寫入。此外，我們假設每條釋出的訊息至少被一個消費者（通常是許多）讀取，因此我們努力使消費盡可能便宜。

從構建和執行一些類似系統的經驗中，我們還發現，效率是多租戶有效運營的關鍵。如果下游的基礎設施服務很容易因為應用的一個小的使用量的提升而成為瓶頸，這種小的變化往往會帶來問題。通過非常快的速度，我們有助於確保應用在負載下會先於基礎設施而傾覆。當我們試圖在一個集中式叢集上執行一個支援幾十個或幾百個應用程式的集中式服務時，這一點尤為重要，因為使用模式的變化幾乎每天都會發生。

我們在上一節討論了磁碟效率。一旦消除了不良的磁碟訪問模式，在這種型別的系統中，有兩個常見的低效率原因：過多的小I/O操作，以及過多的位元組複製。

小I/O問題既發生在客戶端和伺服器之間，也發生在伺服器自身的持久化操作中。

為了避免這種情況，我們的協議是圍繞著一個 "訊息集 "抽象建立的，它自然地將訊息分組。這使得網路請求可以將訊息分組，並攤銷網路往返的開銷，而不是每次只傳送一條訊息。而伺服器則一次性將訊息分塊追加到其日誌中，消費者則一次取回大的線性分塊。

這個簡單的優化產生了數量級的速度提升。批量導致更大的網路資料包、更大的順序磁碟操作、連續的記憶體塊等等，所有這些都讓Kafka將隨機訊息寫入的突發流變成線性寫入，流向消費者。

另一個低效率是在位元組複製方面。在低訊息速率下，這不是問題，但在負載下，影響很大。為了避免這種情況，我們採用了標準化的二進位制訊息格式，由生產者、broker和消費者共享（因此資料塊可以在他們之間不加修改地傳輸）。

broker維護的訊息日誌本身只是一個檔案目錄，每個檔案都由一連串的訊息集填充，這些訊息集已經以生產者和消費者使用的相同格式寫入磁碟。保持這種共同的格式可以優化最重要的操作：網路傳輸持久的日誌塊。現代的unix作業系統提供了一個高度優化的程式碼路徑，用於將資料從pagecache中傳輸到socket中；在Linux中，這是通過sendfile系統呼叫完成的。

要了解sendfile的影響，就必須瞭解從檔案到socket傳輸資料的常用資料路徑。

1. 作業系統從磁碟上讀取資料到核心空間的pagecache中。
2. 應用程式將資料從核心空間讀取到使用者空間緩衝區中
3. 應用程式將資料寫回核心空間到socket緩衝區中
4. 作業系統將資料從套接字緩衝區複製到網路卡緩衝區，並通過網路傳送。

這顯然效率很低，有四次拷貝和兩次系統呼叫。使用sendfile，可以讓作業系統直接將資料從pagecache傳送到網路上，避免了這種重複複製。所以在這個優化的路徑中，只需要最後複製到網路卡緩衝區。

我們預計一個常見的用例是一個主題上有多個消費者。使用上面的零拷貝優化，資料被準確地複製到pagecache中一次，並在每次消費時重複使用，而不是儲存在記憶體中，並在每次讀取時複製到使用者空間。這樣可以使訊息的消耗速度接近網路連線的極限。

pagecache和sendfile的這種組合意味著，在一個Kafka叢集中，消費者大部分都被趕上了，你將看到磁碟上沒有任何讀取活動，因為它們將完全從快取中提供資料。

關於Java中sendfile和零拷貝支援的更多背景，請看這篇文章。

 

端到端批量壓縮

在某些情況下，瓶頸其實不是CPU或磁碟，而是網路頻寬。對於一個需要通過廣域網在資料中心之間傳送訊息的資料管道來說尤其如此。當然，使用者總是可以在不需要Kafka提供任何支援的情況下一次壓縮其訊息，但這可能會導致很差的壓縮比，因為很多冗餘是由於相同型別的訊息之間的重複（例如JSON中的欄位名或Web日誌中的使用者代理或共同的字串值）。高效的壓縮需要將多個訊息一起壓縮，而不是單獨壓縮每個訊息。

Kafka通過高效的批處理格式來支援這一點。一批訊息可以被叢生壓縮在一起，並以這種形式傳送到伺服器。這批訊息將以壓縮的形式寫入日誌，並在日誌中保持壓縮狀態，只有消費者才會解壓。

Kafka支援GZIP、Snappy、LZ4和ZStandard壓縮協議。關於壓縮的更多細節可以在這裡找到。

 

4.4 生產者

負載均衡

生產者直接將資料傳送到作為分割槽領導者的broker，而不需要任何干預的路由層。為了幫助生產者做到這一點，所有的Kafka節點都可以應答關於哪些伺服器是活著的，以及某個主題的分割槽的領導者在哪裡的後設資料請求，以便生產者適當地引導其請求。

客戶端控制它將訊息釋出到哪個分割槽。這可以是隨機的，實現一種隨機負載均衡，也可以通過一些語義分割槽函式來實現。我們公開了語義分割槽的介面，允許使用者指定一個金鑰來進行分割槽，並使用這個金鑰來雜湊到一個分割槽（如果需要的話，還可以選擇覆蓋分割槽函式）。例如，如果選擇的鍵是一個使用者id，那麼給定使用者的所有資料將被髮送到同一個分割槽。這又將允許消費者對他們的消費進行位置性假設。這種分割槽風格被明確設計為允許消費者進行區位性敏感處理。

 

非同步傳送

批量是提高效率的一大驅動力，為了實現批量化，Kafka生產者會嘗試在記憶體中積累資料，並在一次請求中傳送更大的批量。批量可以配置為積累不超過固定數量的訊息，並且等待的時間不超過某個固定的延遲邊界（比如64k或10ms）。這樣可以積累更多的位元組傳送，伺服器上很少有較大的I/O操作。這種緩衝是可配置的，並提供了一種機制來換取少量的額外延遲以獲得更好的吞吐量。

關於配置的細節和生產者的api可以在文件的其他地方找到。

 

4.5 消費者

Kafka消費者的工作方式是向它要消費的分割槽的領導broker發出 "獲取 "請求。消費者通過每個請求指定其在日誌中的偏移量，並接收回從該位置開始的一大塊日誌。因此，消費者對這個位置有很大的控制權，如果需要的話，可以將其倒轉過來重新消費資料。

 

推送 vs 拉取

我們最初考慮的一個問題是，消費者應該從broker那裡拉取資料，還是broker應該將資料推送給消費者。在這方面，Kafka遵循的是一種比較傳統的設計，大多數訊息系統都有這種設計，資料從生產者推送給broker，消費者從broker那裡拉取資料。一些以日誌為中心的系統，如Scribe和Apache Flume，遵循的是一種非常不同的基於推送的路徑，資料被推送到下游。這兩種方法各有利弊。然而，基於推送的系統很難處理不同的消費者，因為broker控制資料傳輸的速度。目標一般是讓消費者能夠以最大可能的速率消費；不幸的是，在推式系統中，這意味著當消費者的消費速率低於生產速率時，消費者往往會被淹沒（本質上是拒絕服務攻擊）。基於拉的系統有一個較好的特性，即消費者只是落在後面，當它能趕上的時候就會趕上。這種情況可以通過某種後退協議來緩解，消費者可以通過這種協議來表示它已經不堪重負，但是讓傳輸速率充分利用（但永遠不要過度利用）消費者是比看起來更棘手的。之前以這種方式構建系統的嘗試，讓我們選擇了更傳統的拉式模式。

基於拉的系統的另一個優點是，它適合於積極地批量傳送資料給消費者。基於推的系統必須選擇要麼立即傳送請求，要麼積累更多的資料，然後在不知道下游消費者是否能夠立即處理的情況下再傳送。如果針對低延遲進行調整，這將導致每次傳送一條訊息，但最後還是被緩衝傳輸，這是一種浪費。基於拉動的設計解決了這個問題，因為消費者總是在日誌中的當前位置後拉動所有可用的訊息（或達到某個可配置的最大大小）。因此，人們可以在不引入不必要的延遲的情況下獲得最佳的批處理。

天真的基於拉動的系統的不足之處是，如果broker沒有資料，消費者可能最終會在一個緊密的迴圈中進行輪詢，實際上是忙於等待資料的到來。為了避免這種情況，我們在拉動請求中設定了引數，允許消費者請求以 "長輪詢 "的方式阻塞，等待資料的到來（也可以選擇等待到給定的位元組數，以確保大的傳輸規模）。

你可以想象其他可能的設計，這將是隻拉，端到端。生產者將在本地寫入本地日誌，而broker將從中拉取資料，消費者也將從中拉取資料。類似型別的 "儲存和轉發 "生產者經常被提出。這很有吸引力，但我們覺得不太適合我們的目標用例，因為我們的目標用例有成千上萬的生產者。我們在大規模執行永續性資料系統的經驗使我們感到，在系統中涉及數千塊磁碟，跨越許多應用，實際上不會使事情變得更可靠，而且會成為操作的噩夢。而在實踐中我們發現，我們可以在不需要生產者持久化的情況下，大規模執行具有強大SLA的流水線。

 

消費者位置

追蹤哪些訊息已經被消費，竟然是訊息系統的關鍵效能點之一。
大多數訊息系統都會在broker上儲存關於哪些訊息已經被消費的後設資料。也就是說，當一條訊息被遞給消費者時，broker要麼立即在本地記錄這一事實，要麼可能會等待消費者的確認。這是一個相當直觀的選擇，事實上對於單機伺服器來說，並不清楚這個狀態還能去哪裡。由於許多訊息系統中用於儲存的資料結構擴充套件性很差，這也是一個實用主義的選擇--由於中間商知道什麼東西被消耗了，它可以立即刪除它，保持資料的小規模。

也許並不明顯的是，讓中間商和消費者就什麼被消耗了達成一致並不是一個小問題。如果broker每次在網路上遞出一條訊息時，都會立即記錄為已消耗，那麼如果消費者未能處理該訊息（比如說因為它崩潰或請求超時或其他原因），該訊息將丟失。為了解決這個問題，很多訊息系統都增加了一個確認功能，也就是說訊息在傳送的時候只標記為已傳送而非消耗，中間人會等待消費者的特定確認，將訊息記錄為消耗。這種策略解決了訊息丟失的問題，但又產生了新的問題。首先，如果消費者處理了訊息，但在傳送確認之前就失敗了，那麼訊息就會被消耗兩次。第二個問題是圍繞著效能，現在broker必須對每一條訊息保持多個狀態（首先要鎖定它，這樣它就不會被第二次發出，然後把它標記為永久消耗，這樣就可以刪除它）。必須處理一些棘手的問題，比如如何處理那些已經傳送但從未被確認的訊息。

Kafka的處理方式不同。我們的主題被劃分為一組完全有序的分割槽，每個分割槽在任何時候都正好被每個訂閱消費者組中的一個消費者消耗。這意味著消費者在每個分割槽中的位置只是一個單一的整數，即下一個要消耗的訊息的偏移。這使得關於已經消耗的狀態非常小，每個分割槽只有一個數字。這個狀態可以定期檢查點。這使得相當於訊息確認的成本非常低。

這個決定有一個側面的好處。消費者可以故意倒退到一箇舊的偏移量，重新消耗資料。這違反了佇列的普通契約，但對許多消費者來說，這原來是一個必不可少的功能。例如，如果消費者的程式碼有一個bug，並且在一些訊息被消耗後被發現，那麼一旦bug被修復，消費者就可以重新消耗這些訊息。

 

離線資料載入

可擴充套件的永續性允許只進行週期性消費的消費者，比如批量資料載入，週期性地將資料批量載入到Hadoop或關係型資料倉儲等離線系統中。
在Hadoop的情況下，我們通過將資料負載拆分到各個地圖任務上，每個節點/主題/分割槽組合一個任務，實現資料負載的完全並行化。Hadoop提供了任務管理，失敗的任務可以重新開始，而不會有重複資料的危險--它們只是從原來的位置重新開始。

 

靜態會員制度

靜態成員資格旨在提高建立在組再平衡協議之上的流應用、消費者組和其他應用的可用性。再平衡協議依賴於組協調器為組成員分配實體id。這些生成的id是短暫的，當成員重新啟動和重新加入時，這些id會發生變化。對於基於消費者的應用程式，這種 "動態成員 "可能會導致在管理操作期間（如程式碼部署、配置更新和定期重啟），將大比例的任務重新分配給不同的例項。對於大狀態的應用，洗牌後的任務在處理前需要長時間恢復其本地狀態，並導致應用部分或完全不可用。在這一觀察的激勵下，Kafka的組管理協議允許組成員提供持久的實體id。組成員基於這些id保持不變，因此不會觸發重新平衡。
如果你想使用靜態成員資格。

• 將broker叢集和客戶端應用都升級到2.3或更高版本，同時確保升級後的broker也使用2.3或更高版本的inter.broker.協議。
• 將config ConsumerConfig#GROUP_INSTANCE_ID_CONFIG設定為一個組下每個消費者例項的唯一值。
• 對於Kafka Streams應用，為每個KafkaStreams例項設定一個唯一的ConsumerConfig#GROUP_INSTANCE_ID_CONFIG即可，與例項的使用執行緒數無關。

如果你的broker處於比2.3更老的版本，但你選擇在客戶端設定ConsumerConfig#GROUP_INSTANCE_ID_CONFIG，應用程式將檢測broker的版本，然後丟擲一個UnsupportedException。如果你不小心為不同的例項配置了重複的id，broker端的圍欄機制會通過觸發org.apache.kafka.common.error.FencedInstanceIdException來通知你的重複客戶端立即關閉。更多細節，請參見KIP-345

 

4.6 訊息傳遞語義

 

現在我們已經對生產者和消費者的工作方式有了一些瞭解，讓我們來討論一下Kafka在生產者和消費者之間提供的語義保證。顯然，可以提供多種可能的訊息傳遞保證。

• 最多一次--訊息可能會丟失，但永遠不會被重傳。
• 至少一次--訊息永遠不會丟失，但可能會被重新傳遞。
• 正好一次--這才是人們真正想要的，每條資訊都是一次，而且只有一次。

值得注意的是，這分為兩個問題：釋出訊息的耐久性保證和消費訊息時的保證。
很多系統都聲稱提供 "精確一次 "的交付語義，但要看清字面意思，這些說法大多是誤導性的（即不能轉化為消費者或生產者可能失敗的情況，也不能轉化為有多個消費程式的情況，或者寫入磁碟的資料可能丟失的情況）。

Kafka的語義是直接的。當釋出一條訊息時，我們有一個訊息被 "提交 "到日誌的概念。一旦釋出的訊息被提交，只要有一個複製這個訊息寫入的分割槽的broker仍然 "活著"，它就不會丟失。提交的訊息、活著的分割槽的定義，以及我們試圖處理哪些型別的故障的描述，將在下一節中詳細介紹。現在讓我們假設一個完美的、無損的broker，並嘗試理解對生產者和消費者的保證。如果生產者嘗試釋出訊息並遇到網路錯誤，它無法確定這個錯誤是發生在訊息提交之前還是之後。這類似於用自動生成的鍵插入到資料庫表中的語義。

在0.11.0.0之前，如果生產者沒有收到表明訊息已提交的響應，它幾乎沒有選擇，只能重新傳送訊息。這提供了至少一次的交付語義，因為如果原始請求事實上已經成功，訊息可能會在重新傳送期間再次寫入日誌。從0.11.0.0開始，Kafka生產者也支援冪等傳遞選項，它保證重新傳送不會導致日誌中的重複條目。為了實現這一點，broker為每個生產者分配一個ID，並使用生產者隨每條訊息一起傳送的序列號對訊息進行重複複製。同時從0.11.0.0開始，生產者支援使用類似事務的語義向多個主題分割槽傳送訊息：即要麼所有訊息都成功寫入，要麼都沒有。主要的用例是Kafka主題之間的精確一次處理（如下所述）。

並非所有的用例都需要如此強大的保證。對於延遲敏感的用例，我們允許生產者指定它想要的耐久性級別。如果生產者指定它希望等待訊息被提交，這可能需要10毫秒的時間。然而，生產者也可以指定它想完全非同步地執行傳送，或者它想只等待直到領導者（但不一定是跟隨者）得到訊息。

現在讓我們從消費者的角度來描述語義。所有的副本都有完全相同的日誌，有相同的偏移量。消費者控制它在這個日誌中的位置。如果消費者從來沒有崩潰過，它可以只把這個位置儲存在記憶體中，但是如果消費者失敗了，我們希望這個主題分割槽被另一個程式接管，新的程式就需要選擇一個合適的位置，從這個位置開始處理。比方說，消費者讀取了一些訊息--它有幾個選擇來處理這些訊息並更新它的位置。

1. 它可以讀取訊息，然後將其位置儲存在日誌中，最後處理訊息。在這種情況下，消費者程式有可能在儲存其位置後但在儲存其訊息處理的輸出之前崩潰。在這種情況下，接手處理的程式將從儲存的位置開始，即使在該位置之前的幾個報文還沒有被處理。這對應於 "最多一次 "的語義，因為在消費者失敗的情況下，訊息可能不會被處理。
2. 它可以讀取訊息，處理訊息，最後儲存自己的位置。在這種情況下，消費者程式有可能在處理完訊息後但在儲存位置之前崩潰。在這種情況下，當新程式接手時，它收到的前幾個報文已經被處理過了。這對應於消費者失敗時的 "at-least-once "語義。在許多情況下，訊息有一個主鍵，因此更新是冪等的（兩次收到相同的訊息只是用另一個副本覆蓋了一條記錄）。

那麼到底一次語義（即你真正想要的東西）呢？當從一個Kafka主題中消費並生產到另一個主題時（如在Kafka Streams應用中），我們可以利用上面提到的0.11.0.0中新的事務生產者功能。消費者的位置作為訊息儲存在一個主題中，所以我們可以在同一個事務中把偏移量寫到Kafka，與接收處理資料的輸出主題一樣。如果事務中止，消費者的位置將恢復到舊值，輸出主題上產生的資料將對其他消費者不可見，這取決於他們的 "隔離級別"。在預設的 "read_uncommitted "隔離級別中，所有的訊息對消費者都是可見的，即使它們是被中止的事務的一部分，但在 "read_committed "中，消費者將只返回來自已提交的事務的訊息（以及任何不屬於事務的訊息）。

當向外部系統寫入時，其侷限性在於需要協調消費者的位置與實際儲存的輸出內容。實現這一目標的經典方法是在消費者位置的儲存和消費者輸出的儲存之間引入一個兩階段的提交。但這可以通過讓消費者將其偏移量儲存在與其輸出相同的地方來處理，更加簡單和普遍。這樣做比較好，因為消費者可能要寫入的許多輸出系統都不會支援兩階段提交。作為一個例子，考慮一個Kafka Connect聯結器，它在HDFS中填充資料的同時，也填充了它所讀取的資料的偏移量，這樣就可以保證資料和偏移量都更新，或者都不更新。我們對許多其他資料系統遵循類似的模式，這些系統需要這些更強的語義，而且對於這些系統來說，訊息沒有一個主鍵來允許重複資料刪除。

因此，有效地，Kafka支援Kafka Streams中的精確一交，當在Kafka主題之間傳輸和處理資料時，事務性生產者/消費者可以被普遍用於提供精確一交。對於其他目的系統的精確一次交付一般需要與這些系統合作，但Kafka提供了偏移，使得實現這一功能是可行的（另見Kafka Connect）。否則，Kafka預設保證最多一次交付，並允許使用者在處理一批訊息之前，通過在生產者上禁用重試和在消費者中提交偏移來實現最多一次交付。

 

4.7 副本

Kafka將每個主題的分割槽的日誌複製到可配置數量的伺服器上（你可以按主題設定這個複製因子）。這樣當叢集中的一臺伺服器出現故障時，可以自動將故障轉移到這些複製件上，這樣在出現故障時訊息仍然可用。

其他訊息系統也提供了一些與複製相關的功能，但是，在我們（完全有偏見）看來，這似乎是一個附加的東西，並沒有被大量使用，而且有很大的弊端：複製體不活躍，吞吐量受到嚴重影響，需要繁瑣的手動配置等等。Kafka是要預設使用複製的--事實上，我們把未複製的topic實現為複製的topic，複製因子為1。

複製的單位是主題分割槽。在非故障條件下，Kafka中的每個分割槽都有一個領導者和零個或多個跟隨者。包括leader在內的複製總數構成複製因子。所有的讀和寫都要到分割槽的領導者那裡去。通常情況下，分割槽的數量比broker多得多，領袖在broker中均勻分佈。跟隨者的日誌與領導者的日誌完全相同--所有的日誌都有相同的偏移量，訊息的順序也相同（當然，在任何時候，領導者的日誌末尾可能有一些尚未複製的訊息）。

跟隨者就像普通的Kafka消費者一樣從領導者那裡消費訊息，並將它們應用到自己的日誌中。讓追隨者從領導者那裡拉取訊息有一個很好的特性，即允許追隨者自然地將他們應用到自己的日誌中的日誌條目批量化。

與大多數分散式系統一樣，自動處理故障需要對一個節點的 "活著 "的含義有一個精確的定義。對於Kafka來說，節點的活潑度有兩個條件

1. 一個節點必須能夠維持它與ZooKeeper的會話（通過ZooKeeper的心跳機制）。
2. 如果它是一個跟隨者，它必須複製發生在領導者身上的寫法，而不是 "太遠 "地落在後面。

我們將滿足這兩個條件的節點稱為 "同步"，以避免 "活著 "或 "失敗 "的模糊性。領導者會跟蹤 "同步 "節點的集合。如果一個跟隨者死亡、卡住或落後，領導者會將其從同步副本列表中移除。卡住和滯後的副本的確定由 replica.lag.time.max.ms 配置控制。
在分散式系統術語中，我們只嘗試處理 "失敗/恢復 "模型的故障，即節點突然停止工作，然後再恢復（可能不知道自己已經死亡）。Kafka不處理所謂的 "拜占庭 "故障，在這種情況下，節點會產生任意或惡意的響應（也許是由於bug或犯規）。

我們現在可以更精確地定義，當該分割槽的所有同步複製體都將訊息應用到它們的日誌中時，該訊息就被認為是已提交的。只有已提交的訊息才會被提供給消費者。這意味著消費者不需要擔心可能會看到一條訊息，如果領導者失敗，這條訊息就會丟失。另一方面，生產者可以選擇等待訊息提交或不提交，這取決於他們對延遲和耐用性之間權衡的偏好。這個偏好由生產者使用的 acks 設定控制。請注意，主題有一個設定，當生產者請求確認訊息已經寫入全部同步副本集時，會檢查同步副本的 "最小數量"。如果生產者請求一個不那麼嚴格的確認，那麼即使in-synchronic replicas的數量低於最小值（比如可以低到只有leader），訊息也可以被提交，並被消費。

Kafka提供的保證是，只要至少有一個在同步副本活著，在任何時候，提交的訊息都不會丟失。

Kafka在經過短暫的故障切換期後，在節點故障的情況下仍能保持可用，但在網路分割槽的情況下可能無法保持可用。

 

重複的日誌：ISRs叢集, 以及狀態機器

Kafka分割槽的核心是一個複製日誌。複製日誌是分散式資料系統中最基本的基元之一，實現複製日誌的方法有很多。複製日誌可以被其他系統作為一個基元來實現其他分散式系統的狀態機風格。
複製日誌模擬了對一系列值的順序達成共識的過程（一般將日誌條目編號為0，1，2，...）。有很多方法可以實現，但最簡單和最快的是由一個領導者選擇提供給它的值的順序。只要領導者還活著，所有的跟隨者只需要複製領導者選擇的值和排序。

當然，如果領導者不失敗，我們就不需要追隨者了! 當領袖真的死了，我們需要從追隨者中選擇一個新的領袖。但是追隨者本身可能會落後或者崩潰，所以我們必須保證選擇一個最新的追隨者。一個日誌複製演算法必須提供的基本保證是，如果我們告訴客戶端一個訊息被提交，而領導者失敗了，我們選出的新領導者也必須有這個訊息。這就產生了一個權衡：如果領導者等待更多的追隨者確認一條訊息後再宣佈它已提交，那麼就會有更多潛在的可選領導者。

如果你選擇確認所需的數量和必須比較的日誌數量來選舉一個領導者，這樣就保證了有一個重疊，那麼這就叫做Quorum。

對於這種權衡，一個常見的方法是在提交決定和領袖選舉中都使用多數票。這不是Kafka所做的，但我們還是來探討一下，以瞭解其中的權衡。假設我們有2f+1個副本。如果f+1個複製體必須在領導者宣佈提交之前收到一條訊息，如果我們通過選舉至少f+1個複製體中日誌最完整的跟隨者來選舉新的領導者，那麼，在不超過f次失敗的情況下，領導者可以保證擁有所有的提交訊息。這是因為在任何f+1個副本中，一定有至少一個副本包含所有已提交的訊息。該副本的日誌將是最完整的，因此將被選為新的領導者。還有很多其餘的細節，每個演算法都必須處理（比如精確定義什麼使日誌更完整，在領導者失敗時確保日誌的一致性，或者改變副本集的伺服器集），但我們暫時忽略這些。

這種多數票的方法有一個非常好的特性：延遲只依賴於最快的伺服器。也就是說，如果複製因子為三，延遲是由速度更快的跟隨者決定的，而不是由速度較慢的跟隨者決定的。

這個系列的演算法非常豐富，包括ZooKeeper的Zab、Raft和Viewstamped Replication。據我們所知，與Kafka實際實現最相似的學術刊物是微軟的PacificA。

多數票的缺點是，不需要很多次失敗就可以讓你沒有可選的領導者。要容忍一次失敗需要三份資料，要容忍兩次失敗需要五份資料。根據我們的經驗，只擁有足夠的冗餘來容忍一次故障，對於一個實用的系統來說是不夠的，但是每一次寫都要做五次，對磁碟空間的要求是5倍，吞吐量是1/5，對於大批量的資料問題來說是不太實用的。這可能就是為什麼在ZooKeeper等共享叢集配置中更多的出現配額演算法，但在主資料儲存中卻不常見的原因。例如在HDFS中，namenode的高可用性功能是建立在基於多數票的日記上，但這種比較昂貴的方法並沒有用於資料本身。

Kafka在選擇其法定人數集時採取了一種稍微不同的方法。Kafka不採用多數票，而是動態地維護了一組追趕上領導者的同步副本（ISR）。只有這個集合的成員才有資格當選為領導者。對Kafka分割槽的寫入，在所有同步複製體收到寫入之前，不被認為是提交。每當ISR集發生變化時，這個ISR集就會被持久化到ZooKeeper上。正因為如此，ISR中的任何副本都有資格當選為領導者。這對於Kafka的使用模型來說是一個重要的因素，因為在Kafka的使用模型中，有很多分割槽，確保領導力的平衡是很重要的。有了這個ISR模型和f+1個副本，一個Kafka主題可以容忍f次失敗而不會丟失已提交的訊息。

 

對於我們希望處理的大多數用例，我們認為這種權衡是合理的。在實踐中，為了容忍f次失敗，多數票和ISR方法都會在提交訊息之前等待相同數量的副本確認（例如，為了在一次失敗中倖存下來，多數票需要三個副本和一個確認，而ISR方法需要兩個副本和一個確認）。在沒有最慢伺服器的情況下提交的能力是多數票方式的一個優勢。然而，我們認為，通過允許客戶端選擇是否在訊息提交時阻塞，可以改善這種情況，由於較低的所需複製因子而帶來的額外吞吐量和磁碟空間是值得的。

另一個重要的設計區別是，Kafka不要求崩潰的節點在恢復時所有資料都完好無損。在這個空間中，複製演算法依賴於 "穩定儲存 "的存在，在任何故障恢復情況下都不能丟失，而不會出現潛在的一致性違反，這並不罕見。這種假設有兩個主要問題。首先，磁碟錯誤是我們在永續性資料系統的實際執行中觀察到的最常見的問題，它們往往不會讓資料保持完整。其次，即使這不是問題，我們也不希望要求在每次寫入時都使用fsync來保證我們的一致性，因為這會使效能降低兩到三個數量級。我們允許一個副本重新加入ISR的協議確保在重新加入之前，即使它在崩潰中丟失了未重新整理的資料，也必須再次完全重新同步。

 

不乾淨的領袖選舉。如果他們都死了怎麼辦？

請注意，Kafka對資料丟失的保證是以至少一個副本保持同步為前提的。如果複製一個分割槽的所有節點都死了，這個保證就不再成立。
然而一個實用的系統需要在所有的複製體都死掉的時候做一些合理的事情。如果你很不走運地發生了這種情況，就要考慮會發生什麼。有兩種行為可以實現。

1. 等待ISR中的一個副本復活，然後選擇這個副本作為領導者（希望它還有所有資料）。
2. 選擇第一個恢復生命的副本（不一定在ISR中）作為領導者。

這是可用性和一致性之間的簡單權衡。如果我們在ISR中等待副本，那麼只要這些副本當機，我們就會一直不可用。如果這樣的副本被破壞或者它們的資料丟失，那麼我們就會永久當機。另一方面，如果一個非同步的副本恢復了生命，我們允許它成為領導者，那麼它的日誌就會成為真理的來源，即使它不能保證擁有每一條提交的訊息。從0.11.0.0版本開始，預設情況下，Kafka會選擇第一種策略，並偏向於等待一個一致的副本。這種行為可以使用配置屬性unclean.leader.election.enable進行更改，以支援正常執行時間優於一致性的用例。

這個難題並不是Kafka特有的。它存在於任何基於法定人數的方案中。例如，在多數投票方案中，如果大多數伺服器遭遇永久性故障，那麼你必須選擇失去100%的資料，或者違反一致性，將現有伺服器上剩餘的資料作為新的真理來源。

可用性和耐用性保證

當向Kafka寫入訊息時，生產者可以選擇是等待訊息被0,1還是所有（-1）複製體確認。請注意，"所有副本的確認 "並不能保證所有分配的副本都收到了訊息。預設情況下，當acks=all時，只要當前所有同步的副本都收到了訊息，就會發生確認。例如，如果一個主題只配置了兩個副本，而其中一個失敗了（即只剩下一個同步副本），那麼指定acks=all的寫入將成功。但是，如果剩餘的副本也發生故障，這些寫入可能會丟失。雖然這確保了分割槽的最大可用性，但對於一些喜歡耐久性而不是可用性的使用者來說，這種行為可能是不可取的。因此，我們提供了兩種主題級配置，可以用來優先選擇訊息耐久性而不是可用性。

1. Disable unclean leader election - 如果所有的副本都變得不可用，那麼分割槽將保持不可用，直到最近的領導者再次變得可用。這有效地優先考慮了不可用性而不是訊息丟失的風險。請參閱上一節 "不乾淨的領導者選舉 "進行說明。
2. 指定最小ISR大小--只有當ISR的大小超過某個最小值時，分割槽才會接受寫入，以防止只寫入一個副本的訊息丟失，而這個副本隨後變得不可用。這個設定只有在生產者使用acks=all，並保證訊息至少會被這麼多的in-synchronic replicas承認的情況下才會生效。這個設定提供了一致性和可用性之間的權衡。更高的最小ISR大小設定保證了更好的一致性，因為訊息被保證寫入更多的副本，從而降低了訊息丟失的概率。然而，它降低了可用性，因為如果同步副本的數量降到最小閾值以下，分割槽將不可用於寫入。

副本管理

上面關於複製日誌的討論其實只涉及到一個日誌，即一個主題分割槽。然而一個Kafka叢集將管理成百上千的這些分割槽。我們試圖以輪迴的方式平衡叢集內的分割槽，以避免將高容量主題的所有分割槽集中在少數節點上。同樣，我們也試圖平衡領導力，使每個節點在其分割槽中按比例成為領導者。

優化領導力選舉過程也很重要，因為那是不可用的關鍵視窗。領導者選舉的天真實現最終會在一個節點失敗時，為該節點託管的所有分割槽進行每個分割槽的選舉。取而代之的是，我們選擇其中一個broker作為 "控制器"。這個控制器在broker級別檢測故障，並負責改變故障broker中所有受影響分割槽的leader。其結果是，我們能夠將許多所需的領導層變更通知批處理在一起，這使得選舉過程對於大量的分割槽來說更加便宜和快速。如果控制器失敗，其中一個倖存的broker將成為新的控制器。

 

4.8 日誌壓縮

日誌壓實確保Kafka將始終為單個主題分割槽的資料日誌內的每個訊息鍵保留至少最後一個已知值。它解決了一些用例和場景，如在應用崩潰或系統故障後恢復狀態，或在執行維護期間重啟應用後過載快取。讓我們更詳細地深入瞭解這些用例，然後描述壓實的工作原理。

到目前為止，我們只描述了較簡單的資料保留方法，即在固定時間後或當日志達到某個預定大小時，舊的日誌資料將被丟棄。這對於時間性事件資料，比如每條記錄都是獨立存在的記錄，效果很好。然而一類重要的資料流是鍵控的、可突變的資料的變化日誌（例如，資料庫表的變化）。

 

我們來討論一下這種資料流的一個具體例子。假設我們有一個包含使用者電子郵件地址的主題；每次使用者更新他們的電子郵件地址時，我們都會使用他們的使用者id作為主鍵向這個主題傳送一條訊息。現在假設我們在一段時間內為一個id為123的使用者傳送以下訊息，每條訊息對應於一個電子郵件地址的變化（其他id的訊息省略）。

 

       123 => bill@microsoft.com
                .
                .
                .
        123 => bill@gatesfoundation.org
                .
                .
                .
        123 => bill@gmail.com

日誌壓縮為我們提供了一個更細化的保留機制，這樣我們就可以保證至少保留每個主鍵的最後一次更新（例如：bill@gmail.com）。通過這樣做，我們保證日誌中包含了每個鍵的最終值的完整快照，而不僅僅是最近改變的鍵。這意味著下游消費者可以在這個主題之外恢復他們自己的狀態，而無需我們保留所有變化的完整日誌。

讓我們先看幾個有用的用例，然後再看看如何使用它。

1. 資料庫變更訂閱。經常需要在多個資料系統中擁有一個資料集，而這些系統中經常有一個是某種資料庫（無論是RDBMS還是可能是一個新式的鍵值儲存）。例如你可能有一個資料庫、一個快取、一個搜尋叢集和一個Hadoop叢集。資料庫的每一次變化都需要反映在快取、搜尋叢集中，最終反映在Hadoop中。在一個只處理實時更新的情況下，你只需要最近的日誌。但如果你想能夠重新載入快取或恢復失敗的搜尋節點，你可能需要一個完整的資料集。
2. 事件來源。這是一種將查詢處理與應用設計共存的應用設計風格，並將變化日誌作為應用的主要儲存。
3. 高可用性的日誌。一個進行本地計算的程式，可以通過記錄出它對本地狀態的變化，使其具有容錯性，這樣另一個程式就可以重新載入這些變化，並在失敗時繼續進行。一個具體的例子是處理流查詢系統中的計數、聚合和其他類似 "group by "的處理。Samza，一個實時流處理框架，正是為了這個目的而使用了這個功能。

 

在這些情況下，人們主要需要處理變化的實時饋送，但偶爾，當機器崩潰或資料需要重新載入或重新處理時，人們需要進行全面載入。日誌壓縮允許將這兩種用例從同一個支援主題上進行反饋。這種日誌的使用方式在這篇博文中會有更詳細的介紹。

總體思路很簡單。如果我們有無限的日誌保留，並且我們記錄了上述情況下的每一個變化，那麼我們就會捕捉到系統從最初開始時每一個時間的狀態。利用這個完整的日誌，我們可以通過重放日誌中的前N條記錄來還原到任何時間點。這種假設的完整日誌對於多次更新一條記錄的系統來說，並不是很實用，因為即使對於一個穩定的資料集，日誌也會無限制的增長。簡單的日誌保留機制將舊的更新扔掉，會約束空間，但日誌不再是恢復當前狀態的方法，現在從日誌開始恢復不再重現當前狀態，因為舊的更新可能根本沒有被捕獲。

 

日誌壓實是一種機制，給每個記錄提供更細粒度的保留，而不是更粗粒度的基於時間的保留。這個想法是有選擇地刪除我們有相同主鍵的最近更新的記錄。這樣就可以保證日誌至少有每個鍵的最後狀態。

 

這個保留策略可以按主題設定，所以一個叢集可以有一些主題是通過大小或時間來執行保留，而其他主題則是通過壓實來執行保留。

 

這個功能的靈感來自於LinkedIn最古老也是最成功的基礎設施之一--名為Databus的資料庫changelog快取服務。與大多數日誌結構的儲存系統不同，Kafka是為訂閱而構建的，並組織資料進行快速線性讀寫。與Databus不同的是，Kafka作為一個真實源儲存，因此即使在上游資料來源無法以其他方式重放的情況下，它也很有用。

 

日誌壓縮基礎

這裡是一張高階圖片，顯示了Kafka日誌的邏輯結構，以及每個訊息的偏移量。

 

 

日誌的頭部與傳統的Kafka日誌相同。它有密集的順序偏移，並保留所有訊息。日誌壓實增加了一個處理日誌尾部的選項。上圖顯示的是一個帶有壓縮尾巴的日誌。請注意，日誌尾部的訊息保留了首次寫入時分配的原始偏移量，這一點永遠不會改變。還需要注意的是，所有的偏移量在日誌中仍然是有效的位置，即使帶有該偏移量的訊息已經被壓縮掉了；在這種情況下，這個位置與日誌中出現的下一個最高偏移量是無法區分的。例如，在上圖中，偏移量36、37和38都是等價的位置，從這些偏移量中的任何一個開始讀取，都會返回一個從38開始的訊息集。

 

壓實還允許刪除。一個帶有鍵和空有效載荷的訊息將被視為從日誌中刪除。這種記錄有時被稱為墓碑。這個刪除標記會導致之前任何帶有該鍵的訊息被刪除（就像任何帶有該鍵的新訊息一樣），但刪除標記是特殊的，因為它們本身會在一段時間後從日誌中清理出來以釋放空間。在上圖中，將不再保留刪除的時間點標記為 "刪除保留點"。

 

壓實是在後臺通過定期重新複製日誌段來完成的。清理不會阻塞讀取，並且可以節流使用不超過可配置的 I/O 吞吐量，以避免影響生產者和消費者。實際壓縮日誌段的過程是這樣的。

 

 

 

 日誌壓縮有哪些保障？

日誌壓縮保證以下幾點。

1. 任何追趕到日誌頭部的消費者都會看到所寫的每一條訊息；這些訊息會有順序的偏移。題目中的min.compaction.lag.ms可以用來保證一個訊息被寫入後必須經過的最小時間長度，然後才能進行壓縮。即它提供了每個訊息在（未壓縮的）頭部停留時間的下限。topic的max.compaction.lag.ms可以用來保證從訊息被寫入到訊息有資格被壓實之間的最大延遲。
2. 訊息的順序總是被保持的。Compaction永遠不會重新排序訊息，只是刪除一些訊息。
3. 訊息的偏移量永遠不會改變。它是日誌中某個位置的永久識別符號。
4. 任何從日誌開始進展的消費者至少會看到所有記錄的最終狀態，其順序是按照它們被寫入的順序。此外，只要消費者在小於主題的delete.retain.ms設定（預設為24小時）的時間段內到達日誌的頭部，就會看到所有刪除記錄的刪除標記。換句話說：由於刪除標記的刪除是與讀取同時發生的，如果消費者的滯後時間超過delete.retention.ms，就有可能錯過刪除標記。

 

日誌壓縮的細節

日誌壓實由日誌清理器處理，它是一個後臺執行緒池，負責重新複製日誌段檔案，刪除鍵出現在日誌頭部的記錄。每個壓縮器執行緒的工作原理如下。

1. 它選擇日誌頭部和尾部比例最高的日誌。
2. 它為日誌頭部的每個鍵建立了一個簡明扼要的最後偏移量摘要。
3. 它從頭到尾重新複製日誌，刪除日誌中較晚出現的鍵。新的、乾淨的片段會立即被交換到日誌中，因此所需的額外磁碟空間只是一個額外的日誌片段（不是日誌的完整副本）。
4. 日誌頭的摘要本質上只是一個空間緊湊的雜湊表。它每個條目正好使用24個位元組。因此，如果有8GB的清理器緩衝區，一個清理器迭代可以清理大約366GB的日誌頭（假設有1k條訊息）。

 

配置日誌清理器

日誌清理器預設為啟用。這將啟動清理執行緒池。要在特定主題上啟用日誌清理，請新增特定於日誌的屬性

 log.cleanup.policy=compact

 

log.cleanup.policy屬性是在broker的server.properties檔案中定義的broker配置設定；它影響叢集中所有沒有配置覆蓋的主題，如這裡所描述的。日誌清理器可以被配置為保留最小數量的未壓縮的日誌 "頭部"。這可以通過設定壓實時間滯後來啟用。

  log.cleaner.min.compaction.lag.ms

 

這可以用來防止超過最小訊息年齡的訊息被壓縮。如果沒有設定，除了最後一個段，即當前正在寫入的段，所有日誌段都有資格進行壓實。即使活動段的所有訊息都超過了最小壓實時滯，也不會對其進行壓實。日誌清理器可以被配置為確保最大延遲，在此延遲之後，未壓縮的日誌 "頭 "才有資格進行日誌壓縮。

 log.cleaner.max.compaction.lag.ms

 

此項可用於防止產生率較低的日誌在無限制的時間內不符合壓實條件。如果不設定，不超過min.cleanable.dirty.ratio的日誌將不會被壓實。請注意，這個壓實期限並不是一個硬性保證，因為它仍然受制於日誌清理執行緒的可用性和實際壓實時間。你要監控uncleanable-partitions-count、max-clean-time-secs和max-compaction-delay-secs指標。

更多的清理器配置在這裡介紹。

 

4.9 配額

Kafka叢集具有對請求執行配額的能力，以控制客戶端使用的經紀資源。Kafkabroker可以為每一組共享配額的客戶執行兩種型別的客戶配額。

1. 網路頻寬配額定義了位元組速率閾值（從0.9開始）。
2. 請求率配額定義了CPU利用率閾值，作為網路和I/O執行緒的百分比(自0.11起)

為什麼要有配額？

生產者和消費者有可能產生/消耗非常大的資料量，或者以非常高的速度產生請求，從而壟斷broker的資源，造成網路飽和，並且通常會使其他客戶和broker自己陷入困境。擁有配額可以防止這些問題，在大型多租戶叢集中就更加重要了，因為一小撮表現不好的客戶端會降低表現好的客戶端的使用者體驗。事實上，當Kafka作為服務執行時，這甚至可以根據商定的合同來執行API限制。

 

客戶端組

Kafka客戶端的身份是使用者principal，它代表安全叢集中的認證使用者。在支援非認證客戶機的叢集中，使用者委託人是由代理使用可配置的PrincipalBuilder選擇的非認證使用者的分組。Client-id是由客戶端應用程式選擇的具有有意義的名稱的客戶端的邏輯分組。元組(user，client-id)定義了一個安全的客戶機邏輯組，該組共享使用者Principal和client-id。

配額可以應用於(使用者，客戶端-id)、使用者或客戶端-id組。對於給定的連線，將應用與該連線匹配的最具體的配額。配額組的所有連線共享為該組配置的配額。例如，如果(user="test-user"，client-id="test-client")的生產配額為10MB/秒，則所有使用者 "test-user "和client-id "test-client "的生產者例項都會共享這個配額。

 

配額設定

配額配置可以為(使用者、客戶端-id)、使用者和客戶端-id組定義。可以在任何一個需要更高（甚至更低）配額的配額級別覆蓋預設配額。機制類似於每主題日誌配置覆蓋。使用者和(使用者，客戶機ID)配額覆蓋寫在/config/users下，客戶機ID配額覆蓋寫在/config/clients下。這些覆寫會被所有的broker讀取並立即生效。這讓我們可以改變配額，而無需對整個叢集進行滾動重啟。詳情請看這裡。每個組的預設配額也可以使用相同的機制動態更新。

配額配置的優先順序是。

1. /config/users/<user>/clients/<client-id>
2. /config/users/<user>/clients/<default>
3. /config/users/<user>
4. /config/users/<default>/clients/<client-id>
5. /config/users/<default>/clients/<default>
6. /config/users/<default>
7. /config/clients/<client-id>
8. /config/clients/<default>

broker屬性（quota.producer.default，quota.consumer.default）也可用於為客戶端id組設定網路頻寬配額的預設值。這些屬性正在被廢棄，並將在以後的版本中被移除。客戶端-id的預設配額可以在Zookeeper中設定，類似於其他配額覆蓋和預設值。

 

網路頻寬配額

網路頻寬配額被定義為每組共享配額的客戶機的位元組速率閾值。預設情況下，每個獨特的客戶機組都會收到群集配置的以位元組/秒為單位的固定配額。該配額是以每個代理為基礎定義的。每組客戶機在客戶機被節流之前，每個broker最多可以釋出/獲取X個位元組/秒的配額。

 

請求速率配額

請求率配額是指在一個配額視窗內，客戶端在請求處理機I/O執行緒和每個代理的網路執行緒上可以利用的時間百分比。n%的配額代表一個執行緒的n%，所以配額出的總容量為((num.io.threads+num.network.threads)*100)%。每組客戶機在被節流之前，可以在一個配額視窗中的所有I/O和網路執行緒中使用最多n%的總百分比。由於分配給I/O和網路執行緒的執行緒數通常基於broker主機上可用的核心數，因此請求率配額代表了每組共享配額的客戶機可能使用的CPU的總百分比。

 

強制

預設情況下，每個獨特的客戶組都會收到群集配置的固定配額。這個配額是以每個代理為基礎定義的。每個客戶端在被節流之前可以利用每個代理的這個配額。我們決定，定義每個broker的這些配額比為每個客戶端提供固定的叢集範圍頻寬要好得多，因為這需要一個機制來在所有broker之間共享客戶端配額使用情況。這可能比配額實現本身更難搞好!

當broker檢測到配額違規時，它是如何反應的？在我們的解決方案中，broker首先計算出使違規客戶端低於配額所需的延遲量，並立即返回一個帶有延遲量的響應。在獲取請求的情況下，響應將不包含任何資料。然後，代理會將通往客戶端的通道靜音，不再處理客戶端的請求，直到延遲結束。在收到一個非零延遲持續時間的響應後，Kafka客戶端也會在延遲期間不再向broker傳送請求。因此，來自節流客戶端的請求會被雙方有效地阻止。即使是不尊重broker的延遲響應的舊客戶端實現，broker通過靜音其socket通道施加的背壓仍然可以處理表現不好的客戶端的節流。那些進一步向節流通道傳送請求的客戶端將在延遲結束後才收到響應。

位元組率和執行緒利用率在多個小視窗（例如30個視窗，每個視窗1秒）中進行測量，以便快速檢測和糾正違反配額的情況。通常情況下，擁有大的測量視窗（例如10個視窗，每個視窗30秒）會導致大的流量爆發，然後是長時間的延遲，這在使用者體驗方面不是很好。

 

 

5. 實現

5.1 網路層

網路層是一個相當直接的NIO伺服器，就不詳細介紹了。sendfile的實現是通過給MessageSet介面一個writeTo方法來完成的。這樣就可以讓檔案支援的訊息集使用效率更高的transferTo實現，而不是程式內緩衝寫。執行緒模型是一個接受者執行緒和N個處理器執行緒，每個執行緒處理固定數量的連線。這種設計已經在其他地方進行了相當徹底的測試，發現它的實現簡單而快速。協議保持相當簡單，以便於將來用其他語言實現客戶端。

 

5.2 訊息

訊息由一個可變長度的頭、一個可變長度的不透明金鑰位元組陣列和一個可變長度的不透明值位元組陣列組成。報文頭的格式在下一節中描述。讓鍵和值不透明是一個正確的決定：現在序列化庫取得了很大的進展，任何特定的選擇都不可能適合所有的用途。不用說一個使用Kafka的特定應用很可能會強制要求將特定的序列化型別作為其使用的一部分。RecordBatch介面只是一個訊息的迭代器，有專門的方法用於批量讀寫NIO通道。

 

5.3 訊息格式

訊息（也就是記錄）總是分批寫入的。訊息批的技術術語是記錄批，一個記錄批包含一條或多條記錄。在退化的情況下，我們可以讓一個記錄批包含一條記錄。記錄批和記錄都有自己的標題。下面將介紹每種格式。

 

5.3.1 記錄批次

以下是RecordBatch的磁碟格式。

 

		baseOffset: int64
		batchLength: int32
		partitionLeaderEpoch: int32
		magic: int8 (current magic value is 2)
		crc: int32
		attributes: int16
			bit 0~2:
				0: no compression
				1: gzip
				2: snappy
				3: lz4
				4: zstd
			bit 3: timestampType
			bit 4: isTransactional (0 means not transactional)
			bit 5: isControlBatch (0 means not a control batch)
			bit 6~15: unused
		lastOffsetDelta: int32
		firstTimestamp: int64
		maxTimestamp: int64
		producerId: int64
		producerEpoch: int16
		baseSequence: int32
		records: [Record]

需要注意的是，當啟用壓縮功能時，壓縮後的記錄資料直接按照記錄數的計數進行序列化。

CRC涵蓋了從屬性到批次結束的資料（即CRC之後的所有位元組）。它位於魔法位元組之後，這意味著客戶端必須先解析魔法位元組，然後再決定如何解釋批次長度和魔法位元組之間的位元組。在CRC計算中不包括分割槽首領時間欄位，以避免當該欄位被分配給broker接收的每個批次時，需要重新計算CRC。計算時採用CRC-32C（Castagnoli）多項式。

關於壓實：與舊的訊息格式不同，magic v2及以上版本在清理日誌時保留了原始批次的首尾偏移量/序列號。這是為了在重新載入日誌時能夠恢復生產者的狀態而需要的。例如，如果我們沒有保留最後一個序列號，那麼在分割槽領導失敗後，生產者可能會看到一個OutOfSequence錯誤。為了進行重複檢查，必須保留基本序列號（broker通過驗證傳入批次的第一個和最後一個序列號與該生產者的最後一個序列號相匹配來檢查傳入的Produce請求是否有重複）。因此，當批中的所有記錄都被清理，但為了保留生產者的最後一個序列號，批仍被保留時，日誌中就有可能出現空批。這裡有一個奇怪的地方，就是在壓實過程中不保留firstTimestamp欄位，所以如果批中的第一條記錄被壓實掉，它就會改變。

 

5.3.1.1 控制批次

一個控制批包含一條記錄，稱為控制記錄。控制記錄不應傳遞給應用程式。相反，它們被消費者用來過濾掉中止的事務性訊息。

控制記錄的鍵符合以下模式。

       version: int16 (current version is 0)
       type: int16 (0 indicates an abort marker, 1 indicates a commit)

控制記錄的值的模式取決於型別。該值對客戶來說是不透明的。

 

5.3.2 記錄

Kafka 0.11.0中引入了記錄級標頭檔案。帶頭記錄的磁碟格式如下。

 

		length: varint
		attributes: int8
			bit 0~7: unused
		timestampDelta: varint
		offsetDelta: varint
		keyLength: varint
		key: byte[]
		valueLen: varint
		value: byte[]
		Headers => [Header]

 

 

5.3.2.1 記錄頭

		headerKeyLength: varint
		headerKey: String
		headerValueLength: varint
		Value: byte[]

 

 

我們使用與Protobuf相同的varint編碼。關於後者的更多資訊可以在這裡找到。記錄中的頭數也是以varint編碼的。

 

5.3.3 舊的資訊格式

在Kafka 0.11之前，訊息是以訊息集的形式傳輸和儲存的。在訊息集中，每個訊息都有自己的後設資料。需要注意的是，雖然訊息集以陣列的形式表示，但並不像協議中的其他陣列元素那樣，前面有一個int32陣列大小。

 

訊息集合：

    MessageSet (Version: 0) => [offset message_size message]
        offset => INT64
        message_size => INT32
        message => crc magic_byte attributes key value
            crc => INT32
            magic_byte => INT8
            attributes => INT8
                bit 0~2:
                    0: no compression
                    1: gzip
                    2: snappy
                bit 3~7: unused
            key => BYTES
            value => BYTES

 

MessageSet (Version: 1) => [offset message_size message]
        offset => INT64
        message_size => INT32
        message => crc magic_byte attributes timestamp key value
            crc => INT32
            magic_byte => INT8
            attributes => INT8
                bit 0~2:
                    0: no compression
                    1: gzip
                    2: snappy
                    3: lz4
                bit 3: timestampType
                    0: create time
                    1: log append time
                bit 4~7: unused
            timestamp => INT64
            key => BYTES
            value => BYTES

 

在Kafka 0.10之前的版本中，唯一支援的訊息格式版本（用魔力值表示）是0，0.10版本中引入了訊息格式版本1，並支援時間戳。

• 與上面的版本2類似，屬性的最低位代表壓縮型別。
• 在版本1中，生產者應該始終將時間戳型別位設定為0，如果主題被配置為使用日誌追加時間，（通過broker級別配置log.message.timestamp.type = LogAppendTime或主題級別配置message.timestamp.type = LogAppendTime），broker將覆蓋時間戳型別和訊息集中的時間戳。
• 屬性的最高位必須設定為0。

在訊息格式版本0和1中，Kafka支援遞迴訊息以實現壓縮。在這種情況下，訊息的屬性必須被設定為指示壓縮型別之一，並且值域將包含用該型別壓縮的訊息集。我們通常將巢狀訊息稱為 "內部訊息"，將封裝訊息稱為 "外部訊息"。請注意，外層訊息的鍵應該是空的，其偏移量將是最後一個內部訊息的偏移量。

當接收遞迴的版本0訊息時，broker會對它們進行解壓，並且每個內部訊息都會單獨分配一個偏移量。在版本1中，為了避免伺服器端重新壓縮，只有包裝訊息將被分配一個偏移量。內部訊息將有相對的偏移量。絕對偏移量可以使用外層訊息的偏移量來計算，它對應於分配給最後一個內部訊息的偏移量。

crc欄位包含後續報文位元組的CRC32（而不是CRC-32C）（即從魔法位元組到值）。

 

5.4 日誌

一個名為 "my_topic "的主題的日誌有兩個分割槽，由兩個目錄（即my_topic_0和my_topic_1）組成，這兩個目錄中包含了該主題的訊息資料檔案。日誌檔案的格式是一個 "日誌條目 "的序列；每個日誌條目是一個4位元組的整數N，儲存訊息長度，後面是N個訊息位元組。每條訊息由一個64位整數偏移量唯一標識，給出該訊息在該分割槽上所有傳送到該主題的訊息流中開始的位元組位置。每條訊息的磁碟格式如下。每個日誌檔案都以它所包含的第一條訊息的偏移量命名。所以建立的第一個檔案將是000000000.kafka，每一個額外的檔案將有一個整數名，大約是前一個檔案的S位元組，其中S是配置中給出的最大日誌檔案大小。

 

記錄的確切二進位制格式是版本化的，並作為標準介面進行維護，因此在理想的情況下，記錄批次可以在生產者、broker和客戶端之間傳輸，而無需重新複製或轉換。上一節包括了關於記錄的磁碟格式的細節。

 

使用訊息偏移量作為訊息id是不尋常的。我們最初的想法是使用生產者生成的 GUID，並在每個broker上維護一個從 GUID 到偏移量的對映。但由於消費者必須為每個伺服器維護一個ID，所以GUID的全域性唯一性沒有提供任何價值。此外，維護從隨機id到偏移量的對映的複雜性，需要一個重磅的索引結構，而這個結構必須與磁碟同步，本質上需要一個完整的持久化隨機訪問資料結構。因此為了簡化查詢結構，我們決定使用一個簡單的每個分割槽原子計數器，它可以與分割槽id和節點id耦合，以唯一標識一個訊息；這使得查詢結構更簡單，儘管每個消費者請求仍有可能進行多次查詢。然而，一旦我們確定了計數器，直接使用偏移量似乎是很自然的--畢竟兩者都是分割槽唯一的單調遞增整數。由於偏移量被隱藏在消費者API中，這個決定最終是一個實現細節，我們選擇了更有效的方法。

 

 

 

 寫

日誌允許序列追加，它總是轉到最後一個檔案。當這個檔案達到一個可配置的大小（比如1GB）時，就會轉到一個新的檔案。日誌需要兩個配置引數。M，給出了在強制作業系統將檔案重新整理到磁碟之前要寫的資訊數量，S，給出了強制重新整理的秒數。這樣可以保證在系統崩潰時最多丟失M條訊息或S秒資料的耐久性。

 

讀

讀取是通過給定訊息的64位邏輯偏移量和S位元組的最大分塊大小來完成的，這將返回一個S位元組緩衝區中的訊息迭代器。這將返回一個迭代器，遍歷S位元組緩衝區中包含的訊息。S 位元組的大小要大於任何一條訊息，但如果訊息異常大，可以多次重試讀取，每次都將緩衝區大小加倍，直到訊息被成功讀取。可以指定一個最大的訊息和緩衝區大小，以使伺服器拒絕大於某個大小的訊息，並給客戶端一個最大的約束，它需要讀取一個完整的訊息。讀取的緩衝區很可能以部分訊息結束，這很容易通過大小分隔來檢測。

 

從偏移量讀取的實際過程，需要先定位資料存放的日誌段檔案，從全域性偏移量值中計算出特定檔案的偏移量，然後從該檔案偏移量中讀取。搜尋是以簡單的二進位制搜尋變化的方式，針對每個檔案維護的記憶體範圍進行的。

 

日誌提供了獲取最近寫的訊息的功能，以便客戶從 "現在 "開始訂閱。在消費者未能在其SLA規定的天數內消費其資料的情況下，這也很有用。在這種情況下，當客戶機試圖消費一個不存在的偏移量時，它將得到一個OutOfRangeException，並且可以根據用例的情況重置自己或失敗。

 

以下是傳送給消費者的結果的格式。

 

    MessageSetSend (fetch result)

    total length     : 4 bytes
    error code       : 2 bytes
    message 1        : x bytes
    ...
    message n        : x bytes

    MultiMessageSetSend (multiFetch result)

    total length       : 4 bytes
    error code         : 2 bytes
    messageSetSend 1
    ...
    messageSetSend n

 

 

刪除

每次刪除一個日誌段的資料。日誌管理器應用兩個指標來確定符合刪除條件的片段：時間和大小。對於基於時間的策略，會考慮記錄的時間戳，由分段檔案中最大的時間戳（記錄順序無關）定義整個分段的保留時間。基於大小的保留預設為禁用。啟用時，日誌管理器會不斷刪除最舊的段檔案，直到分割槽的整體大小再次在配置的限制範圍內。如果同時啟用了這兩個策略，則會刪除因任一策略而符合刪除條件的段。為了避免鎖定讀取，同時仍然允許修改段列表的刪除，我們使用了一種複製-寫式的段列表實現，它提供了一致的檢視，允許在刪除進行時，在日誌段的不可改變的靜態快照檢視上進行二進位制搜尋。

 

保障

日誌提供了一個配置引數M，它控制了在強制重新整理到磁碟之前寫入的最大訊息數量。在啟動時，會執行一個日誌恢復程式，該程式會遍歷最新日誌段中的所有訊息，並驗證每個訊息條目是否有效。如果訊息的大小和偏移量之和小於檔案的長度，並且訊息有效載荷的CRC32與訊息儲存的CRC相匹配，則訊息條目有效。如果檢測到損壞，日誌會被截斷到最後一個有效的偏移量。

 

請注意，必須處理兩種腐敗：截斷，其中一個未寫的塊由於崩潰而丟失，以及一個無意義的塊被新增到檔案中的腐敗。原因是一般情況下，作業系統不保證檔案inode和實際塊資料之間的寫入順序，所以如果inode更新了新的大小，但在寫入包含該資料的塊之前發生了崩潰，那麼除了丟失寫入資料外，檔案還可能獲得無意義資料。CRC可以檢測到這種角落的情況，並防止它破壞日誌（當然，未寫入的資訊會丟失）。

 

5.5 分配

消費者偏移量追蹤

Kafka消費者跟蹤它在每個分割槽中消耗的最大偏移量，並具有提交偏移量的能力，以便在重新啟動時可以從這些偏移量恢復。Kafka提供了一個選項，可以將某個消費者組的所有偏移量儲存在一個指定的broker(針對該組)中，稱為組協調器.也就是說，該消費者組中的任何消費者例項都應該將其偏移量提交和取回傳送到該組協調器(broker)。消費者組根據其組名被分配給協調器。消費者可以通過向任何Kafka broker發出FindCoordinatorRequest並讀取FindCoordinatorResponse來查詢它的協調人，FindCoordinatorResponse將包含協調人的詳細資訊。然後，消費者可以繼續從協調人broker那裡提交或獲取偏移量。如果協調器移動了，消費者需要重新發現協調器。偏移提交可以由消費者例項自動或手動完成。

 

當組協調器收到OffsetCommitRequest時，它會將請求附加到一個名為__consumer_offsets的特殊壓縮Kafka主題中。只有在offsets主題的所有副本都收到offsets之後，代理才會向消費者傳送一個成功的偏移提交響應。如果偏移量未能在可配置的超時內複製，偏移量提交將失敗，消費者可以在後退後重新嘗試提交。broker會定期壓縮偏移主題，因為它只需要維護每個分割槽的最新偏移提交。協調器還將偏移量快取在記憶體表中，以便快速服務於偏移量的獲取。

 

當協調器收到一個偏移獲取請求時，它只需從偏移快取中返回最後提交的偏移向量。在協調器剛剛啟動的情況下，或者如果它剛剛成為一組新的消費者組的協調器（通過成為偏移量主題分割槽的領導者），它可能需要將偏移量主題分割槽載入到快取中。在這種情況下，偏移量的獲取將以CoordinatorLoadInProgressException失敗，消費者可能會在後退後重新嘗試OffsetFetchRequest。

 

Zookeeper目錄

下面給出了ZooKeeper結構和用於協調消費者和broker的演算法。

 

符號

當一個路徑中的元素用[xyz]表示時，意味著xyz的值不是固定的，實際上xyz的每一個可能的值都有一個ZooKeeper znode。例如/topics/[topic]將是一個名為/topics的目錄，其中包含了每個主題名的子目錄。還給出了數字範圍，如[0...5]來表示子目錄0，1，2，3，4。箭頭->用來表示一個znode的內容。例如，/hello -> world表示一個包含 "world "的znode /hello。

 

broker節點註冊

    /brokers/ids/[0...N] --> {"jmx_port":...,"timestamp":...,"endpoints":[...],"host":...,"version":...,"port":...} (ephemeral node)

 

這是所有存在的 broker 節點的列表，每個節點都提供了一個唯一的邏輯 broker id，它可以向消費者標識它（必須作為其配置的一部分給出）。在啟動時，broker 節點通過在 /brokers/ids 下建立一個帶有邏輯 broker id 的 znode 來註冊自己。邏輯 broker id 的目的是允許 broker 移動到不同的物理機器上，而不影響消費者。試圖註冊一個已經在使用的broker id（比如說因為兩臺伺服器配置了相同的broker id）會導致錯誤。

由於broker在ZooKeeper中使用短暫的znodes註冊自己，這個註冊是動態的，如果broker被關閉或死亡，這個註冊就會消失（從而通知消費者它不再可用）。

 

broker主題註冊

    /brokers/topics/[topic]/partitions/[0...N]/state --> {"controller_epoch":...,"leader":...,"version":...,"leader_epoch":...,"isr":[...]} (ephemeral node)

 

每個broker在其維護的主題下注冊自己，並儲存該主題的分割槽數量。

 叢集ID

群集id是分配給Kafka群集的唯一且不可更改的識別符號。群集id最多可以有22個字元，允許的字元由正規表示式[a-zA-Z0-9_/9/\-]+定義，它對應於沒有填充的URL安全Base64變體所使用的字元。從概念上來說，它是在叢集第一次啟動時自動生成的。

 

在實現上，它是在第一次成功啟動0.10.1或更高版本的broker時生成的。broker在啟動過程中會嘗試從/cluster/id znode中獲取叢集id。如果znode不存在，broker會生成一個新的叢集id，並使用這個叢集id建立znode。

broker節點註冊

broker節點基本上是獨立的，所以它們只發布自己所擁有的資訊。當一個broker加入時，它在broker節點登錄檔目錄下注冊自己，並寫入自己的主機名和埠資訊。broker也會在broker主題登錄檔中註冊現有主題的列表及其邏輯分割槽。新的主題在broker上建立時是動態註冊的。

 

6.操作

以下是基於LinkedIn的使用情況和經驗，關於將Kafka作為生產系統實際執行的一些資訊。請將您知道的任何其他技巧傳送給我們。

6.1 Kafka基本操作

本節將回顧您將在Kafka叢集上執行的最常見的操作。本節回顧的所有工具都可以在Kafka發行版的bin/目錄下使用，如果執行時沒有引數，每個工具都會列印所有可能的命令列選項的詳細資訊。

新增和刪除主題

您可以選擇手動新增主題，或在資料首次釋出到不存在的主題時讓它們自動建立。如果主題是自動建立的，那麼你可能要調整用於自動建立主題的預設主題配置。
使用主題工具新增和修改主題。

 

 > bin/kafka-topics.sh --bootstrap-server broker_host:port --create --topic my_topic_name \
        --partitions 20 --replication-factor 3 --config x=y

複製因子控制有多少臺伺服器會複製每條被寫入的訊息。如果您的複製因子為3，那麼在您失去對資料的訪問之前，最多可以有2臺伺服器發生故障。我們建議您使用2或3的複製因子，這樣您就可以在不中斷資料消耗的情況下透明地跳轉機器。
分割槽數控制主題將被分片成多少個日誌。分割槽數有幾個影響。首先每個分割槽必須完全適合在一臺伺服器上。因此，如果你有20個分割槽，那麼全部資料集（以及讀寫負載）將由不超過20臺伺服器處理（不計算副本）。最後，分割槽數會影響你的消費者的最大並行性。這在概念部分有更詳細的討論。

每個分片分割槽的日誌都會被放置到Kafka日誌目錄下自己的資料夾中。這種資料夾的名稱由主題名稱、破折號（-）和分割槽id組成。由於一個典型的資料夾名不能超過255個字元，所以主題名的長度會有限制。我們假設分割槽的數量永遠不會超過100,000。因此，主題名不能超過249個字元。這就為資料夾名中的破折號和可能長達 5 位的分割槽 ID 留出了足夠的空間。

在命令列上新增的配置覆蓋了伺服器的預設設定，比如資料應該保留的時間長度。完整的按主題配置集在這裡有記載。

 

修改主題

您可以使用同一主題工具更改主題的配置或分割槽。
要新增分割槽，您可以執行以下操作

 

  > bin/kafka-topics.sh --bootstrap-server broker_host:port --alter --topic my_topic_name \
        --partitions 40

要知道，分割槽的一個用例是對資料進行語義上的分割槽，而新增分割槽並不會改變現有資料的分割槽，所以如果消費者依賴該分割槽，這可能會打擾到他們。也就是說，如果資料是按照hash(key) % number_of_partitions進行分割槽的，那麼這個分割槽將有可能通過新增分割槽來洗牌，但Kafka不會嘗試以任何方式自動重新分配資料。
要新增配置：

  > bin/kafka-configs.sh --bootstrap-server broker_host:port --entity-type topics --entity-name my_topic_name --alter --add-config x=y

 

要刪除一個配置：

  > bin/kafka-configs.sh --bootstrap-server broker_host:port --entity-type topics --entity-name my_topic_name --alter --delete-config x

 

最終刪除一個主題：

  > bin/kafka-topics.sh --bootstrap-server broker_host:port --delete --topic my_topic_name

 

Kafka目前不支援減少一個主題的分割槽數量。

更改主題的複製因子的說明可以在這裡找到。

 

優雅地關機

Kafka叢集將自動檢測任何broker關閉或故障，併為該機器上的分割槽選舉新的領導者。無論伺服器發生故障，還是因維護或配置更改而故意當機，都會發生這種情況。對於後一種情況，Kafka支援一種更優雅的機制來停止伺服器，而不是直接殺死它。當一個伺服器被優雅地停止時，它有兩個優化，它會利用這兩個優化。

1. 它會將所有的日誌同步到磁碟上，以避免在重新啟動時需要進行任何日誌恢復（即驗證日誌尾部所有訊息的校驗和）。日誌恢復需要時間，所以這可以加快有意重啟的速度。
2. 它將在關閉之前把伺服器是領導的任何分割槽遷移到其他副本。這將使領導權轉移更快，並將每個分割槽不可用的時間減少到幾毫秒。

除硬殺外，每當伺服器停止時，同步日誌將自動發生，但受控領導力遷移需要使用特殊設定：

      controlled.shutdown.enable=true

請注意，只有當所有託管在broker上的分割槽都有副本時，受控關閉才會成功（即複製因子大於1，並且這些副本中至少有一個是活的）。這通常是你想要的，因為關閉最後一個副本會使該主題分割槽不可用。

 

平衡領導權

每當一個broker停止或崩潰時，該broker的分割槽的領導權就會轉移到其他副本上。當broker重新啟動時，它將只成為其所有分割槽的跟隨者，這意味著它將不會被用於客戶端讀寫。
為了避免這種不平衡，Kafka有一個首選副本的概念。如果一個分割槽的副本列表是1,5,9，那麼節點1作為領導者比節點5或9都要優先，因為它在副本列表中更早。預設情況下，Kafka叢集會嘗試將領導權恢復給被恢復的副本。這種行為是通過以下方式配置的。

 

      auto.leader.rebalance.enable=true

 

您也可以將此設定為false，但您需要通過執行命令手動將領導力恢復到恢復的副本。

  > bin/kafka-preferred-replica-election.sh --bootstrap-server broker_host:port

 

平衡各機架上的副本

機架感知功能將同一分割槽的副本分佈在不同機架上。這將Kafka為broker故障提供的保證擴充套件到覆蓋機架故障，限制了一個機架上所有broker同時故障時的資料丟失風險。該功能還可以應用於其他broker分組，如EC2中的可用性區。

您可以通過在broker config中新增一個屬性來指定某個broker屬於某個機架：

  broker.rack=my-rack-id

 

當一個主題被建立、修改或副本被重新分配時，機架約束將被尊重，確保副本跨越儘可能多的機架（一個分割槽將跨越min(#racks, replication-factor)不同的機架）。
用於將副本分配給broker的演算法確保每個broker的leader數量不變，無論broker如何分佈在機架上。這確保了均衡的吞吐量。
然而，如果機架上分配了不同數量的broker，那麼複製件的分配將不會是均勻的。擁有較少broker的機架將獲得更多的複製，這意味著它們將使用更多的儲存並將更多的資源投入到複製中。因此，每個機架配置相同數量的broker是明智的。

 

叢集之間的資料映象和地理複製

Kafka管理員可以定義跨越單個Kafka叢集、資料中心或地理區域邊界的資料流。更多資訊請參考 "地理複製 "一節。

 

檢查消費者位置

有時候，看看你的消費者的位置是很有用的。我們有一個工具，可以顯示一個消費群中所有消費者的位置，以及他們在日誌末端的落後程度。如果要在一個名為my-group的消費群組上執行這個工具，消費一個名為my-topic的主題，會是這樣的。

  > bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group

  TOPIC                          PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG        CONSUMER-ID                                       HOST                           CLIENT-ID
  my-topic                       0          2               4               2          consumer-1-029af89c-873c-4751-a720-cefd41a669d6   /127.0.0.1                     consumer-1
  my-topic                       1          2               3               1          consumer-1-029af89c-873c-4751-a720-cefd41a669d6   /127.0.0.1                     consumer-1
  my-topic                       2          2               3               1          consumer-2-42c1abd4-e3b2-425d-a8bb-e1ea49b29bb2   /127.0.0.1                     consumer-2

 

管理消費者組

通過ConsumerGroupCommand工具，我們可以列出、描述或刪除消費者組。消費者組可以手動刪除，也可以在該組最後一次提交的偏移量到期時自動刪除。只有當該組沒有任何活動成員時，手動刪除才有效。例如，要列出所有主題的所有消費者組。

  > bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list

  test-consumer-group

 

如前所述，為了檢視偏移量，我們是這樣 "描述 "消費群體的。

  > bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group

  TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID                                    HOST            CLIENT-ID
  topic3          0          241019          395308          154289          consumer2-e76ea8c3-5d30-4299-9005-47eb41f3d3c4 /127.0.0.1      consumer2
  topic2          1          520678          803288          282610          consumer2-e76ea8c3-5d30-4299-9005-47eb41f3d3c4 /127.0.0.1      consumer2
  topic3          1          241018          398817          157799          consumer2-e76ea8c3-5d30-4299-9005-47eb41f3d3c4 /127.0.0.1      consumer2
  topic1          0          854144          855809          1665            consumer1-3fc8d6f1-581a-4472-bdf3-3515b4aee8c1 /127.0.0.1      consumer1
  topic2          0          460537          803290          342753          consumer1-3fc8d6f1-581a-4472-bdf3-3515b4aee8c1 /127.0.0.1      consumer1
  topic3          2          243655          398812          155157          consumer4-117fe4d3-c6c1-4178-8ee9-eb4a3954bee0 /127.0.0.1      consumer4

 

有一些額外的 "描述 "選項可以用來提供有關消費者群體的更多詳細資訊。
--members  該選項提供消費群中所有活躍成員的清單：

      > bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group --members

      CONSUMER-ID                                    HOST            CLIENT-ID       #PARTITIONS
      consumer1-3fc8d6f1-581a-4472-bdf3-3515b4aee8c1 /127.0.0.1      consumer1       2
      consumer4-117fe4d3-c6c1-4178-8ee9-eb4a3954bee0 /127.0.0.1      consumer4       1
      consumer2-e76ea8c3-5d30-4299-9005-47eb41f3d3c4 /127.0.0.1      consumer2       3
      consumer3-ecea43e4-1f01-479f-8349-f9130b75d8ee /127.0.0.1      consumer3       0

--members--verbose   除了上述"--成員 "選項報告的資訊外，該選項還提供分配給每個成員的分割槽。 

      > bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group --members --verbose

      CONSUMER-ID                                    HOST            CLIENT-ID       #PARTITIONS     ASSIGNMENT
      consumer1-3fc8d6f1-581a-4472-bdf3-3515b4aee8c1 /127.0.0.1      consumer1       2               topic1(0), topic2(0)
      consumer4-117fe4d3-c6c1-4178-8ee9-eb4a3954bee0 /127.0.0.1      consumer4       1               topic3(2)
      consumer2-e76ea8c3-5d30-4299-9005-47eb41f3d3c4 /127.0.0.1      consumer2       3               topic2(1), topic3(0,1)
      consumer3-ecea43e4-1f01-479f-8349-f9130b75d8ee /127.0.0.1      consumer3       0               -

--offsets。這是預設的describe選項，提供與"--describe "選項相同的輸出。
--state：這個選項提供了有用的組級資訊。這個選項提供了有用的組級資訊。

      > bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group --state

      COORDINATOR (ID)          ASSIGNMENT-STRATEGY       STATE                #MEMBERS
      localhost:9092 (0)        range                     Stable               4

要手動刪除一個或多個消費群，可使用"--刪除 "選項。

  > bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --delete --group my-group --group my-other-group

  Deletion of requested consumer groups ('my-group', 'my-other-group') was successful.

 

要重置一個消費群的偏移量，可以使用"--reset-offsets "選項。這個選項一次只支援一個消費群。它需要定義以下範圍：---all-topics 或 ---topic。必須選擇一個範圍，除非你使用"--from-file "方案。另外，首先確保消費者例項是非活動的。更多細節請參見KIP-122。

它有3個執行選項。

1. (default)顯示要重置的偏移量。
2. --execute : 執行 --reset-offsets 程式。
3. --export : 將結果匯出為CSV格式。

--reset-offsets也有以下方案可供選擇（必須至少選擇一個方案）。

• --to-dateatetime <String: datetime> : 將偏移量重置為日期時間的偏移量。格式：'YYYY-MM-DD'。'YYYY-MM-DDTHH:MM:SS.sss' 。
• --toearliest ：將偏移量重置為最早的偏移量。
• --to-latest : 將偏移量重置為最早的偏移量。將偏移量重置為最新的偏移量。
• --shift-by <Long: number-of-offsets> : 重置偏移量，將當前偏移量移動'n'，其中'n'可以是正或負。
• --from-file : 將偏移量重置為CSV檔案中定義的值。
• --to-current : 將偏移量重置為當前偏移量。將偏移量重置為當前的偏移量。
• --by-duration <String: duration> : 將偏移量重置為當前時間戳的持續時間的偏移量。格式：'PnDTnHnM'。'PnDTnHnMnS'。
• --to-offset : 將偏移量重置為一個特定的偏移量。

請注意，超出範圍的偏移將被調整到可用的偏移端。例如，如果偏移量在10，而偏移量的請求是15，那麼，實際上將選擇10的偏移量。
例如，將消費者組的偏移量重置為最新的偏移量：

  > bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --reset-offsets --group consumergroup1 --topic topic1 --to-latest

  TOPIC                          PARTITION  NEW-OFFSET
  topic1                         0          0

如果你使用舊的高階消費者，並將組後設資料儲存在ZooKeeper中（即offsets.storage=zookeeper），傳遞--zookeeper而不是--bootstrap-server。

  > bin/kafka-consumer-groups.sh --zookeeper localhost:2181 --list

 

叢集擴充套件

將伺服器新增到Kafka叢集很簡單，只需給它們分配一個唯一的broker id，然後在新伺服器上啟動Kafka。然而這些新伺服器不會自動分配任何資料分割槽，所以除非分割槽被移動到它們身上，否則它們不會做任何工作，直到新的主題被建立。因此，通常當你將機器新增到你的叢集時，你會希望將一些現有的資料遷移到這些機器上。
遷移資料的過程是手動發起的，但完全自動化。在掩護下發生的事情是，Kafka會將新伺服器新增為它要遷移的分割槽的跟隨者，並允許它完全複製該分割槽中的現有資料。當新伺服器完全複製了這個分割槽的內容，並加入了同步副本後，其中一個現有的副本將刪除其分割槽的資料。

分割槽重新分配工具可以用來在不同的broker之間移動分割槽。理想的分割槽分佈將確保所有broker的資料負載和分割槽大小均勻。分割槽重新分配工具沒有能力自動研究Kafka叢集中的資料分佈，並移動分割槽以達到均勻的負載分佈。因此，管理員必須弄清楚哪些主題或分割槽應該被移動。

分割槽重新分配工具可以在3種相互排斥的模式下執行。

• --生成模式 在這種模式下，給定一個主題列表和一個broker列表，該工具會生成一個候選的重新分配，將指定主題的所有分割槽移動到新的broker上。這個選項只是提供了一種方便的方式來生成給定主題和目標broker列表的分割槽重新分配計劃。
• --執行。在這種模式下，工具會根據使用者提供的重新分配計劃啟動分割槽的重新分配。(使用--reassignment-js-on-file選項)。這可以是管理員手工製作的自定義重新分配計劃，也可以是使用--generate選項提供的。
• --驗證：在該模式下，該工具將驗證上次 --執行期間列出的所有分割槽的重新分配狀態。狀態可以是成功完成、失敗或正在進行。

 

自動將資料遷移到新機器上

分割槽重新分配工具可用於將一些主題從當前的broker集合中移到新新增的broker中。這在擴充套件現有群集時通常很有用，因為將整個主題移動到新的broker集合中比一次移動一個分割槽更容易。當用來做這件事時，使用者應該提供一個應該移動到新的broker集的主題列表和一個新broker的目標列表。然後，該工具會將給定主題列表的所有分割槽均勻地分配到新的broker集上。在這個移動過程中，主題的複製因子保持不變。實際上，輸入的主題列表的所有分割槽的複製都從舊的broker集移動到新增加的broker。
例如，下面的例子將把主題foo1,foo2的所有分割槽移動到新的broker5,6集。在移動結束後，主題foo1和foo2的所有分割槽將只存在於broker5,6上。

由於該工具接受輸入的主題列表為 json 檔案，因此首先需要確定要移動的主題，並建立 json 檔案，如下所示：

  > cat topics-to-move.json
  {"topics": [{"topic": "foo1"},
              {"topic": "foo2"}],
  "version":1
  }

 

 

一旦json檔案準備好，使用分割槽重分配工具生成候選分配。

  > bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --topics-to-move-json-file topics-to-move.json --broker-list "5,6" --generate
  Current partition replica assignment

  {"version":1,
  "partitions":[{"topic":"foo1","partition":2,"replicas":[1,2]},
                {"topic":"foo1","partition":0,"replicas":[3,4]},
                {"topic":"foo2","partition":2,"replicas":[1,2]},
                {"topic":"foo2","partition":0,"replicas":[3,4]},
                {"topic":"foo1","partition":1,"replicas":[2,3]},
                {"topic":"foo2","partition":1,"replicas":[2,3]}]
  }

  Proposed partition reassignment configuration

  {"version":1,
  "partitions":[{"topic":"foo1","partition":2,"replicas":[5,6]},
                {"topic":"foo1","partition":0,"replicas":[5,6]},
                {"topic":"foo2","partition":2,"replicas":[5,6]},
                {"topic":"foo2","partition":0,"replicas":[5,6]},
                {"topic":"foo1","partition":1,"replicas":[5,6]},
                {"topic":"foo2","partition":1,"replicas":[5,6]}]
  }

 

該工具會生成一個候選任務，將所有分割槽從主題foo1,foo2移動到broker5,6。但請注意，此時分割槽移動還沒有開始，它只是告訴你當前的分配和建議的新分配。當前的分配應該被儲存，以防你想回滾到它。新的分配應該儲存在一個json檔案中(例如expand-cluster-reassignment.json)，以便用--execute選項輸入到工具中，如下所示。

 

  > bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --reassignment-json-file expand-cluster-reassignment.json --execute
  Current partition replica assignment

  {"version":1,
  "partitions":[{"topic":"foo1","partition":2,"replicas":[1,2]},
                {"topic":"foo1","partition":0,"replicas":[3,4]},
                {"topic":"foo2","partition":2,"replicas":[1,2]},
                {"topic":"foo2","partition":0,"replicas":[3,4]},
                {"topic":"foo1","partition":1,"replicas":[2,3]},
                {"topic":"foo2","partition":1,"replicas":[2,3]}]
  }

  Save this to use as the --reassignment-json-file option during rollback
  Successfully started reassignment of partitions
  {"version":1,
  "partitions":[{"topic":"foo1","partition":2,"replicas":[5,6]},
                {"topic":"foo1","partition":0,"replicas":[5,6]},
                {"topic":"foo2","partition":2,"replicas":[5,6]},
                {"topic":"foo2","partition":0,"replicas":[5,6]},
                {"topic":"foo1","partition":1,"replicas":[5,6]},
                {"topic":"foo2","partition":1,"replicas":[5,6]}]
  }

 

最後，--verify選項可以與該工具一起使用，以檢查分割槽重新分配的狀態。請注意，在使用--verify選項時，應該使用相同的expand-cluster-reassignment.json（與--execute選項一起使用）。

 

 > bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --reassignment-json-file expand-cluster-reassignment.json --verify
  Status of partition reassignment:
  Reassignment of partition [foo1,0] completed successfully
  Reassignment of partition [foo1,1] is in progress
  Reassignment of partition [foo1,2] is in progress
  Reassignment of partition [foo2,0] completed successfully
  Reassignment of partition [foo2,1] completed successfully
  Reassignment of partition [foo2,2] completed successfully

 

自定義分割槽分配和遷移

分割槽重新分配工具還可用於有選擇地將一個分割槽的副本移至一組特定的broker。當以這種方式使用時，假定使用者知道重新分配計劃，不需要該工具生成候選的重新分配，有效地跳過--生成步驟，直接進入--執行步驟。
例如，下面的例子將topic foo1的分割槽0移動到broker 5,6，將topic foo2的分割槽1移動到broker 2,3。

第一步是在json檔案中手工製作自定義的重新分配計劃：

  > cat custom-reassignment.json
  {"version":1,"partitions":[{"topic":"foo1","partition":0,"replicas":[5,6]},{"topic":"foo2","partition":1,"replicas":[2,3]}]}

然後，使用帶有--execute選項的json檔案開始重新分配過程。

 > bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --reassignment-json-file custom-reassignment.json --execute
  Current partition replica assignment

  {"version":1,
  "partitions":[{"topic":"foo1","partition":0,"replicas":[1,2]},
                {"topic":"foo2","partition":1,"replicas":[3,4]}]
  }

  Save this to use as the --reassignment-json-file option during rollback
  Successfully started reassignment of partitions
  {"version":1,
  "partitions":[{"topic":"foo1","partition":0,"replicas":[5,6]},
                {"topic":"foo2","partition":1,"replicas":[2,3]}]
  }

 

--verify選項可用於工具檢查分割槽重新分配的狀態。請注意，在使用--驗證選項時，應該使用相同的自定義重新分配.json（與--執行選項一起使用）。

 

  > bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --reassignment-json-file custom-reassignment.json --verify
  Status of partition reassignment:
  Reassignment of partition [foo1,0] completed successfully
  Reassignment of partition [foo2,1] completed successfully

 

退役的broker

分割槽重新分配工具尚不具備為停用的代理自動生成重新分配計劃的能力。因此，管理員必須提出一個重新分配計劃，將託管在要停用的broker上的所有分割槽的副本轉移到其他broker上。這可能是比較繁瑣的，因為重新分配需要確保所有的副本不會從退役的broker移動到只有一個其他broker。為了使這一過程不費吹灰之力，我們計劃在未來為退役broker增加工具支援。

增加複製因子

增加現有分割槽的複製因子很容易。只需在自定義的重新分配json檔案中指定額外的複製因子，並與--execute選項一起使用，就可以增加指定分割槽的複製因子。

例如，下面的例子將topic foo的分割槽0的複製因子從1增加到3，在增加複製因子之前，該分割槽的唯一副本存在於broker 5上。作為增加複製因子的一部分，我們將在broker6和7上增加更多的副本。

 

第一步是在json檔案中手工製作自定義的重新分配計劃。

 

  > cat increase-replication-factor.json
  {"version":1,
  "partitions":[{"topic":"foo","partition":0,"replicas":[5,6,7]}]}

然後，使用帶有--execute選項的json檔案開始重新分配過程。

  > bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --reassignment-json-file increase-replication-factor.json --execute
  Current partition replica assignment

  {"version":1,
  "partitions":[{"topic":"foo","partition":0,"replicas":[5]}]}

  Save this to use as the --reassignment-json-file option during rollback
  Successfully started reassignment of partitions
  {"version":1,
  "partitions":[{"topic":"foo","partition":0,"replicas":[5,6,7]}]}

 

--verify選項可以與該工具一起使用，以檢查分割槽重新分配的狀態。請注意，在使用--驗證選項時，應該使用相同的遞增複製因子.json（與--execute選項一起使用）。

 

  > bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --reassignment-json-file increase-replication-factor.json --verify
  Status of partition reassignment:
  Reassignment of partition [foo,0] completed successfully

 

你也可以用kafka-topics工具驗證複製因子的增加。

 > bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic foo --describe
  Topic:foo	PartitionCount:1	ReplicationFactor:3	Configs:
    Topic: foo	Partition: 0	Leader: 5	Replicas: 5,6,7	Isr: 5,6,7

限制資料遷移期間的頻寬使用

Kafka讓你可以對複製流量進行節流，對用於將複製從機器移動到機器的頻寬設定一個上限。這在重新平衡叢集、引導新的代理或新增或刪除代理時非常有用，因為它限制了這些資料密集型操作對使用者的影響。
有兩個介面可以用來參與節流。最簡單，也是最安全的是在呼叫kafka-reassign-partitions.sh時應用節流，但kafka-configs.sh也可以直接用來檢視和改變節流值。
所以舉例來說，如果你要執行重新分配，用下面的命令，它將以不超過50MB/s的速度移動分割槽。

$ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --execute --reassignment-json-file bigger-cluster.json --throttle 50000000

 

當你執行這個指令碼時，你會看到節氣門齧合。

The throttle limit was set to 50000000 B/s
Successfully started reassignment of partitions.

如果你想在重新平衡過程中改變節流閥，比如說增加吞吐量以使其完成得更快，你可以通過重新執行傳遞相同的重新分配-js-檔案的執行命令來實現。

$ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092  --execute --reassignment-json-file bigger-cluster.json --throttle 700000000
  There is an existing assignment running.
  The throttle limit was set to 700000000 B/s

 

一旦再平衡完成，管理員可以使用--驗證選項檢查再平衡的狀態。如果再平衡已經完成，將通過--驗證命令移除節流閥。重要的是，管理員在再平衡完成後，要通過執行帶有--verify選項的命令及時移除節流閥。如果不這樣做，可能會導致常規復制流量被節流。

當執行--verify選項，並且重新分配完成後，指令碼將確認節流被移除。

  > bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092  --verify --reassignment-json-file bigger-cluster.json
  Status of partition reassignment:
  Reassignment of partition [my-topic,1] completed successfully
  Reassignment of partition [mytopic,0] completed successfully
  Throttle was removed.

管理員也可以使用kafka-configs.sh來驗證分配的配置。有兩對節流配置用於管理節流過程。第一對是指節流值本身。這是在broker層面，使用動態屬性進行配置的。

 

    leader.replication.throttled.rate
    follower.replication.throttled.rate

 

然後是配置對列舉的節制複製集。

 

    leader.replication.throttled.replicas
    follower.replication.throttled.replicas

 

其中每個主題的配置值。

所有四個配置值都是由kafka-reassign-partitions.sh自動分配的（下面討論）。

要檢視節流限制配置。

 

  > bin/kafka-configs.sh --describe --bootstrap-server localhost:9092 --entity-type brokers
  Configs for brokers '2' are leader.replication.throttled.rate=700000000,follower.replication.throttled.rate=700000000
  Configs for brokers '1' are leader.replication.throttled.rate=700000000,follower.replication.throttled.rate=700000000

 

這顯示了應用於複製協議的領導者和跟隨者端的節流。預設情況下，兩邊都被分配了相同的節流吞吐量值。

要檢視節流複製的列表。

  > bin/kafka-configs.sh --describe --bootstrap-server localhost:9092 --entity-type topics
  Configs for topic 'my-topic' are leader.replication.throttled.replicas=1:102,0:101,
      follower.replication.throttled.replicas=1:101,0:102

 

在這裡，我們看到領導節流被應用於broker102上的分割槽1和broker101上的分割槽0。同樣的，跟隨者節制也被應用於broker 101上的分割槽1和broker 102上的分割槽0。

預設情況下，kafka-reassign-partitions.sh會將leader節流應用到所有在重新平衡之前存在的複製，其中任何一個複製都可能是leader。它將對所有移動目的地應用follower節制。因此，如果在broker 101,102 上有一個複製的分割槽，被重新分配到 102,103，那麼該分割槽的領導者節流將被應用到 101,102，而跟隨者節流將只應用到 103。

如果需要，你也可以使用kafka-configs.sh上的--alter開關來手動改變節流配置。

安全使用節流複製

在使用節流複製時，應注意一些問題。尤其是

(1)節流器的移除。

重新分配完成後，應及時移除節流器(通過執行kafka-reassign-partitions.sh--verify)。
(2)保證進度。

如果節流閥設定得太低，與傳入的寫入速率相比，有可能導致複製沒有進展。這種情況發生在以下情況。

 

max(BytesInPerSec) > throttle

 

其中BytesInPerSec是監控生產者向每個broker寫入吞吐量的度量。

管理員可以在重新平衡期間，使用該指標監控複製是否有進展。

 

kafka.server:type=FetcherLagMetrics,name=ConsumerLag,clientId=([-.\w]+),topic=([-.\w]+),partition=([0-9]+)

 

在複製過程中，滯後應該不斷減少。如果該指標沒有減少，管理員應如上所述增加節流吞吐量。

 

設定配額

配額覆蓋和預設值可以在(使用者、客戶端-id)、使用者或客戶端-id級別進行配置，如這裡所述。預設情況下，客戶端獲得的配額是無限的。可以為每個（使用者、客戶機id）、使用者或客戶機id組設定自定義配額。
為（user=user1，client-id=clientA）配置自定義配額：

  > bin/kafka-configs.sh  --bootstrap-server localhost:9092 --alter --add-config 'producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200' --entity-type users --entity-name user1 --entity-type clients --entity-name clientA
  Updated config for entity: user-principal 'user1', client-id 'clientA'.

 

為user=user1配置自定義配額：

  > bin/kafka-configs.sh  --bootstrap-server localhost:9092 --alter --add-config 'producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200' --entity-type users --entity-name user1
  Updated config for entity: user-principal 'user1'.

 

為client-id=clientA配置自定義配額：

  > bin/kafka-configs.sh  --bootstrap-server localhost:9092 --alter --add-config 'producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200' --entity-type clients --entity-name clientA
  Updated config for entity: client-id 'clientA'.

通過指定--entity-default選項而不是--entity-name，可以為每個（使用者、client-id）、使用者或client-id組設定預設配額。
為user=userA配置預設的client-id配額：

  > bin/kafka-configs.sh  --bootstrap-server localhost:9092 --alter --add-config 'producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200' --entity-type users --entity-name user1 --entity-type clients --entity-default
  Updated config for entity: user-principal 'user1', default client-id.

配置使用者的預設配額：

  > bin/kafka-configs.sh  --bootstrap-server localhost:9092 --alter --add-config 'producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200' --entity-type users --entity-default
  Updated config for entity: default user-principal.

配置client-id的預設配額：

  > bin/kafka-configs.sh  --bootstrap-server localhost:9092 --alter --add-config 'producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200' --entity-type clients --entity-default
  Updated config for entity: default client-id.

下面是如何描述一個給定的（使用者，client-id）的配額。

  > bin/kafka-configs.sh  --bootstrap-server localhost:9092 --describe --entity-type users --entity-name user1 --entity-type clients --entity-name clientA
  Configs for user-principal 'user1', client-id 'clientA' are producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200

描述給定使用者的配額：

  > bin/kafka-configs.sh  --bootstrap-server localhost:9092 --describe --entity-type users --entity-name user1
  Configs for user-principal 'user1' are producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200

 

描述給定客戶ID的配額：

  > bin/kafka-configs.sh  --bootstrap-server localhost:9092 --describe --entity-type clients --entity-name clientA
  Configs for client-id 'clientA' are producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200

 

如果沒有指定實體名稱，則描述指定型別的所有實體。例如，描述所有使用者：

  > bin/kafka-configs.sh  --bootstrap-server localhost:9092 --describe --entity-type users
  Configs for user-principal 'user1' are producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200
  Configs for default user-principal are producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200

 

同理，對於（使用者，客戶端）：

  > bin/kafka-configs.sh  --bootstrap-server localhost:9092 --describe --entity-type users --entity-type clients
  Configs for user-principal 'user1', default client-id are producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200
  Configs for user-principal 'user1', client-id 'clientA' are producer_byte_rate=1024,consumer_byte_rate=2048,request_percentage=200

 

通過在broker上設定這些配置，可以設定適用於所有客戶端ID的預設配額。只有在Zookeeper中沒有配置配額覆蓋或預設值時，才會應用這些屬性。預設情況下，每個客戶機id都會收到一個無限的配額。下面將每個生產者和消費者客戶端-id的預設配額設定為10MB/秒。

    quota.producer.default=10485760
    quota.consumer.default=10485760

 

請注意，這些屬性已經被廢棄，可能會在未來的版本中被刪除。使用kafka-configs.sh配置的預設值優先於這些屬性。

 

 

6.2 資料中心

一些部署將需要管理一個跨越多個資料中心的資料管道。我們推薦的方法是在每個資料中心部署一個本地的Kafka叢集，每個資料中心的應用例項僅與其本地叢集進行互動，並在叢集之間進行資料映象（如何做到這一點，請參見關於地理複製的文件）。
這種部署模式允許資料中心作為獨立的實體行事，並允許我們集中管理和調整資料中心間的複製。這允許每個設施獨立執行，即使資料中心間鏈路不可用：當發生這種情況時，映象會落後，直到鏈路恢復時才會趕上。

對於需要對所有資料進行全域性檢視的應用，您可以使用映象提供叢集，該叢集的資料彙總從所有資料中心的本地叢集中映象出來。這些聚合叢集用於需要完整資料集的應用的讀取。

這不是唯一可能的部署模式。通過廣域網從遠端Kafka叢集讀取或寫入也是可能的，不過很明顯，這會增加獲取叢集所需的任何延遲。

Kafka自然地在生產者和消費者中都會對資料進行批處理，因此即使在高延遲的連線上也能實現高吞吐量。不過為了允許這樣做，可能需要使用socket.send.buffer.bytes和socket.receive.buffer.bytes配置來增加生產者、消費者和broker的TCP socket緩衝區大小。這裡記載了適當的設定方法。

一般來說，不建議在高延遲鏈路上執行跨越多個資料中心的單個Kafka叢集。這將導致Kafka寫入和ZooKeeper寫入的複製延遲非常高，而且如果位置之間的網路不可用，Kafka和ZooKeeper都不會在所有位置保持可用。

 

6.3 地理複製(跨叢集資料映象)

地理複製概述

Kafka管理員可以定義跨越單個Kafka叢集、資料中心或地理區域邊界的資料流。這種事件流的設定通常是出於組織、技術或法律要求的需要。常見的場景包括

• 地理複製
• 災難恢復
• 將邊緣叢集送入一箇中央的聚合叢集中
• 叢集的物理隔離（如生產與測試）。
• 雲遷移或混合雲部署
• 法律和合規要求

管理員可以通過Kafka的MirrorMaker（第2版）來設定這樣的叢集間資料流，MirrorMaker是一個在不同Kafka環境之間以流式方式複製資料的工具。MirrorMaker建立在Kafka Connect框架之上，支援以下功能。

• 複製主題(資料加配置)
• 複製包括偏移在內的消費群體，以在叢集之間遷移應用。
• 複製ACL
• 保留分割槽
• 自動檢測新主題和分割槽
• 提供廣泛的指標，如跨多個資料中心/叢集的端到端複製延遲。
• 容錯和橫向可擴充套件的操作。

注意：使用MirrorMaker的Geo-replication可以跨Kafka叢集複製資料。這種叢集間的複製與Kafka的叢集內複製不同，後者在同一個Kafka叢集內複製資料。

 

什麼是複製流

通過MirrorMaker，Kafka管理員可以將主題、主題配置、消費者組及其偏移量和ACL從一個或多個源Kafka叢集複製到一個或多個目標Kafka叢集，即跨叢集環境。簡而言之，MirrorMaker 使用 Connectors 從源叢集消費，並生產到目標叢集。

這些從源叢集到目標叢集的定向流稱為複製流。它們在MirrorMaker配置檔案中以{source_cluster}->{target_cluster}的格式進行定義，後面會介紹。管理員可以根據這些流建立複雜的複製拓撲。

以下是一些示例模式。

• Active/Active高可用性部署。A->B，B->A
• 主動/被動或主動/備用高可用性部署。A->B
• 聚集(如從許多簇到一個簇)。A->K，B->K，C->K。
• 扇出(如從一簇到多簇)。K->A，K->B，K->C。
• 轉發：A->B、B->C、C->D A->B，B->C，C->D。

預設情況下，一個流會複製所有主題和消費者組。但是，可以對每個複製流進行獨立配置。例如，您可以定義只將特定的主題或消費者組從源群集複製到目標群集。

下面是關於如何配置資料從主群集複製到輔助群集（主動/被動設定）的第一個例子。

 

# Basic settings
clusters = primary, secondary
primary.bootstrap.servers = broker3-primary:9092
secondary.bootstrap.servers = broker5-secondary:9092

# Define replication flows
primary->secondary.enable = true
primary->secondary.topics = foobar-topic, quux-.*

 

配置地理複製

以下部分描述瞭如何配置和執行專用的MirrorMaker叢集。如果您想在現有的 Kafka Connect 叢集或其他支援的部署設定中執行 MirrorMaker，請參考 KIP-382: MirrorMaker 2.0，並注意不同部署模式的配置設定名稱可能有所不同。

除了以下章節所涉及的內容外，還可在以下網址獲得有關配置設定的進一步示例和資訊。

• MirrorMakerConfig，MirrorConnectorConfig。
• 預設主題過濾（DefaultTopicFilter），預設組過濾（DefaultGroupFilter）。
• connect-mirror-maker.properties中的配置設定示例，KIP-382。MirrorMaker 2.0

 

配置檔案語法

MirrorMaker配置檔案通常命名為connect-mirror-maker.properties。你可以在這個檔案中配置各種元件。

• MirrorMaker設定：全域性設定，包括叢集定義（別名），加上每個複製流的自定義設定。
• Kafka連線和聯結器設定
• Kafka生產者、消費者和管理客戶端設定

例子。定義MirrorMaker設定（後面會詳細解釋）。

 

# Global settings
clusters = us-west, us-east   # defines cluster aliases
us-west.bootstrap.servers = broker3-west:9092
us-east.bootstrap.servers = broker5-east:9092

topics = .*   # all topics to be replicated by default

# Specific replication flow settings (here: flow from us-west to us-east)
us-west->us-east.enable = true
us-west->us.east.topics = foo.*, bar.*  # override the default above

 

MirrorMaker是基於Kafka Connect框架的。在Kafka Connect的文件章節中描述的任何Kafka Connect、source connector和sink connector設定都可以直接在MirrorMaker配置中使用，而無需更改或字首配置設定的名稱。

例子 定義自定義的Kafka Connect設定，供MirrorMaker使用。

 

# Setting Kafka Connect defaults for MirrorMaker
tasks.max = 5

 

除了tasks.max之外，大多數預設的Kafka Connect設定在MirrorMaker開箱即用的情況下都能正常工作。為了在多個MirrorMaker程式中均勻分配工作負載，建議根據可用的硬體資源和要複製的主題分割槽總數，將tasks.max設定為至少2（最好更高）。

您可以進一步自定義MirrorMaker按源叢集或目標叢集的Kafka Connect設定（更準確地說，您可以 "按聯結器 "指定Kafka Connect worker級別的配置設定）。在MirrorMaker配置檔案中使用{cluster}.{config_name}的格式。

例子 ：為us-west叢集定義自定義聯結器設定：

 

# us-west custom settings
us-west.offset.storage.topic = my-mirrormaker-offsets

 

MirrorMaker內部使用Kafka生產者、消費者和管理員客戶端。經常需要對這些客戶端進行自定義設定。要覆蓋預設值，請在MirrorMaker配置檔案中使用以下格式。

• {source}.consumer.{consumer_config_name}。
• {target}.producer.{producer_config_name}。
• {source_or_target}.admin.{admin_config_name}。

例子：定義自定義生產者、消費者、管理員客戶端的設定：

# us-west cluster (from which to consume)
us-west.consumer.isolation.level = read_committed
us-west.admin.bootstrap.servers = broker57-primary:9092

# us-east cluster (to which to produce)
us-east.producer.compression.type = gzip
us-east.producer.buffer.memory = 32768
us-east.admin.bootstrap.servers = broker8-secondary:9092

 

建立和啟用複製流

要定義複製流，必須先在MirrorMaker配置檔案中定義各自的源叢集和目標Kafka叢集。

• clusters（必填）：以逗號分隔的Kafka叢集 "別名 "列表。
• {clusterAlias}.bootstrap.servers (必填)：特定叢集的連線資訊；以逗號分隔的 "bootstrap "Kafkabroker列表。

例子：定義兩個叢集別名primary和secondary，包括其連線資訊：

clusters = primary, secondary
primary.bootstrap.servers = broker10-primary:9092,broker-11-primary:9092
secondary.bootstrap.servers = broker5-secondary:9092,broker6-secondary:9092

 

其次，您必須根據需要使用{source}->{target}.enabled = true顯式啟用單個複製流。請記住，流是有方向性的：如果你需要雙向（雙向）複製，你必須啟用兩個方向的流。

 

# Enable replication from primary to secondary
primary->secondary.enable = true

 

預設情況下，複製流將把除少數特殊主題和消費者組以外的所有主題和消費者組從源群集複製到目標群集，並自動檢測任何新建立的主題和組。在目標叢集中複製的主題的名稱將以源叢集的名稱為字首（請參閱下面的進一步章節）。例如，源群集 us-west 中的主題 foo 將被複制到目標群集 us-east 中名為 us-west.foo 的主題。

後面的章節將解釋如何根據你的需要定製這個基本設定。

 

配置複製流

複製流的配置是頂層預設設定（如主題）的組合，在頂層預設設定的基礎上應用特定流的設定（如us-west->us-east.topic）。要更改頂層預設設定，請將相應的頂層設定新增到 MirrorMaker 配置檔案中。要僅覆蓋特定複製流的預設值，請使用語法格式{source}->{target}.{config.name}。

最重要的設定是

• topics：主題列表或定義源叢集中哪些主題要複製的正規表示式（預設： topics = .*）。
• topics.exclude：topic的列表或正規表示式，用於隨後排除由topic設定匹配的topic（預設：topic.exclude = .*[\-/\.]internal, .*/\.replica, __.*)
• groups：主題列表或正規表示式，用於定義源叢集中要複製的消費者群體（預設：group = .*）。
• groups.exclude：主題列表或正規表示式，用於隨後排除由 groups 設定匹配的消費者組（預設情況下：groups.exclude = console-consumer-.*, connect-.*, __.*）。
• {source}->{target}.enable：設定為true以啟用複製流（預設：false）。

例如：

# Custom top-level defaults that apply to all replication flows
topics = .*
groups = consumer-group1, consumer-group2

# Don't forget to enable a flow!
us-west->us-east.enable = true

# Custom settings for specific replication flows
us-west->us-east.topics = foo.*
us-west->us-east.groups = bar.*
us-west->us-east.emit.heartbeats = false

 

支援其他配置設定，其中一些設定列在下面。在大多數情況下，你可以讓這些設定保持預設值。更多細節請參見MirrorMakerConfig和MirrorConnectorConfig。

• refresh.topics.enabled：是否定期檢查源叢集中的新主題（預設：true）。
• refresh.topics.interval.seconds：在源叢集中檢查新主題的頻率；比預設值低的值可能會導致效能下降（預設值：6000，每十分鐘一次）。
• refresh.groups.enabled：是否定期檢查源群集中的新消費群集（預設：true）。
• refresh.groups.interval.seconds：在源群集中檢查新消費者群集的頻率；低於預設值可能會導致效能下降（預設值：6000，每十分鐘一次）。
• sync.topic.configs.enabled：是否從源叢集複製topic配置（預設：true）。
• sync.topic.acls.enabled：是否從源叢集同步ACL（預設：true）。
• emit.heartbeats.enabled：是否週期性地發出心跳聲（預設：true）。
• emit.heartbeats.interval.seconds：發出心跳的頻率（預設：5，每五秒一次）。
• heartbeats.topic.replication.factor：MirrorMaker內部心跳主題的複製因子（預設：3）。
• emit.checkpoints.enabled：是否定期發射MirrorMaker的消費偏移量（預設：true）。
• emit.checkpoints.interval.seconds：發出檢查點的頻率（預設：60，每分鐘）。
• checkpoints.topic.replication.factor：MirrorMaker內部檢查點主題的複製因子（預設：3）。
• sync.group.offsets.enabled：是否定期將複製的消費群組（在源群組中）的翻譯偏移量寫入目標群組中的__consumer_offsets主題，只要該群組中沒有活躍的消費者連線到目標群組（預設：true）。
• sync.group.offsets.interval.seconds：同步消費組偏移量的頻率（預設：60，每分鐘）。
• offset-syncs.topic.replication.factor：MirrorMaker內部offset-syncs主題的複製因子(預設：3)

確保複製流的安全

MirrorMaker支援與Kafka Connect相同的安全設定，所以請參考連結部分了解更多資訊。

例如： 加密MirrorMaker和us-east叢集之間的通訊：

us-east.security.protocol=SSL
us-east.ssl.truststore.location=/path/to/truststore.jks
us-east.ssl.truststore.password=my-secret-password
us-east.ssl.keystore.location=/path/to/keystore.jks
us-east.ssl.keystore.password=my-secret-password
us-east.ssl.key.password=my-secret-password

自定義命名目標叢集中重複的主題

在目標叢集中複製的主題--有時稱為遠端主題--會根據複製策略重新命名。MirrorMaker使用該策略來確保來自不同叢集的事件（也就是記錄、訊息）不會被寫入同一個主題分割槽。預設情況下，按照DefaultReplicationPolicy，目標叢集中複製的主題名稱具有{source}.{source_topic_name}的格式。

 

us-west         us-east
=========       =================
                bar-topic
foo-topic  -->  us-west.foo-topic

您可以使用 replication.policy.separator 設定自定義分隔符（預設：.）

# 自定義一個分隔符
us-west->us-east.replication.policy.separator = _

如果你需要進一步控制複製的主題的命名方式，你可以實現一個自定義的ReplicationPolicy，並在MirrorMaker配置中覆蓋replication.policy.class（預設為DefaultReplicationPolicy）。

 

防止配置衝突

MirrorMaker程式通過其目標Kafka叢集共享配置。當針對同一目標叢集操作的MirrorMaker程式之間的配置不同時，這種行為可能會導致衝突。

例如，以下兩個MirrorMaker程式會很狂野:

# Configuration of process 1
A->B.enabled = true
A->B.topics = foo

# Configuration of process 2
A->B.enabled = true
A->B.topics = bar

在這種情況下，兩個程式將通過叢集B共享配置，從而導致衝突。根據這兩個程式中哪個程式是當選的 "領導者"，結果將是主題foo或主題欄被複制，但不是兩個都被複制。

因此，在複製到同一目標叢集的各個複製流中保持MirrorMaker配置的一致性是非常重要的。例如，可以通過自動化工具或為整個組織使用單一的共享MirrorMaker配置檔案來實現這一點。

 

最佳實踐:遠端消費，本地生產

為了最大限度地減少延遲（"生產者滯後"），建議將MirrorMaker程式定位在儘可能靠近其目標叢集的地方，即它生產資料的叢集。這是因為Kafka生產者通常比Kafka消費者在不可靠或高延遲的網路連線中掙扎得更多。

 

First DC          Second DC
==========        =========================
primary --------- MirrorMaker --> secondary
(remote)                           (local)

 

要執行這種 "從遠端消費，生產到本地 "的設定，請在目標叢集附近，最好是在同一位置執行MirrorMaker程式，並在--clusters命令列引數中明確設定這些 "本地 "叢集（以空格分隔的叢集別名列表）。

 

# Run in secondary's data center, reading from the remote `primary` cluster
$ ./bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters secondary

 

--clusters secondary告訴MirrorMaker程式，給定的叢集就在附近，並防止它複製資料或向其他遠端位置的叢集傳送配置。

 

例子：主動/被動高可用性部署 主動/被動高可用性部署

下面的例子顯示了將主題從主環境複製到輔助Kafka環境的基本設定，但不是從輔助環境複製回主環境。請注意，大多數生產設定將需要進一步的配置，例如安全設定。

 

# Unidirectional flow (one-way) from primary to secondary cluster
primary.bootstrap.servers = broker1-primary:9092
secondary.bootstrap.servers = broker2-secondary:9092

primary->secondary.enabled = true
secondary->primary.enabled = false

primary->secondary.topics = foo.*  # only replicate some topics

 

示例:主動/主動高可用性部署

下面的例子顯示了在兩個叢集之間以兩種方式複製主題的基本設定。請注意，大多數生產設定將需要進一步的配置，例如安全設定。

 

# Bidirectional flow (two-way) between us-west and us-east clusters
clusters = us-west, us-east
us-west.bootstrap.servers = broker1-west:9092,broker2-west:9092
Us-east.bootstrap.servers = broker3-east:9092,broker4-east:9092

us-west->us-east.enabled = true
us-east->us-west.enabled = true

關於防止複製 "迴圈 "的注意點（即topic將原本從A複製到B，然後被複制的topic將再次從B複製到A，以此類推）。只要在同一個MirrorMaker配置檔案中定義上述流程，就不需要明確新增topic.exclude設定來防止兩個叢集之間的複製迴圈。

 

例子: 多叢集地理複製

讓我們把前面幾節的所有資訊放在一個更大的例子中。想象一下，有三個資料中心（西、東、北），每個資料中心有兩個Kafka叢集（例如，西-1、西-2）。本節的示例展示瞭如何配置MirrorMaker (1)用於每個資料中心內的Active/Active複製，以及(2)用於跨資料中心複製(XDCR)。

首先，在配置中定義源叢集和目標叢集以及它們的複製流:

# Basic settings
clusters: west-1, west-2, east-1, east-2, north-1, north-2
west-1.bootstrap.servers = ...
west-2.bootstrap.servers = ...
east-1.bootstrap.servers = ...
east-2.bootstrap.servers = ...
north-1.bootstrap.servers = ...
north-2.bootstrap.servers = ...

# Replication flows for Active/Active in West DC
west-1->west-2.enabled = true
west-2->west-1.enabled = true

# Replication flows for Active/Active in East DC
east-1->east-2.enabled = true
east-2->east-1.enabled = true

# Replication flows for Active/Active in North DC
north-1->north-2.enabled = true
north-2->north-1.enabled = true

# Replication flows for XDCR via west-1, east-1, north-1
west-1->east-1.enabled  = true
west-1->north-1.enabled = true
east-1->west-1.enabled  = true
east-1->north-1.enabled = true
north-1->west-1.enabled = true
north-1->east-1.enabled = true

 

然後，在每個資料中心，啟動一個或多個MirrorMaker，如下所示。

 

# In West DC:
$ ./bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters west-1 west-2

# In East DC:
$ ./bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters east-1 east-2

# In North DC:
$ ./bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters north-1 north-2

 

通過這種配置，向任何叢集生產的記錄都將在資料中心內複製，也會跨到其他資料中心。通過提供--clusters引數，我們可以確保每個MirrorMaker程式只向附近的叢集生產資料。

注意：從技術上講，這裡並不需要--clusters引數。MirrorMaker在沒有它的情況下也能正常工作。但是，吞吐量可能會受到資料中心之間 "生產者滯後 "的影響，你可能會產生不必要的資料傳輸成本。

 

開始地理複製

您可以根據需要執行儘可能少的或儘可能多的MirrorMaker程式（認為：節點、伺服器）。因為MirrorMaker是基於Kafka Connect的，所以配置為複製相同Kafka叢集的MirrorMaker程式以分散式設定執行。它們會相互找到對方，共享配置（見下節），負載平衡它們的工作，等等。例如，如果你想提高複製流的吞吐量，一個選項是並行執行額外的MirrorMaker程式。

要啟動一個MirrorMaker程式，請執行命令:

 

$ ./bin/connect-mirror-maker.sh connect-mirror-maker.properties

 

啟動後，可能需要幾分鐘的時間，直到MirrorMaker程式第一次開始複製資料。

如前所述，可以選擇設定引數--clusters，以確保MirrorMaker程式只向附近的叢集產生資料。

 

# Note: The cluster alias us-west must be defined in the configuration file
$ ./bin/connect-mirror-maker.sh connect-mirror-maker.properties \
            --clusters us-west

 

測試複製消費者組時的注意事項。預設情況下，MirrorMaker不會複製kafka-console-consumer.sh工具建立的消費者組，你可能會用它在命令列上測試你的MirrorMaker設定。如果你確實也想複製這些消費者組，請相應地設定groups.exclude配置（預設：groups.exclude = console-consumer-.*，connect-.*，__.*）。完成測試後，記得再次更新配置。

 

停止地理複製

你可以通過使用命令傳送SIGTERM訊號來停止正在執行的MirrorMaker程式。

 

$ kill <MirrorMaker pid>

 

應用配置更改

要使配置更改生效，必須重新啟動MirrorMaker程式。

 

監測地理複製

建議監控MirrorMaker程式，以確保所有定義的複製流都能正常執行。MirrorMaker建立在Connect框架上，繼承了Connect的所有度量，比如source-record-poll-rate。此外，MirrorMaker還在kafka.connect.mirror度量組下產生自己的度量。度量被標記為以下屬性。

• source：源叢集的別名（例如，主叢集）。
• target：目標群組的別名（如二級）。
• topic：在目標群組上覆制的主題
• partition：被複制的分割槽

對每個複製的主題進行度量跟蹤。可以從主題名稱推斷出源叢集。例如，從primary->secondary複製topic1將產生如下指標。

• target=secondary
• topic=primary.topic1
• partition=1

發出以下指標：

 

# MBean: kafka.connect.mirror:type=MirrorSourceConnector,target=([-.w]+),topic=([-.w]+),partition=([0-9]+)

record-count            # number of records replicated source -> target
record-age-ms           # age of records when they are replicated
record-age-ms-min
record-age-ms-max
record-age-ms-avg
replication-latency-ms  # time it takes records to propagate source->target
replication-latency-ms-min
replication-latency-ms-max
replication-latency-ms-avg
byte-rate               # average number of bytes/sec in replicated records

# MBean: kafka.connect.mirror:type=MirrorCheckpointConnector,source=([-.w]+),target=([-.w]+)

checkpoint-latency-ms   # time it takes to replicate consumer offsets
checkpoint-latency-ms-min
checkpoint-latency-ms-max
checkpoint-latency-ms-avg

 

這些指標並不區分create-at和log-append時間戳。

 

6.4 kfaka配置

重要的客戶端配置

最重要的生產者配置是。

• acks
• compression
• batch size

最重要的消費者配置是獲取大小。
所有的配置在配置部分都有記載。

生產伺服器配置

下面是一個生產伺服器配置的例子：

  # ZooKeeper
  zookeeper.connect=[list of ZooKeeper servers]

  # Log configuration
  num.partitions=8
  default.replication.factor=3
  log.dir=[List of directories. Kafka should have its own dedicated disk(s) or SSD(s).]

  # Other configurations
  broker.id=[An integer. Start with 0 and increment by 1 for each new broker.]
  listeners=[list of listeners]
  auto.create.topics.enable=false
  min.insync.replicas=2
  queued.max.requests=[number of concurrent requests]

 

我們的客戶端配置在不同的用例之間有相當大的差異。

 

6.5 Java版本

支援Java 8和Java 11。如果啟用了TLS，Java 11的效能會顯著提高，所以強烈推薦使用（它還包括一些其他效能改進。G1GC、CRC32C、Compact Strings、執行緒本地握手等）。) 從安全形度來看，我們推薦最新發布的補丁版本，因為舊的免費版本已經披露了安全漏洞。用基於OpenJDK的Java實現（包括Oracle JDK）執行Kafka的典型配置是：

-Xmx6g -Xms6g -XX:MetaspaceSize=96m -XX:+UseG1GC
  -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1HeapRegionSize=16M
  -XX:MinMetaspaceFreeRatio=50 -XX:MaxMetaspaceFreeRatio=80 -XX:+ExplicitGCInvokesConcurrent

 

以下是LinkedIn最繁忙的一個叢集（高峰期）使用上述Java引數的統計資料，供參考：

• 60個broker
• 5萬個分割槽(複製係數為2)
• 80萬條/秒的資訊
• 入300 MB/秒，出1 GB/秒以上

該叢集中的所有broker，90%的GC暫停時間約為21ms，每秒只有不到1個新生代GC。

 

6.6 硬體和作業系統

我們使用的是雙四核Intel Xeon機器，記憶體為24GB。
你需要足夠的記憶體來緩衝活躍的讀寫器。你可以通過假設你希望能夠緩衝30秒，並計算你的記憶體需求為write_throughput*30，對記憶體需求做一個包絡後的估計。

磁碟的吞吐量很重要。我們有8x7200轉的SATA硬碟。一般來說，磁碟吞吐量是效能瓶頸，磁碟越多越好。取決於你如何配置重新整理行為，你可能會或可能不會受益於更昂貴的磁碟（如果你經常強制重新整理，那麼更高轉速的SAS驅動器可能會更好）。

 

作業系統

Kafka應該在任何unix系統上執行良好，並且已經在Linux和Solaris上進行了測試。
我們已經看到了一些在Windows上執行的問題，Windows目前不是一個很好的支援平臺，儘管我們很樂意改變這種情況。

它不太可能需要太多的作業系統級別的調整，但是有三個潛在的重要的作業系統級別的配置。

• 檔案描述符限制。Kafka對日誌段和開放連線使用檔案描述符。如果一個broker託管了許多分割槽，考慮到broker至少需要(number_of_partitions)*(partition_size/segment_size)來跟蹤所有的日誌段，此外還有broker的連線數。我們建議至少為broker程式提供100000個允許的檔案描述符作為起點。注意：mmap()函式為與檔案描述符 fildes 相關聯的檔案新增了一個額外的引用，這個引用不會被隨後對該檔案描述符的 close()刪除。當沒有更多的對映到檔案時，這個引用就會被刪除。
• 最大套接字緩衝區大小：可以增加，以實現這裡所說的資料中心之間的高效能資料傳輸。
• 一個程式可能擁有的記憶體對映區域的最大數量（又名vm.max_map_count）。參見Linux核心文件。在考慮一個broker可能擁有的最大分割槽數時，你應該關注這個作業系統級別的屬性。預設情況下，在一些Linux系統上，vm.max_map_count的值是65535左右。每個分割槽分配的每個日誌段，都需要一對索引/時間索引檔案，每個檔案消耗1個地圖區域。換句話說，每個日誌段使用2個地圖區域。因此，每個分割槽只要承載一個日誌段，就至少需要2個地圖區域。也就是說，在一個broker上建立50000個分割槽將導致100000個地圖區域的分配，並且很可能導致broker在預設的vm.max_map_count系統上以OutOfMemoryError（地圖失敗）的方式崩潰。請記住，每個分割槽的日誌段數根據段的大小、負載強度、保留策略的不同而不同，一般來說，往往會超過一個。

磁碟和檔案系統

我們建議使用多個驅動器來獲得良好的吞吐量，並且不要與應用程式日誌或其他作業系統檔案系統活動共享用於Kafka資料的相同驅動器，以確保良好的延遲。你可以將這些硬碟一起RAID成一個卷，或者將每個硬碟格式化並掛載為自己的目錄。由於Kafka具有複製功能，RAID提供的冗餘也可以在應用層提供。這種選擇有幾個權衡。
如果你配置了多個資料目錄，分割槽將被輪流分配到資料目錄中。每個分割槽將完全在其中一個資料目錄中。如果資料在分割槽之間沒有得到很好的平衡，就會導致磁碟之間的負載不平衡。

RAID有可能在平衡磁碟之間的負載方面做得更好(儘管它似乎並不總是這樣)，因為它在較低的層次上平衡負載。RAID的主要缺點是，它通常會對寫入吞吐量造成很大的效能衝擊，並減少可用的磁碟空間。

RAID的另一個潛在好處是能夠容忍磁碟故障。然而我們的經驗是，重建RAID陣列是如此的I/O密集型，以至於它有效地禁用了伺服器，所以這並沒有提供多少真正的可用性改進。

 

應用程式與作業系統重新整理管理

Kafka總是立即將所有資料寫入檔案系統，並支援配置重新整理策略的功能，控制何時使用重新整理將資料從作業系統快取中強制寫入磁碟。這個重新整理策略可以控制在一段時間後或在寫入一定數量的訊息後強制將資料放到磁碟上。這個配置有幾種選擇。

Kafka最終必須呼叫fsync才能知道資料被重新整理。當從崩潰中恢復任何不知道是fsync'd的日誌段時，Kafka將通過檢查每個訊息的CRC來檢查其完整性，並且還重建附帶的偏移索引檔案，作為啟動時執行的恢復過程的一部分。

請注意，Kafka中的耐久性不需要將資料同步到磁碟上，因為失敗的節點總是會從其副本中恢復。

我們建議使用預設的重新整理設定，它完全禁用應用程式fsync。這意味著依靠作業系統和Kafka自己的後臺重新整理來完成。這為大多數用途提供了最好的選擇：無需調整旋鈕，極大的吞吐量和延遲，以及完全的恢復保證。我們普遍覺得複製提供的保證比同步到本地磁碟更強，然而偏執狂還是可能更喜歡兩者兼備，而且仍然支援應用級fsync策略。

使用應用級重新整理設定的缺點是它的磁碟使用模式效率較低（它給作業系統重新排序寫入的餘地較小），而且它可能會引入延遲，因為大多數Linux檔案系統中的fsync會阻止對檔案的寫入，而後臺重新整理做的是更細化的頁級鎖定。

一般來說，你不需要對檔案系統進行任何低階別的調整，但在接下來的幾節中，我們將介紹一些這方面的內容，以防有用。

 

瞭解Linux作業系統的重新整理行為

在Linux中，寫入檔案系統的資料被儲存在pagecache中，直到必須將其寫入磁碟（由於應用程式級的fsync或作業系統自己的重新整理策略）。資料的重新整理是由一組稱為pdflush的後臺執行緒（或在2.6.32後的核心中稱為 "flusher執行緒"）完成的。
Pdflush有一個可配置的策略來控制快取中可以保留多少髒資料，以及在多長時間內必須將其寫回磁碟。這裡描述了這個策略。當Pdflush無法跟上資料寫入的速度時，它最終會導致寫入過程阻塞，從而在寫入過程中產生延遲，減緩資料的積累。

你可以通過執行以下操作來檢視當前作業系統的記憶體使用狀況

 

 > cat /proc/meminfo 

 

這些值的含義在上面的連結中進行了描述。
與程式內快取相比，使用pagecache來儲存將寫入磁碟的資料有幾個優勢。

• I/O排程器會將連續的小寫合併成較大的物理寫，從而提高吞吐量。
• I/O排程器會嘗試重新排序寫入，以減少磁碟頭的移動，從而提高吞吐量。
• 它自動使用機器上所有的可用記憶體。

 

檔案系統選擇

Kafka使用的是磁碟上的常規檔案，因此它對特定的檔案系統沒有硬性依賴。不過，使用率最高的兩個檔案系統是EXT4和XFS。從歷史上看，EXT4的使用量更大，但最近對XFS檔案系統的改進表明，它對Kafka的工作負載有更好的效能特性，而且在穩定性方面沒有任何妥協。

對比測試是在一個具有重大訊息負載的叢集上進行的，使用各種檔案系統建立和掛載選項。Kafka中被監控的主要指標是 "請求本地時間"，表示追加操作所需的時間。XFS帶來了更好的本地時間（160ms vs. 最佳EXT4配置的250ms+），以及更低的平均等待時間。XFS效能也顯示出磁碟效能的變化較小。

一般檔案系統注意事項

對於任何用於資料目錄的檔案系統，在Linux系統上，建議在掛載時使用以下選項。

• noatime   這個選項可以在讀取檔案時禁止更新檔案的atime（最後訪問時間）屬性。這可以消除大量的檔案系統寫入，特別是在引導消費者的情況下。Kafka根本不依賴atime屬性，所以禁用這個是安全的。

XFS檔案系統注意事項

XFS檔案系統有大量的自動調優功能，所以無論是在建立檔案系統時還是在掛載時，都不需要改變預設設定。唯一值得考慮的調優引數是

• largeio: 這會影響 stat 呼叫報告的首選 I/O 大小。雖然這可以讓較大的磁碟寫入時獲得更高的效能，但在實踐中，它對效能的影響微乎其微，甚至沒有影響。
• nobarrier。對於有電池支援快取的底層裝置，這個選項可以通過禁用週期性的寫入重新整理來提供更高的效能。但是，如果底層裝置表現良好，它會向檔案系統報告它不需要重新整理，這個選項就沒有影響。

EXT4檔案系統注意事項

EXT4是Kafka資料目錄的一個服務性的檔案系統選擇，然而要想獲得最大的效能，需要調整幾個掛載選項。此外，這些選項在故障情況下一般是不安全的，會導致更多的資料丟失和損壞。對於單個broker故障，這並不是什麼大問題，因為可以擦除磁碟，並從叢集中重建副本。在多重故障的情況下，例如斷電，這可能意味著底層檔案系統（因此也是資料）的損壞，不容易恢復。以下選項可以調整。

• data=writeeback: Ext4預設為data=ordered，它對一些寫入進行了強烈的排序。Kafka不需要這個排序，因為它對所有未重新整理的日誌進行非常偏執的資料恢復。這個設定去掉了排序約束，似乎可以顯著降低延遲。
• 禁用日誌。日誌是一種權衡：它使伺服器崩潰後的重啟速度更快，但它引入了大量額外的鎖定，增加了寫入效能的變數。那些不關心重啟時間並希望減少寫延遲峰值的主要來源的人可以完全關閉日誌。
• commit=num_secs。這將調整 ext4 向後設資料日誌提交的頻率。將其設定為較低的值可以減少崩潰時未重新整理資料的損失。將其設定為較高的值將提高吞吐量。
• nobh：當使用data=writeback模式時，該設定控制額外的排序保證。這對Kafka來說應該是安全的，因為我們不依賴於寫排序，並提高吞吐量和延遲。
• delalloc。延遲分配意味著檔案系統避免分配任何塊，直到物理寫發生。這允許ext4分配一個大的範圍，而不是較小的頁面，並有助於確保資料按順序寫入。這個特性對於吞吐量來說是非常好的。它似乎涉及到檔案系統中的一些鎖定，這增加了一點延遲差異。

 

6.7 監測

Kafka在伺服器中使用Yammer Metrics進行度量報告。Java客戶端使用Kafka Metrics，這是一個內建的度量登錄檔，可以最大限度地減少拉到客戶端應用程式中的過渡性依賴關係。兩者都通過JMX暴露度量，並且可以配置使用可插拔的統計報告器來報告統計資料，以掛接到您的監控系統。
所有的Kafka速率指標都有一個相應的累計計數指標，字尾為-total。例如，records-consumed-rate有一個對應的度量，名為records-consumed-total。

檢視可用指標的最簡單方法是啟動jconsole，並將其指向正在執行的kafka客戶端或伺服器；這將允許使用JMX瀏覽所有指標。

使用JMX進行遠端監控的安全注意事項

Apache Kafka 預設情況下是禁用遠端 JMX 的。您可以通過為使用 CLI 或標準 Java 系統屬性啟動的程式設定環境變數 JMX_PORT 來啟用遠端 JMX 的遠端監控，從而以程式設計方式啟用遠端 JMX。在生產場景中啟用遠端 JMX 時，您必須啟用安全功能，以確保未經授權的使用者無法監視或控制您的broker或應用程式以及執行這些應用程式的平臺。請注意，在Kafka中，預設情況下，JMX的身份驗證是被禁用的，對於生產部署，必須通過為使用CLI啟動的程式設定環境變數KAFKA_JMX_OPTS或設定適當的Java系統屬性來覆蓋安全配置。請參閱使用JMX技術的監控和管理，瞭解有關JMX安全的詳細資訊。

我們對以下指標進行圖形化和警報：

 

描述	指標名稱	值域
訊息速率	kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec
客戶端訊息速率	kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec
從其他broker同步訊息速率	kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesInPerSec
請求速率	kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower}
錯誤速率	kafka.network:type=RequestMetrics,name=ErrorsPerSec,request=([-.\w]+),error=([-.\w]+)	按請求型別和錯誤程式碼計算的響應中的錯誤數量。如果一個響應包含多個錯誤，則會計算所有錯誤。error=NONE表示成功的響應。
請求大小	kafka.network:type=RequestMetrics,name=RequestBytes,request=([-.\w]+)	每個請求型別的請求大小
臨時記憶體大小	kafka.network:type=RequestMetrics,name=TemporaryMemoryBytes,request={Produce|Fetch}	用於訊息格式轉換和解壓的臨時記憶體
訊息格式轉換時間	kafka.network:type=RequestMetrics,name=MessageConversionsTimeMs,request={Produce|Fetch}	資訊格式轉換所花費的時間，以毫秒為單位。
訊息格式轉換速率	kafka.server:type=BrokerTopicMetrics,name={Produce|Fetch}MessageConversionsPerSec,topic=([-.\w]+)	需要轉換電文格式的記錄數量。
請求佇列大小	kafka.network:type=RequestChannel,name=RequestQueueSize	請求佇列大小
客戶端的位元組輸出速率	kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec
傳送到其他broker位元組輸出速率	kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesOutPerSec
由於沒有為壓縮主題指定金鑰而導致的訊息驗證失敗率	kafka.server:type=BrokerTopicMetrics,name=NoKeyCompactedTopicRecordsPerSec
因無效魔數導致的資訊驗證失敗率	kafka.server:type=BrokerTopicMetrics,name=InvalidMagicNumberRecordsPerSec
由於錯誤的crc校驗和而導致的資訊驗證失敗率	kafka.server:type=BrokerTopicMetrics,name=InvalidMessageCrcRecordsPerSec
由於批次中的非連續偏移或序列號導致的資訊驗證失敗率	kafka.server:type=BrokerTopicMetrics,name=InvalidOffsetOrSequenceRecordsPerSec
日誌重新整理速度和時間	kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMs
# 複製不足的分割槽數（未重新分配的副本數-ISR數>0）	kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions	0
# 小於最小Isr分割槽的數量(|ISR| < min.insync.replicas)	kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount	0
# 等於最小Isr分割槽的數量 (|ISR| = min.insync.replicas)	kafka.server:type=ReplicaManager,name=AtMinIsrPartitionCount	0
# 離線的日誌目錄	kafka.log:type=LogManager,name=OfflineLogDirectoryCount	0
broker的控制器是否活躍	kafka.controller:type=KafkaController,name=ActiveControllerCount	在叢集中，應該有一個broker應該是1
選舉leader的速率	kafka.controller:type=ControllerStats,name=LeaderElectionRateAndTimeMs	當出現broker故障時，非零
不乾淨的選舉leader的速率	kafka.controller:type=ControllerStats,name=UncleanLeaderElectionsPerSec	0
待刪除的topic的數量	kafka.controller:type=KafkaController,name=TopicsToDeleteCount
待刪除的分割槽數量	kafka.controller:type=KafkaController,name=ReplicasToDeleteCount
待刪除的不合格的topic的數量	kafka.controller:type=KafkaController,name=TopicsIneligibleToDeleteCount
待刪除的不合格的分割槽數量	kafka.controller:type=KafkaController,name=ReplicasIneligibleToDeleteCount
分割槽計數	kafka.server:type=ReplicaManager,name=PartitionCount	通常是奇數
Leader副本計數	kafka.server:type=ReplicaManager,name=LeaderCount	通常是奇數
ISR 收縮速率	kafka.server:type=ReplicaManager,name=IsrShrinksPerSec	如果一個broker當機，部分分割槽的ISR會縮減。當該broker再次啟動時，一旦副本被完全趕上，ISR將被擴大。除此之外，ISR收縮率和擴張率的預期值都是0。
ISR 擴充套件速率	kafka.server:type=ReplicaManager,name=IsrExpandsPerSec	參考上面
追隨者和領導者副本之間的訊息最大滯後性	kafka.server:type=ReplicaFetcherManager,name=MaxLag,clientId=Replica	滯後時間應與最大的一個生產者請求大小成正比。
每個追隨者副本的訊息滯後	kafka.server:type=FetcherLagMetrics,name=ConsumerLag,clientId=([-.\w]+),topic=([-.\w]+),partition=([0-9]+)	滯後時間應與最大的一個生產者請求大小成正比。
在生產者傳送佇列中等待的請求數量	kafka.server:type=DelayedOperationPurgatory,name=PurgatorySize,delayedOperation=Produce	如果使用ack=-1，則為非零。
在消費者佇列中等待的請求	kafka.server:type=DelayedOperationPurgatory,name=PurgatorySize,delayedOperation=Fetch	大小取決於消費者中的fetch.wait.max.ms。
請求總計用時	kafka.network:type=RequestMetrics,name=TotalTimeMs,request={Produce|FetchConsumer|FetchFollower}	分為佇列、本地、遠端和響應傳送時間。
請求在請求佇列中的等待時間	kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request={Produce|FetchConsumer|FetchFollower}
請求在leader處處理的時間	kafka.network:type=RequestMetrics,name=LocalTimeMs,request={Produce|FetchConsumer|FetchFollower}
請求等待follower的時間	kafka.network:type=RequestMetrics,name=RemoteTimeMs,request={Produce|FetchConsumer|FetchFollower}	當ACK=-1時，生產請求的非零。
請求在響應佇列中的等待時間	kafka.network:type=RequestMetrics,name=ResponseQueueTimeMs,request={Produce|FetchConsumer|FetchFollower}
發出答覆的時間	kafka.network:type=RequestMetrics,name=ResponseSendTimeMs,request={Produce|FetchConsumer|FetchFollower}
消費者落後於生產者的資訊數量。由消費者釋出，而非broker釋出。	kafka.consumer:type=consumer-fetch-manager-metrics,client-id={client-id} Attribute: records-lag-max
網路處理器空閒的平均時長。	kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent	在0和1之間，理想的情況是>0.3。
由於客戶機沒有重新認證，然後使用超過到期時間的連線進行重新認證以外的其他操作而在處理器上斷開的連線數。	kafka.server:type=socket-server-metrics,listener=[SASL_PLAINTEXT|SASL_SSL],networkProcessor=<#>,name=expired-connections-killed-count	理想情況下，當重新認證被啟用時，意味著不再有任何舊的、2.2.0之前的客戶端連線到這個（監聽器、處理器）組合上。
由於客戶機沒有重新認證，然後在過期後將連線用於除重新認證以外的其他用途而斷開的連線總數，跨越所有處理器。	kafka.network:type=SocketServer,name=ExpiredConnectionsKilledCount	理想情況下，當重新認證被啟用時，意味著不再有任何舊的、2.2.0之前的客戶端連線到這個broker。
請求處理程式執行緒空閒的平均時長。	kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent	在0和1之間，理想的情況是>0.3。
每個（使用者、客戶端ID）、使用者或客戶端ID的頻寬配額指標	kafka.server:type={Produce|Fetch},user=([-.\w]+),client-id=([-.\w]+)	兩個屬性。 throttle-time表示客戶端被節流的時間，單位為ms。理想情況下=0.byte-rate表示客戶端的資料產生/消耗率，單位為位元組/秒。對於(user，client-id)配額，使用者和client-id都要指定。如果對客戶端應用了per-client-id配額，則不指定使用者。如果應用了per-user配額，則不指定client-id。
按(使用者、客戶機ID)、使用者或客戶機ID申請配額指標。	kafka.server:type=Request,user=([-.\w]+),client-id=([-.\w]+)	兩個屬性.throttle-time表示客戶端被節流的時間，單位為ms。理想情況下=0.request-time表示在broker網路和I/O執行緒中處理來自客戶端組的請求所花費的時間百分比。對於(user，client-id)配額，使用者和client-id都要指定。如果對客戶端應用了per-client-id配額，則不指定使用者。如果應用了per-user配額，則不指定client-id。
免於節流的請求	kafka.server:type=Request	exempt-throttle-time表示經紀網路和I/O執行緒處理免於節流的請求所花費的時間百分比。
ZooKeeper客戶端請求延遲	kafka.server:type=ZooKeeperClientMetrics,name=ZooKeeperRequestLatencyMs	從broker發出ZooKeeper請求的延遲，以毫秒計。
ZooKeeper連線狀態	kafka.server:type=SessionExpireListener,name=SessionState	brokerZooKeeper會話的連線狀態可能是Disconnected|SyncConnected|AuthFailed|ConnectedReadOnly|SaslAuthenticated|Expired。
載入組後設資料的最大時間	kafka.server:type=group-coordinator-metrics,name=partition-load-time-max	從過去30秒內載入的消費者偏移分割槽載入偏移量和組後設資料所花費的最大時間（包括等待載入任務被安排的時間），以毫秒為單位。
載入組後設資料的平均時間	kafka.server:type=group-coordinator-metrics,name=partition-load-time-avg	過去30秒內從消費者偏移分割槽載入偏移量和組後設資料所花費的平均時間（包括等待載入任務被安排的時間），單位為毫秒。
載入交易後設資料的最大時間	kafka.server:type=transaction-coordinator-metrics,name=partition-load-time-max	從過去30秒內載入的消費者偏移分割槽載入事務後設資料所花費的最大時間（包括等待載入任務被安排的時間），單位為毫秒。
載入交易後設資料的平均時間	kafka.server:type=transaction-coordinator-metrics,name=partition-load-time-avg	從過去30秒內載入的消費者偏移分割槽中載入事務後設資料所需的平均時間（包括等待載入任務被安排的時間），以毫秒為單位。
消費者組偏離量統計	kafka.server:type=GroupMetadataManager,name=NumOffsets	消費者組提交的偏移量總數
消費者組總數	kafka.server:type=GroupMetadataManager,name=NumGroups	消費者組的總數
消費者組總數，每種狀態	kafka.server:type=GroupMetadataManager,name=NumGroups[PreparingRebalance,CompletingRebalance,Empty,Stable,Dead]	處於不同狀態的消費者組總數。 PreparingRebalance, CompletingRebalance, Empty, Stable, Dead
重新分配分割槽的數量	kafka.server:type=ReplicaManager,name=ReassigningPartitions	每臺broker機器上正在重新分配的leader分割槽的數量
重新分配流量的出站位元組率	kafka.server:type=BrokerTopicMetrics,name=ReassignmentBytesOutPerSec
重新分配流量的傳入位元組率	kafka.server:type=BrokerTopicMetrics,name=ReassignmentBytesInPerSec

生產者/消費者/連線/流的共同監測指標

以下指標在生產者/消費者/連線者/流例項中可用。具體的指標，請看以下章節。

度量值	描述	度量名稱
connection-close-rate	視窗中每秒鐘關閉的連線數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
connection-close-total	視窗中關閉的連線總數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
connection-creation-rate	視窗中每秒鐘建立的新連線。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
connection-creation-total	視窗中建立的新連線總數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
network-io-rate	每秒鐘對所有連線的平均網路操作次數（讀或寫）。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
network-io-total	所有連線上的網路操作總數（讀或寫）。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
outgoing-byte-rate	每秒鐘向所有伺服器傳送的平均外發位元組數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
outgoing-byte-total	傳送給所有伺服器的總位元組數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
request-rate	平均每秒發出的請求數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
request-total	傳送的請求總數；	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
request-size-avg	視窗中所有請求的平均大小。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
request-size-max	視窗中傳送的任何請求的最大尺寸。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
incoming-byte-rate	從所有socket上讀取的位元組/秒。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
incoming-byte-total	從所有套接字讀取的總位元組數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
response-rate	每秒鐘收到的答覆。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
response-total	收到的答覆總數	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
select-rate	I/O層每秒檢查新I/O執行的次數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
select-total	I/O層檢查新I/O執行的總次數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
io-wait-time-ns-avg	I/O執行緒等待一個準備好讀或寫的socket的平均時間，單位為納秒。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
io-wait-ratio	I/O執行緒等待的時間分數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
io-time-ns-avg	每次選擇呼叫的平均I/O時間長度，單位為納秒。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
io-ratio	I/O執行緒做I/O的時間分數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
connection-count	當前的活動連線數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
successful-authentication-rate	每秒鐘使用SASL或SSL成功認證的連線。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
successful-authentication-total	使用SASL或SSL成功認證的連線總數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
failed-authentication-rate	認證失敗的每秒連線數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
failed-authentication-total	未能通過認證的連線總數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
successful-reauthentication-rate	每秒鐘使用SASL成功重新認證的連線。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
successful-reauthentication-total	使用SASL成功重新認證的連線總數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
reauthentication-latency-max	觀察到的因重新認證而產生的最大延遲，單位為毫秒。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
reauthentication-latency-avg	觀察到的平均延遲時間，以毫秒為單位，由於重新認證。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
failed-reauthentication-rate	重新認證失敗的每秒連線數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
failed-reauthentication-total	未能重新認證的連線總數。	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
successful-authentication-no-reauth-total	不支援重新認證的2.2.0之前的舊版SASL客戶端成功認證的連線總數。只能為非零	kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)

每個broker的指標 生產者/消費者/連線/流

以下指標在生產者/消費者/連線者/流例項中可用。具體的指標，請看以下章節。

屬性名稱	描述	MBEAN NAME
outgoing-byte-rate	節點平均每秒傳送的外發位元組數。	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)
outgoing-byte-total	一個節點傳送出去的總位元組數。	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)
request-rate	一個節點平均每秒傳送的請求數。	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)
request-total	為一個節點傳送的總請求數。	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)
request-size-avg	一個節點的視窗中所有請求的平均大小。	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)
request-size-max	一個節點在視窗中傳送的任何請求的最大尺寸。	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)
incoming-byte-rate	節點每秒收到的平均位元組數。	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)
incoming-byte-total	節點收到的總位元組數。	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)
request-latency-avg	節點的平均請求延遲，單位為ms。	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)
request-latency-max	節點的最大請求延遲，單位為ms。	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)
response-rate	節點每秒收到的響應。	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)
response-total	一個節點收到的答覆總數	kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)

 

生產者監測

生產者例項有以下指標。

屬性名稱	描述	MBEAN NAME
waiting-threads	等待緩衝區記憶體查詢記錄的使用者執行緒阻塞的數量。	kafka.producer:type=producer-metrics,client-id=([-.\w]+)
buffer-total-bytes	客戶端可以使用的最大緩衝區記憶體量（無論當前是否使用）。	kafka.producer:type=producer-metrics,client-id=([-.\w]+)
buffer-available-bytes	未被使用的緩衝區記憶體總量（未分配或在空閒列表中）。	kafka.producer:type=producer-metrics,client-id=([-.\w]+)
bufferpool-wait-time	應用者等待空間分配的時間分數。	kafka.producer:type=producer-metrics,client-id=([-.\w]+)

生產者sender執行緒指標

kafka.producer:type=producer-metrics,client-id="{client-id}"
	屬性名稱	描述
	batch-size-avg	每個分割槽每次請求傳送的平均位元組數。
	batch-size-max	每個分割槽每次請求傳送的最大位元組數。
	batch-split-rate	每秒平均分批次數
	batch-split-total	批次分割的總數量
	compression-rate-avg	記錄批次的平均壓縮率，定義為壓縮批次大小與未壓縮大小的平均比率。
	metadata-age	當前正在使用的生產者後設資料的年齡，以秒為單位。
	produce-throttle-time-avg	請求被broker節流的平均時間，以毫秒計
	produce-throttle-time-max	broker對請求進行節流的最大時間，以毫秒為單位。
	record-error-rate	平均每秒鐘傳送的導致錯誤的記錄數量。
	record-error-total	導致錯誤的記錄傳送總數。
	record-queue-time-avg	以ms為單位的記錄批次在傳送緩衝區中花費的平均時間。
	record-queue-time-max	記錄批次在傳送緩衝區中花費的最大時間，單位為ms。
	record-retry-rate	平均每秒鐘的重試記錄傳送次數。
	record-retry-total	重試記錄傳送的總次數
	record-send-rate	平均每秒傳送的記錄數。
	record-send-total	傳送的記錄總數。
	record-size-avg	平均記錄大小
	record-size-max	最大記錄大小
	records-per-request-avg	每次請求的平均記錄數量；
	request-latency-avg	平均請求延遲時間(ms)
	request-latency-max	最大請求延遲，單位為ms
	requests-in-flight	目前等待答覆的飛行中請求的數量。
kafka.producer:type=producer-topic-metrics,client-id="{client-id}",topic="{topic}"
	屬性名稱	描述
	byte-rate	一個主題平均每秒傳送的位元組數。
	byte-total	一個主題的總髮送位元組數。
	compression-rate	一個主題的記錄批次的平均壓縮率，定義為壓縮後的批次大小與未壓縮大小的平均比例。
	record-error-rate	每秒鐘平均傳送記錄的次數，導致一個主題出現錯誤。
	record-error-total	導致一個主題出錯的記錄傳送總數。
	record-retry-rate	一個主題的平均每秒鐘重試記錄傳送次數。
	record-retry-total	一個主題的重試記錄傳送總數。
	record-send-rate	一個主題平均每秒傳送的記錄數。
	record-send-total	一個主題的總髮送記錄數。

 

消費者監測

消費者例項有以下指標：

屬性名稱	描述	MBEAN NAME
time-between-poll-avg	poll()呼叫之間的平均延遲。	kafka.consumer:type=consumer-metrics,client-id=([-.\w]+)
time-between-poll-max	poll()呼叫之間的最大延遲。	kafka.consumer:type=consumer-metrics,client-id=([-.\w]+)
last-poll-seconds-ago	上次呼叫poll()後的秒數。	kafka.consumer:type=consumer-metrics,client-id=([-.\w]+)
poll-idle-ratio-avg	消費者的poll()相對於等待使用者程式碼處理記錄的平均空閒時間的分數。	kafka.consumer:type=consumer-metrics,client-id=([-.\w]+)

消費者組指標

屬性名稱	描述	MBEAN NAME
commit-latency-avg	提交請求的平均時間	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
commit-latency-max	提交請求所需的最大時間	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
commit-rate	每秒鐘的提交次數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
commit-total	提交總次數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
assigned-partitions	當前分配給該消費者的分割槽數量。	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
heartbeat-response-time-max	接收心跳請求響應所需的最大時間。	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
heartbeat-rate	平均每秒心跳次數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
heartbeat-total	心跳的總次數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
join-time-avg	小組重新加入的平均時間	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
join-time-max	小組重新加入所需的最長時間	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
join-rate	每秒鐘加入的組數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
join-total	消費者組加盟的總機器數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
sync-time-avg	組同步的平均時間	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
sync-time-max	組同步的最大時間	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
sync-rate	每秒鐘的組同步次數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
sync-total	群體同步的總次數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
rebalance-latency-avg	組內重新平衡所需的平均時間。	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
rebalance-latency-max	組內重新平衡所需的最大時間。	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
rebalance-latency-total	迄今為止，消費者組重新平衡所需的總時間。	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
rebalance-total	消費者組再平衡總數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
rebalance-rate-per-hour	每小時再平衡次數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
failed-rebalance-total	失敗的消費者組再平衡次數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
failed-rebalance-rate-per-hour	每小時失敗的再平衡總數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
last-rebalance-seconds-ago	最後一次發生再平衡過去的時間 秒數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
last-heartbeat-seconds-ago	最後一次收到控制器的心跳訊號過去的時間 秒數	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
partitions-revoked-latency-avg	由on-partitions-revoked rebalance監聽器回撥的平均時間。	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
partitions-revoked-latency-max	由on-partitions-revoked rebalance監聽器回撥的最大時間。	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
partitions-assigned-latency-avg	分割槽分配的重新平衡監聽器回撥所需的平均時間。	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
partitions-assigned-latency-max	分割槽分配的重新平衡監聽器回撥所需的最大時間。	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
partitions-lost-latency-avg	分割槽丟失的重新平衡監聽器回撥的平均時間。	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)
partitions-lost-latency-max	on-partitions-lost rebalance監聽器回撥的最大時間。	kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+)

消費者拉取效能

kafka.consumer:type=consumer-fetch-manager-metrics,client-id="{client-id}"
	屬性名稱	描述
	bytes-consumed-rate	每秒鐘消耗的平均位元組數。
	bytes-consumed-total	消耗的總位元組數
	fetch-latency-avg	拉取一個請求的平均時間
	fetch-latency-max	拉取一個請求最大時間
	fetch-rate	每秒鐘拉取的請求的數量
	fetch-size-avg	每秒鐘拉取的請求的平均大小 位元組數
	fetch-size-max	每次請求獲取的最大位元組數。
	fetch-throttle-time-avg	平均節流時間（毫秒）
	fetch-throttle-time-max	最大節流時間(ms)
	fetch-total	獲取請求的總次數。
	records-consumed-rate	每秒鐘消耗的平均記錄數
	records-consumed-total	消耗的記錄總數
	records-lag-max	該視窗中任何分割槽的記錄數的最大滯後量。
	records-lead-min	該視窗中任何分割槽的記錄數的最小前導值。
	records-per-request-avg	每次請求的平均記錄數量
kafka.consumer:type=consumer-fetch-manager-metrics,client-id="{client-id}",topic="{topic}"
	屬性名稱	描述
	bytes-consumed-rate	一個主題每秒消耗的平均位元組數。
	bytes-consumed-total	一個主題消耗的總位元組數。
	fetch-size-avg	一個主題每次請求所獲取的平均位元組數。
	fetch-size-max	一個主題每次請求獲取的最大位元組數。
	records-consumed-rate	某一主題每秒消耗的平均記錄數。
	records-consumed-total	某一主題所消耗的記錄總數。
	records-per-request-avg	每項請求的平均記錄數。
kafka.consumer:type=consumer-fetch-manager-metrics,partition="{partition}",topic="{topic}",client-id="{client-id}"
	屬性名稱	描述
	preferred-read-replica	分割槽的當前讀取副本，如果從領導讀取，則為-1。
	records-lag	分割槽的最新滯後時間
	records-lag-avg	分割槽的平均滯後時間
	records-lag-max	分割槽的最大滯後時間
	records-lead	分割槽的領先程度
	records-lead-avg	分割槽的平均領先幅度
	records-lead-min	分割的最小領先幅度

 

連線監測

一個Connect worker流程包含所有生產者和消費者的度量，以及Connect特有的度量。Worker程式本身有許多指標，而每個聯結器和任務都有額外的指標。

[2020-12-04 10:03:05,630] INFO Metrics scheduler closed (org.apache.kafka.common.metrics.Metrics:668)

[2020-12-04 10:03:05,632] INFO Metrics reporters closed (org.apache.kafka.common.metrics.Metrics:678)

kafka.connect:type=connect-worker-metrics
	屬性名稱	描述
	connector-count	該worker中執行的聯結器數量。
	connector-startup-attempts-total	該worker嘗試過的聯結器啟動總數。
	connector-startup-failure-percentage	這個worker的聯結器啟動失敗的平均比例。
	connector-startup-failure-total	失敗的聯結器啟動總數。
	connector-startup-success-percentage	這個worker的聯結器啟動成功的平均百分比。
	connector-startup-success-total	成功的聯結器啟動總數。
	task-count	該worker執行的任務數量。
	task-startup-attempts-total	該worker嘗試過的任務啟動總數。
	task-startup-failure-percentage	這個worker的任務啟動失敗的平均百分比。
	task-startup-failure-total	任務啟動失敗的總次數。
	task-startup-success-percentage	這個worker的任務開始成功的平均百分比。
	task-startup-success-total	成功的任務啟動總數。
kafka.connect:type=connect-worker-metrics,connector="{connector}"
	屬性名稱	描述
	connector-destroyed-task-count	worker身上聯結器的銷燬任務數量。
	connector-failed-task-count	worker身上的聯結器的失敗任務數。
	connector-paused-task-count	worker上聯結器的暫停任務數。
	connector-running-task-count	worker上聯結器的執行任務數。
	connector-total-task-count	worker上的聯結器的任務數量。
	connector-unassigned-task-count	worker上的聯結器的未分配任務數。
kafka.connect:type=connect-worker-rebalance-metrics
	屬性名稱	描述
	completed-rebalances-total	worker完成的再平衡總數。
	connect-protocol	該叢集使用的Connect協議
	epoch	worker的時代或代數。
	leader-name	組leader的名字。
	rebalance-avg-time-ms	worker重新平衡所花費的平均時間（毫秒）。
	rebalance-max-time-ms	worker重新平衡所花費的最大時間（毫秒）。
	rebalancing	worker目前是否在重新平衡。
	time-since-last-rebalance-ms	worker完成最近一次重新平衡後的時間，以毫秒為單位。
kafka.connect:type=connector-metrics,connector="{connector}"
	屬性名稱	描述
	connector-class	聯結器類的名稱。
	connector-type	聯結器的型別。"source "或 "sink "之一。
	connector-version	聯結器類的版本，由聯結器報告。
	status	聯結器的狀態。"未分配"、"執行"、"暫停"、"失敗 "或 "銷燬 "中的一種。
kafka.connect:type=connector-task-metrics,connector="{connector}",task="{task}"
	屬性名稱	描述
	batch-size-avg	聯結器處理的平均批次大小。
	batch-size-max	聯結器處理的最大批次大小。
	offset-commit-avg-time-ms	該任務提交偏移量所需的平均時間（毫秒）。
	offset-commit-failure-percentage	該任務的偏移提交嘗試失敗的平均百分比。
	offset-commit-max-time-ms	該任務提交偏移量所需的最大時間（毫秒）。
	offset-commit-success-percentage	該任務的偏移提交嘗試成功的平均百分比。
	pause-ratio	該任務在暫停狀態下所花費的時間分數。
	running-ratio	該任務在執行狀態下所花費的時間分數。
	status	聯結器任務的狀態。未分配"、"執行"、"暫停"、"失敗 "或 "銷燬 "中的一種。
kafka.connect:type=sink-task-metrics,connector="{connector}",task="{task}"
	屬性名稱	描述
	offset-commit-completion-rate	平均每秒鐘成功完成的偏移提交次數。
	offset-commit-completion-total	成功完成的偏移提交總數。
	offset-commit-seq-no	當前偏移提交的序列號。
	offset-commit-skip-rate	平均每秒鐘收到的太晚和跳過/忽略的偏移提交完成數。
	offset-commit-skip-total	太晚收到的和跳過/忽略的偏移提交完成總數。
	partition-count	分配給該任務的主題分割槽的數量，屬於該worker中命名的sink聯結器。
	put-batch-avg-time-ms	這個任務把一批匯記錄的平均時間。
	put-batch-max-time-ms	這個任務放一批匯記錄所需的最大時間。
	sink-record-active-count	已從Kafka讀取但尚未完全提交/重新整理/被sink任務認可的記錄數量。
	sink-record-active-count-avg	已從Kafka讀取但尚未完全提交/重新整理/被sink任務認可的記錄的平均數量。
	sink-record-active-count-max	從Kafka讀取但尚未完全提交/重新整理/被sink任務認可的記錄的最大數量。
	sink-record-lag-max	對於任何主題分割槽而言，匯任務落後於消費者位置的記錄數的最大滯後。
	sink-record-read-rate	此任務從 Kafka 讀取的平均每秒記錄數，屬於此 worker 中命名的 sink 聯結器。這是在應用轉換之前。
	sink-record-read-total	自該任務上次重啟以來，該任務從Kafka讀取的屬於該worker中命名的sink聯結器的記錄總數。
	sink-record-send-rate	從轉換中輸出併傳送到該任務的記錄的平均每秒數量，這些記錄屬於該工作者中指定的sink。這是在應用了轉換之後的資料，不包括任何被轉換過濾掉的記錄。
	sink-record-send-total	自任務最後一次重啟以來，從變換中輸出併傳送給該任務的屬於該worker中命名的sink聯結器的記錄總數。
kafka.connect:type=source-task-metrics,connector="{connector}",task="{task}"
	屬性名稱	描述
	poll-batch-avg-time-ms	該任務輪詢一批源記錄所需的平均時間（毫秒）。
	poll-batch-max-time-ms	該任務輪詢一批源記錄所需的最大時間（毫秒）。
	source-record-active-count	這個任務已經產生但還沒有完全寫入Kafka的記錄數量。
	source-record-active-count-avg	該任務已產生但尚未完全寫入Kafka的平均記錄數。
	source-record-active-count-max	該任務已產生但尚未完全寫入Kafka的最大記錄數。
	source-record-poll-rate	此任務在此工作者中屬於命名的源聯結器的平均每秒鐘產生/輪詢（轉換前）的記錄數。
	source-record-poll-total	該任務產生/輪詢的記錄總數（轉換前），屬於該工作者中的指定源聯結器。
	source-record-write-rate	從轉換中輸出並寫入 Kafka 的記錄的平均每秒記錄數，該任務屬於該 Worker 中的命名源聯結器。這是在應用了轉換之後的資料，不包括任何被轉換過濾掉的記錄。
	source-record-write-total	自任務最後一次重啟以來，該任務從變換中輸出並寫入Kafka的記錄數量，這些記錄屬於該worker中命名的源聯結器。
kafka.connect:type=task-error-metrics,connector="{connector}",task="{task}"
	屬性名稱	描述
	deadletterqueue-produce-failures	向掛掉佇列寫入失敗的次數。
	deadletterqueue-produce-requests	試圖寫入掛掉的佇列的次數。
	last-error-timestamp	該任務最後一次遇到錯誤時的時間戳。
	total-errors-logged	記錄的錯誤數量。
	total-record-errors	本任務中記錄處理錯誤的次數。
	total-record-failures	該任務中記錄處理失敗的次數。
	total-records-skipped	由於錯誤而跳過的記錄數量。
	total-retries	重試的操作次數。

 

流監測

一個Kafka Streams例項包含所有的生產者和消費者指標，以及Streams特有的附加指標。預設情況下，Kafka Streams的度量有兩個記錄級別：debug和info。

需要注意的是，度量有一個4層的層次結構。在頂層，有每個啟動的Kafka Streams客戶端的客戶端級指標。每個客戶端都有流執行緒，有自己的度量。每個流執行緒有任務，有自己的指標。每個任務有若干個處理器節點，有自己的指標。每個任務也有許多狀態儲存和記錄快取，都有自己的度量。

使用下面的配置選項來指定你要收集哪些度量。

metrics.recording.level="info"

 

客戶端指標

以下所有的指標都有一個記錄級別的資訊。

屬性名稱	描述	MBEAN NAME
version	Kafka Streams客戶端的版本。	kafka.streams:type=stream-metrics,client-id=([-.\w]+)
commit-id	Kafka Streams客戶端的版本控制提交ID。	kafka.streams:type=stream-metrics,client-id=([-.\w]+)
application-id	Kafka Streams客戶端的應用ID。	kafka.streams:type=stream-metrics,client-id=([-.\w]+)
topology-description	Kafka Streams客戶端中執行的拓撲的描述。	kafka.streams:type=stream-metrics,client-id=([-.\w]+)
state	Kafka Streams客戶端的狀態。	kafka.streams:type=stream-metrics,client-id=([-.\w]+)

執行緒指標

以下所有的指標都有一個記錄級別的資訊。

指標名稱	描述	MBEAN NAME
commit-latency-avg	該執行緒所有執行任務的平均執行時間，以毫秒為單位。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
commit-latency-max	該執行緒所有正在執行的任務中，提交的最大執行時間，單位為ms。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
poll-latency-avg	平均執行時間，單位為毫秒，用於消費者投票。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
poll-latency-max	最大執行時間，以ms為單位，用於消費者輪詢。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
process-latency-avg	平均執行時間，以毫秒為單位，進行處理。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
process-latency-max	最大執行時間，單位為ms，進行處理。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
punctuate-latency-avg	平均執行時間，單位為毫秒，用於標點符號。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
punctuate-latency-max	標點符號的最大執行時間，單位為ms。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
commit-rate	平均每秒提交的次數。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
commit-total	提交的總次數。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
poll-rate	平均每秒鐘的消費者poll呼叫數量。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
poll-total	消費者poll呼叫的總數量。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
process-rate	平均每秒處理的記錄數。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
process-total	處理的記錄總數。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
punctuate-rate	平均每秒鐘的標點符號呼叫次數。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
punctuate-total	標點符號呼叫的總次數。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
task-created-rate	平均每秒建立的任務數。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
task-created-total	建立的任務總數。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
task-closed-rate	平均每秒關閉的任務數。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)
task-closed-total	結束的任務總數。	kafka.streams:type=stream-thread-metrics,thread-id=([-.\w]+)

任務指標

除了drop-records-rate和drop-records-total這兩個指標的記錄級別為info之外，以下所有指標的記錄級別為debug。

指標名稱	描述	MBEAN NAME
process-latency-avg	平均執行時間以ns為單位，進行處理。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
process-latency-max	處理的最大執行時間，以ns為單位。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
process-rate	該任務的所有源處理器節點每秒處理的平均記錄數。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
process-total	該任務的所有源處理器節點的處理記錄總數。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
commit-latency-avg	提交的平均執行時間，以ns為單位。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
commit-latency-max	提交的最大執行時間，單位為ns。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
commit-rate	平均每秒的提交呼叫次數。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
commit-total	提交commit的總次數。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
record-lateness-avg	記錄的平均觀察延遲時間（流時間-記錄時間戳）。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
record-lateness-max	觀察到的最大記錄延遲（流時間-記錄時間戳）。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
enforced-processing-rate	平均每秒的強制處理次數。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
enforced-processing-total	強制處理的總數。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
dropped-records-rate	本任務內平均掉落的記錄數。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)
dropped-records-total	本任務中放棄的記錄總數。	kafka.streams:type=stream-task-metrics,thread-id=([-.\w]+),task-id=([-.\w]+)

節點指標處理器

以下指標僅在某些型別的節點上可用，即程式-速率和程式-總數僅在源處理器節點上可用，壓制-發射-速率和壓制-發射-總數僅在壓制操作節點上可用。所有的指標都有一個記錄級別的除錯。

指標名稱	描述	MBEAN NAME
process-rate	源處理器節點平均每秒處理的記錄數。	kafka.streams:type=stream-processor-node-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),processor-node-id=([-.\w]+)
process-total	源處理器節點每秒處理的記錄總數。	kafka.streams:type=stream-processor-node-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),processor-node-id=([-.\w]+)
suppression-emit-rate	從抑制操作節點下游發出的記錄的速度。	kafka.streams:type=stream-processor-node-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),processor-node-id=([-.\w]+)
suppression-emit-total	從抑制操作節點下游發出的記錄總數。	kafka.streams:type=stream-processor-node-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),processor-node-id=([-.\w]+)

狀態儲存指標

以下所有指標的記錄級別均為debug。需要注意的是，對於使用者自定義的狀態儲存，儲存範圍值在StoreSupplier#metricsScope()中指定；對於內建的狀態儲存，目前我們有。

 

• in-memory-state
• in-memory-lru-state
• in-memory-window-state
• in-memory-suppression (for suppression buffers)
• rocksdb-state (for RocksDB backed key-value store)
• rocksdb-window-state (for RocksDB backed window store)
• rocksdb-session-state (for RocksDB backed session store)

 

壓制緩衝區大小-平均值、壓制緩衝區大小-最大值、壓制緩衝區計數-平均值和壓制緩衝區計數-最大值等指標只適用於壓制緩衝區。所有其他指標都不適用於壓制緩衝區。

指標名稱	描述	MBEAN NAME
put-latency-avg	平均執行時間（ns）。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
put-latency-max	最大執行時間（ns）。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
put-if-absent-latency-avg	平均put-if-absent執行時間，單位為ns。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
put-if-absent-latency-max	最大的put-if-absent執行時間，單位為ns。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
get-latency-avg	平均獲取執行時間，單位為ns。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
get-latency-max	最大獲取執行時間，單位為ns。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
delete-latency-avg	平均刪除執行時間（ns）。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
delete-latency-max	最大刪除執行時間（ns）。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
put-all-latency-avg	平均put-all執行時間，單位為ns。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
put-all-latency-max	最大put-all執行時間，單位為ns。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
all-latency-avg	所有操作的平均執行時間（ns）。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
all-latency-max	所有操作的最大執行時間，單位為ns。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
range-latency-avg	平均範圍執行時間（ns）。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
range-latency-max	最大範圍執行時間，單位為ns。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
flush-latency-avg	平均重新整理執行時間（ns）。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
flush-latency-max	最大重新整理執行時間，單位為ns。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
restore-latency-avg	平均還原執行時間（ns）。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
restore-latency-max	最大還原執行時間，單位為ns。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
put-rate	這個儲存的平均投放率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
put-if-absent-rate	這個儲存的平均放如果率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
get-rate	這個儲存的平均獲取速率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
delete-rate	這個儲存的平均刪除速率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
put-all-rate	這個儲存的平均put-all速率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
all-rate	這個儲存的所有操作的平均速率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
range-rate	該儲存的平均範圍速率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
flush-rate	這個儲存的平均沖洗率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
restore-rate	這個儲存的平均還原率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
suppression-buffer-size-avg	取樣視窗中緩衝資料的平均總大小，以位元組為單位。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),in-memory-suppression-id=([-.\w]+)
suppression-buffer-size-max	取樣視窗中緩衝資料的最大總大小，以位元組為單位。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),in-memory-suppression-id=([-.\w]+)
suppression-buffer-count-avg	取樣視窗中緩衝的平均記錄數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),in-memory-suppression-id=([-.\w]+)
suppression-buffer-count-max	取樣視窗中緩衝的最大記錄數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),in-memory-suppression-id=([-.\w]+)

 

RocksDB指標

RocksDB的度量分為基於統計的度量和基於屬性的度量。前者記錄的是RocksDB狀態儲存收集的統計資料，而後者記錄的是RocksDB公開的屬性。RocksDB收集的統計資料提供了一段時間內的累積測量值，例如寫入狀態儲存的位元組數。RocksDB暴露的屬性提供了當前的測量值，例如，當前使用的記憶體量。請注意，目前內建的RocksDB狀態儲存的儲存範圍如下。

• rocksdb-state (for RocksDB backed key-value store)
• rocksdb-window-state (for RocksDB backed window store)
• rocksdb-session-state (for RocksDB backed session store)

基於RocksDB統計的指標。以下所有基於統計的指標都有一個記錄級別的除錯，因為在RocksDB中收集統計資料可能會對效能產生影響。基於統計的指標每分鐘都會從RocksDB狀態儲存中收集。如果一個狀態儲存由多個RocksDB例項組成，就像隨著時間和會話視窗的聚合一樣，每個度量都會報告狀態儲存的RocksDB例項的聚合情況。

指標名稱	描述	MBEAN NAME
bytes-written-rate	平均每秒寫入RocksDB狀態儲存的位元組數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
bytes-written-total	寫入RocksDB狀態儲存的總位元組數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
bytes-read-rate	平均每秒從RocksDB狀態儲存中讀取的位元組數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
bytes-read-total	從RocksDB狀態儲存中讀取的總位元組數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
memtable-bytes-flushed-rate	平均每秒從記憶體表到磁碟上重新整理的位元組數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
memtable-bytes-flushed-total	從memtable重新整理到磁碟的總位元組數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
memtable-hit-ratio	相對於所有查詢到的memtable來說，memtable的點選率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
block-cache-data-hit-ratio	資料塊的塊快取點選率相對於資料塊的所有查詢到塊快取的比率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
block-cache-index-hit-ratio	索引塊的塊快取點選率相對於索引塊的所有查詢到塊快取的比率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
block-cache-filter-hit-ratio	過濾器塊的塊快取點選率相對於過濾器塊的所有查詢到塊快取的比率。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
write-stall-duration-avg	寫入停頓的平均持續時間（毫秒）。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
write-stall-duration-total	寫入停頓的總時間，單位為ms。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
bytes-read-compaction-rate	壓實過程中平均每秒讀取的位元組數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
bytes-written-compaction-rate	壓實過程中平均每秒寫入的位元組數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
number-open-files	當前開啟的檔案數量。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
number-file-errors-total	檔案錯誤發生的總次數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)

RocksDB基於屬性的度量：以下所有基於屬性的度量都有記錄級別的資訊，並在度量被訪問時被記錄。如果一個狀態儲存由多個RocksDB例項組成，就像隨著時間和會話視窗的聚合一樣，每個度量都會報告該狀態儲存的所有RocksDB例項的總和，除了塊快取度量block-cache-*。如果每個例項都使用自己的塊快取，則塊快取度量報告所有RocksDB例項的總和，如果所有例項共享一個塊快取，則只報告一個例項的記錄值。

指標名稱	描述	MBEAN NAME
num-immutable-mem-table	還沒有重新整理的不可更改的記憶表的數量。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
cur-size-active-mem-table	活動記憶體表的大概大小，以位元組為單位。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
cur-size-all-mem-tables	活動的和未重新整理的不可更改的記憶體表的大致大小，以位元組為單位。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
size-all-mem-tables	活動的、未重新整理的不可變的和釘住的不可變的memtables的大概大小，單位是位元組。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
num-entries-active-mem-table	活動記憶表中的條目數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
num-entries-imm-mem-tables	未重新整理的不可更改記憶表的條目數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
num-deletes-active-mem-table	活動記憶表的刪除條數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
num-deletes-imm-mem-tables	未重新整理的不可更改記憶表的刪除條目數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
mem-table-flush-pending	如果記憶表重新整理待定，該指標報告1，否則報告0。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
num-running-flushes	當前正在執行的沖洗總數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
compaction-pending	如果至少有一次壓實正在進行，則該指標報告1，否則報告0。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
num-running-compactions	當前執行的壓實次數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
estimate-pending-compaction-bytes	估計壓實需要在磁碟上重寫的總位元組數，以使所有層級降到目標大小以下（僅對層級壓實有效）。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
total-sst-files-size	所有SST檔案的總大小，以位元組為單位。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
live-sst-files-size	屬於最新LSM樹的所有SST檔案的總大小，以位元組為單位。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
num-live-versions	LSM樹的實際版本數量。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
block-cache-capacity	塊狀快取的容量，單位為位元組。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
block-cache-usage	駐留在塊快取中的記憶體大小，單位為位元組。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
block-cache-pinned-usage	塊快取中被釘入的條目的記憶體大小，單位為位元組。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
estimate-num-keys	啟用的和未重新整理的不可更改的記憶表和儲存中的估計金鑰數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
estimate-table-readers-mem	讀取SST表所使用的估計記憶體，以位元組為單位，不包括塊快取中使用的記憶體。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
background-errors	背景錯誤的總數。	kafka.streams:type=stream-state-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)

 

記錄快取指標4

以下所有指標的記錄級別均為除錯。

指標名稱	描述	MBEAN NAME
hit-ratio-avg	平均快取命中率定義為快取讀取命中量與快取讀取請求總量的比率。	kafka.streams:type=stream-record-cache-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),record-cache-id=([-.\w]+)
hit-ratio-min	最小快取命中率。	kafka.streams:type=stream-record-cache-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),record-cache-id=([-.\w]+)
hit-ratio-max	最大快取命中率。	kafka.streams:type=stream-record-cache-metrics,thread-id=([-.\w]+),task-id=([-.\w]+),record-cache-id=([-.\w]+)

 

其他

我們建議監控GC時間等統計和各種伺服器統計，如CPU利用率、I/O服務時間等。在客戶端，我們建議監控訊息/位元組速率（全域性和每個主題）、請求速率/大小/時間，在消費端，監控所有分割槽間訊息的最大滯後和最小取回請求速率。對於消費者來說，最大滯後需要小於一個閾值，最小獲取率需要大於0。

 

6.8 Zookeeper

穩定版

目前的穩定分支是3.5。Kafka會定期更新，包括3.5系列的最新版本。

操作ZooKeeper

在操作上，為了健康的ZooKeeper安裝，我們做到以下幾點。

• 物理/硬體/網路佈局的冗餘：儘量不要把它們放在同一個機架上，體面的（但不要太瘋狂）硬體，儘量保持冗餘的電源和網路路徑等。一個典型的ZooKeeper合集有5或7臺伺服器，分別可以容忍2臺和3臺伺服器當機。如果你的部署規模較小，那麼使用3臺伺服器也是可以接受的，但要記住，這種情況下你只能容忍1臺伺服器當機。
• I/O隔離：如果你做了很多寫型別的流量，你幾乎肯定會希望事務日誌在一個專用磁碟組上。對事務日誌的寫入是同步的(但為了效能而分批進行)，因此，併發寫入會明顯影響效能。ZooKeeper快照可以是這樣一個併發寫入的源頭，理想的情況是應該寫在與事務日誌分開的磁碟組上。快照是非同步寫入磁碟的，所以一般情況下與作業系統和訊息日誌檔案共享是可以的。你可以通過dataLogDir引數配置伺服器使用一個單獨的磁碟組。
• 應用隔離。除非你真的瞭解你想安裝在同一個盒子上的其他應用程式的應用模式，否則隔離執行ZooKeeper是個不錯的主意（儘管這可能是一個與硬體能力平衡的行為）。
• 使用虛擬化時要小心。根據你的叢集佈局和讀/寫模式和SLA，它可以工作，但虛擬化層引入的微小開銷可能會增加，並拋開ZooKeeper，因為它可能對時間非常敏感。
• ZooKeeper配置。它是java，確保你給它足夠的堆空間（我們通常用3-5G執行它們，但這主要是由於我們這裡的資料集大小）。不幸的是，我們沒有一個好的公式，但請記住，允許更多的ZooKeeper狀態意味著快照會變得很大，而大的快照會影響恢復時間。事實上，如果快照變得太大了（幾GB），那麼你可能需要增加initLimit引數，以給伺服器足夠的時間來恢復和加入合集。
• 監控。JMX和4個字母詞(4lw)命令都非常有用，它們在某些情況下會重疊(在這些情況下，我們更喜歡4個字母命令，它們看起來更可預測，或者至少，它們與LI監控基礎設施配合得更好)
• 不要過度構建叢集：大型叢集，特別是在重寫使用模式下，意味著大量的叢集內通訊（寫入和後續叢集成員更新的配額），但不要過度構建（並有可能淹沒叢集）。擁有更多的伺服器會增加你的讀取能力。

總的來說，我們儘量讓ZooKeeper系統保持小規模，因為它可以處理負載（加上標準的增長容量規劃），並且儘可能的簡單。與官方版本相比，我們儘量不做任何花哨的配置或應用程式佈局，以及保持儘可能的自我控制。由於這些原因，我們傾向於跳過作業系統的打包版本，因為它有一種傾向，即試圖把東西放在作業系統標準的層次結構中，這可能是 "混亂的"，想要一個更好的方式來形容它。

 

 

7.安全

7.1 安全概述

在0.9.0.0版本中，Kafka社群增加了一些功能，這些功能可以單獨使用，也可以一起使用，增加Kafka叢集的安全性。目前支援以下安全措施。

1. 從客戶（生產者和消費者）、其他broker和工具連線到broker的認證，使用SSL或SASL。Kafka支援以下SASL機制。
   • SASL/GSSAPI (Kerberos) - starting at version 0.9.0.0
   • SASL/PLAIN - starting at version 0.10.0.0
   • SASL/SCRAM-SHA-256 and SASL/SCRAM-SHA-512 - starting at version 0.10.2.0
   • SASL/OAUTHBEARER - starting at version 2.0
2. 從broker到ZooKeeper的連線認證。
3. 使用SSL對broker和客戶機之間、broker之間或broker和工具之間傳輸的資料進行加密（注意，啟用SSL後會出現效能下降，下降的幅度取決於CPU型別和JVM實現）。
4. 客戶端對讀/寫操作的授權
5. 授權是可插拔的，並支援與外部授權服務的整合。

值得注意的是，安全性是可選的 - 支援非安全叢集，以及認證、非認證、加密和非加密客戶端的混合。下面的指南解釋瞭如何在客戶端和broker中配置和使用安全功能。

 

7.2 使用SSL進行加密和認證

Apache Kafka允許客戶端使用SSL對流量進行加密以及認證。預設情況下，SSL是被禁用的，但如果需要的話可以開啟。下面的段落詳細解釋瞭如何設定自己的PKI基礎架構，使用它來建立證照並配置Kafka使用這些證照。

為每個Kafka代理生成SSL金鑰和證照

部署一個或多個支援SSL的broker的第一步是為每個伺服器生成一個公鑰/私鑰對。由於Kafka期望所有的金鑰和證照都儲存在keystores中，我們將使用Java的keytool命令來完成這個任務。該工具支援兩種不同的keystore格式，Java特有的jks格式，現在已經被廢棄了，還有PKCS12。PKCS12是Java版本9的預設格式，為了確保無論使用哪個Java版本都能使用這種格式，以下所有命令都明確指定PKCS12格式

                keytool -keystore {keystorefile} -alias localhost -validity {validity} -genkey -keyalg RSA -storetype pkcs12

 

你需要在上述命令中指定兩個引數。

1. keystorefile：儲存這個broker的金鑰（以及後來的證照）的keystore檔案。keystore檔案包含了這個broker的私鑰和公鑰，因此需要保證它的安全。理想情況下，這一步是在金鑰將被使用的Kafka broker上執行的，因為這個金鑰永遠不應該被傳輸/離開它所要使用的伺服器。
2. validity：金鑰的有效時間，單位為天。請注意，這與證照的有效期不同，證照的有效期將在簽署證照中確定。你可以使用同一個金鑰來申請多個證照：如果你的金鑰的有效期是10年，但你的CA只簽署有效期為一年的證照，你可以使用同一個金鑰與10個證照在一段時間內。

要想獲得一個可以和剛剛建立的私鑰一起使用的證照，需要建立一個證照籤署請求。這個簽名請求，當由一個受信任的CA簽署時，會產生實際的證照，然後可以安裝在金鑰儲存中，並用於認證目的。
要生成證照籤名請求，請為目前建立的所有伺服器金鑰庫執行以下命令：

                keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey -keyalg RSA -destkeystoretype pkcs12 -ext SAN=DNS:{FQDN},IP:{IPADDRESS1}

 

此命令假設你要在證照中新增主機名資訊，如果不是這樣，可以省略擴充套件引數-ext SAN=DNS:{FQDN},IP:{IPADDRESS1}。請看下面的內容：

主機名驗證

啟用主機名驗證後，是將連線到的伺服器所提供的證照中的屬性與該伺服器的實際主機名或ip地址進行核對，以確保你確實連線到了正確的伺服器。
這種檢查的主要原因是為了防止中間人攻擊。對於Kafka來說，這項檢查在預設情況下已經被禁用了很長時間，但是從Kafka 2.0.0開始，伺服器的主機名校驗在預設情況下對客戶端連線和broker之間的連線都是啟用的。
通過將ssl.endpoint.identification.algorithm設定為空字串，可以禁用伺服器主機名驗證。
對於動態配置的broker監聽器，可以使用kafka-configs.sh禁用主機名驗證：

                bin/kafka-configs.sh --bootstrap-server localhost:9093 --entity-type brokers --entity-name 0 --alter --add-config "listener.name.internal.ssl.endpoint.identification.algorithm="

 

注意：在正常情況下，沒有什麼好的理由禁用主機名驗證。

通常情況下，沒有什麼好的理由來禁用主機名驗證，除了最快捷的方式 "只要能正常工作"，然後承諾 "以後有更多的時間時再解決"！如果在正確的時間內完成主機名驗證，並不難，但一旦叢集啟動和執行，就會變得很難。
如果在正確的時間內完成主機名驗證並不難，但一旦叢集啟動並執行，就會變得更加困難--幫你自己一個忙，現在就去做吧!
如果啟用了主機名驗證，客戶端將根據以下兩個欄位之一驗證伺服器的完全合格域名（FQDN）或IP地址。

1. 通用名(CN)
2. 主題替代名稱(SAN)

雖然Kafka會檢查這兩個欄位，但自2000年以來，通用名欄位用於主機名驗證已經被廢棄，應儘可能避免使用。此外，SAN欄位更加靈活，允許在證照中宣告多個DNS和IP條目。
另一個優點是，如果SAN欄位被用於主機名驗證，通用名可以設定為一個更有意義的值，用於授權目的。由於我們需要SAN欄位包含在簽名的證照中，所以在生成簽名請求時將指定它。它也可以在生成金鑰對時指定，但不會自動複製到簽名請求中。
要新增 SAN 欄位，請在 keytool 命令中新增以下引數 -ext SAN=DNS:{FQDN},IP:{IPADDRESS}：

                keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey -keyalg RSA -destkeystoretype pkcs12 -ext SAN=DNS:{FQDN},IP:{IPADDRESS1}

建立你自己的CA

這一步之後，叢集中的每臺機器都有一個公鑰/私鑰對，已經可以用來加密流量，還有一個證照籤署請求，這是建立證照的基礎。要新增認證功能，這個簽名請求需要由一個受信任的權威機構來簽名，這個權威機構將在這一步中建立。
證照頒發機構（CA）負責簽署證照。CA的工作原理就像一個發行護照的政府--政府在每本護照上蓋章（簽名），這樣護照就很難偽造。其他政府則會對印章進行驗證，以確保護照的真實性。同樣，CA對證照進行簽名，密碼學保證簽名的證照在計算上難以偽造。因此，只要CA是一個真實可信的權威機構，客戶就可以有力地保證他們連線到真實的機器。

在本指南中，我們將做自己的證照頒發機構。當在企業環境中建立生產叢集時，這些證照通常會由整個公司都信任的企業CA簽署。請參閱生產中的常見陷阱，瞭解這種情況下需要考慮的一些事情。

由於OpenSSL中的一個錯誤，x509模組不會將CSR中要求的擴充套件欄位複製到最終證照中。由於我們希望SAN擴充套件欄位能出現在證照中以實現主機名驗證，我們將使用ca模組來代替。這需要在生成 CA 金鑰對之前進行一些額外的配置。
將以下列表儲存到一個名為openssl-ca.cnf的檔案中，並根據需要調整有效性和通用屬性的值。

HOME            = .
RANDFILE        = $ENV::HOME/.rnd

####################################################################
[ ca ]
default_ca    = CA_default      # The default ca section

[ CA_default ]

base_dir      = .
certificate   = $base_dir/cacert.pem   # The CA certifcate
private_key   = $base_dir/cakey.pem    # The CA private key
new_certs_dir = $base_dir              # Location for new certs after signing
database      = $base_dir/index.txt    # Database index file
serial        = $base_dir/serial.txt   # The current serial number

default_days     = 1000         # How long to certify for
default_crl_days = 30           # How long before next CRL
default_md       = sha256       # Use public key default MD
preserve         = no           # Keep passed DN ordering

x509_extensions = ca_extensions # The extensions to add to the cert

email_in_dn     = no            # Don't concat the email in the DN
copy_extensions = copy          # Required to copy SANs from CSR to cert

####################################################################
[ req ]
default_bits       = 4096
default_keyfile    = cakey.pem
distinguished_name = ca_distinguished_name
x509_extensions    = ca_extensions
string_mask        = utf8only

####################################################################
[ ca_distinguished_name ]
countryName         = Country Name (2 letter code)
countryName_default = DE

stateOrProvinceName         = State or Province Name (full name)
stateOrProvinceName_default = Test Province

localityName                = Locality Name (eg, city)
localityName_default        = Test Town

organizationName            = Organization Name (eg, company)
organizationName_default    = Test Company

organizationalUnitName         = Organizational Unit (eg, division)
organizationalUnitName_default = Test Unit

commonName         = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Test Name

emailAddress         = Email Address
emailAddress_default = test@test.com

####################################################################
[ ca_extensions ]

subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always, issuer
basicConstraints       = critical, CA:true
keyUsage               = keyCertSign, cRLSign

####################################################################
[ signing_policy ]
countryName            = optional
stateOrProvinceName    = optional
localityName           = optional
organizationName       = optional
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

####################################################################
[ signing_req ]
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints       = CA:FALSE
keyUsage               = digitalSignature, keyEncipherment

 

然後建立一個資料庫和序列號檔案，這些將用於跟蹤哪些證照是與這個CA簽署的。這兩個檔案都是簡單的文字檔案，與你的CA金鑰駐留在同一個目錄下

                echo 01 > serial.txt
                touch index.txt

完成這些步驟後，你現在就可以生成你的CA了，它將被用來簽署證照。

                keytool -keystore client.truststore.jks -alias CARoot -import -file ca-cert

 

注意：如果你在Kafka brokers配置中通過將ssl.client.auth設定為 "requested "或 "required "來配置Kafka brokers需要客戶端認證，那麼你必須為Kafka brokers也提供一個truststore，它應該有客戶端的金鑰所簽署的所有CA證照。

                keytool -keystore server.truststore.jks -alias CARoot -import -file ca-cert

 

與步驟1中儲存每臺機器自身身份的keystore不同，客戶端的truststore儲存了客戶端應該信任的所有證照。將一個證照匯入到自己的truststore中，也意味著信任所有由該證照籤署的證照。就像上面的比喻，信任政府（CA）也意味著信任它頒發的所有護照（證照）。這個屬性被稱為信任鏈，當在大型Kafka叢集上部署SSL時，它特別有用。你可以用一個CA來簽署叢集中的所有證照，並讓所有機器共享同一個信任CA的truststore。這樣所有的機器都可以對所有其他機器進行認證。

簽署證照

然後在CA上簽字：

                openssl ca -config openssl-ca.cnf -policy signing_policy -extensions signing_req -out {server certificate} -infiles {certificate signing request}

 

最後，你需要將CA的證照和簽名的證照都匯入到金鑰儲存中。

                keytool -keystore {keystore} -alias CARoot -import -file {CA certificate}
                keytool -keystore {keystore} -alias localhost -import -file cert-signed

 

引數的定義如下。

1. keystore：鑰匙店的位置
2. CA證照：CA的證照
3. 證照籤署請求：用伺服器金鑰建立的csr。
4. 伺服器證照：將伺服器的簽名證照寫入的檔案。

這將給你留下一個名為truststore.jks的truststore檔案--這個檔案可以對所有的客戶和broker都是一樣的，不包含任何敏感資訊，所以沒有必要保護這個檔案。
此外，每個節點將有一個server.keystore.jks檔案，其中包含該節點的金鑰、證照和你的CAs證照，關於如何使用這些檔案，請參考配置Kafkabroker和配置Kafka客戶端。
關於這個主題的一些工具幫助，請檢視easyRSA專案，它有大量的指令碼來幫助完成這些步驟。

PEM格式的SSL金鑰和證照

從2.7.0開始，可以直接在配置中以PEM格式為Kafkabroker和客戶端配置SSL金鑰和信任儲存。這避免了在檔案系統上儲存單獨的檔案，並受益於Kafka配置的密碼保護功能。除了JKS和PKCS12之外，PEM也可以作為基於檔案的金鑰和信任儲存的儲存型別。如果要在broker或客戶端配置中直接配置PEM金鑰儲存，應在ssl.keystore.key中提供PEM格式的私鑰，在ssl.keystore.certificate.chain中提供PEM格式的證照鏈。配置信任儲存時，應在ssl.truststore.certificates中提供信任證照，如CA的公開證照。由於PEM通常儲存為多行基數64的字串，配置值可以在Kafka配置中以多行字串的形式包含，並以反斜槓('/')作為行的延續。
儲存密碼配置ssl.keystore.password和ssl.truststore.password不用於PEM。如果私鑰使用密碼加密，必須在ssl.key.password中提供金鑰密碼。當直接在config值中指定PEM時，可以不使用密碼以未加密的形式提供私鑰。在生產部署中，這種情況下應該使用Kafka中的密碼保護功能對config進行加密或外部化。需要注意的是，當使用OpenSSL等外部工具進行加密時，預設的SSL引擎工廠對加密私鑰的解密能力有限。第三方庫如BouncyCastle可能會被整合到自定義的SSL引擎工廠中，以支援更廣泛的加密私鑰。

 

生產中的常見陷阱

上面的段落展示了建立你自己的CA，並使用它為你的叢集簽署證照的過程。雖然對於沙盒、開發、測試和類似的系統非常有用，但這通常不是為企業環境中的生產叢集建立證照的正確過程。企業通常會運營自己的CA，使用者可以傳送CSR到這個CA上進行簽名，這樣做的好處是使用者不用負責保證CA的安全，同時也是大家可以信任的中央權威機構。然而這也剝奪了使用者對證照籤署過程的很多控制權。不少時候，操作企業CA的人員會對證照進行嚴格的限制，當試圖將這些證照與Kafka一起使用時，就會出現問題。

1. 擴充套件金鑰使用
   • 證照可能包含一個擴充套件欄位，用於控制證照的使用目的，如果該欄位為空，則對使用沒有限制，但如果在這裡指定了任何用途，有效的SSL實現必須強制執行這些用途。如果該欄位為空，則對使用沒有限制，但如果在這裡指定了任何用途，有效的SSL實現必須執行這些用途。
   • Kafka的相關用途有
     • 客戶端認證
     • 伺服器認證
   • Kafkabroker需要這兩種用法都被允許，因為對於叢集內的通訊，每個broker對其他broker都會表現為既是客戶端又是伺服器。企業CA有一個webservers的簽名配置檔案，並將其也用於Kafka，這並不罕見，它將只包含serverAuth用法值，並導致SSL握手失敗。
2. 中級證照
   • 出於安全原因，公司的根證照經常處於離線狀態。為了保證日常的使用，建立了所謂的中間CA，然後用來簽署最終的證照。當把一個由中間CA簽署的證照匯入到金鑰儲存中時，有必要提供整個信任鏈到根CA。這可以通過簡單地將證照檔案編碼為一個合併的證照檔案，然後用keytool匯入來完成。
3. 複製擴充套件欄位失敗

• • 核證機運營商往往不願意從企業社會責任書中複製和要求的擴充套件欄位，而更願意自己指定這些欄位，因為這使惡意方更難獲得具有潛在誤導性或欺詐性價值的證照。建議仔細檢查已簽署的證照，是否包含所有要求的SAN欄位，以便進行正確的主機名驗證。下面的命令可以用來列印證照細節到控制檯，並與最初的要求進行比較。

                        openssl x509 -in certificate.crt -text -noout

 

配置Kafka brokers

Kafka Brokers支援監聽多個埠上的連線。我們需要在server.properties中配置以下屬性，該屬性必須有一個或多個逗號分隔的值：

listeners

 

如果沒有為broker之間的通訊啟用SSL（見下文如何啟用），則需要同時啟用PLAINTEXT和SSL埠。

            listeners=PLAINTEXT://host.name:port,SSL://host.name:port

 

broker端需要以下SSL配置。

            ssl.keystore.location=/var/private/ssl/server.keystore.jks
            ssl.keystore.password=test1234
            ssl.key.password=test1234
            ssl.truststore.location=/var/private/ssl/server.truststore.jks
            ssl.truststore.password=test1234

 

注意：ssl.truststore.password在技術上是可選的，但強烈建議使用。如果沒有設定密碼，對truststore的訪問仍然可用，但完整性檢查被禁用。值得考慮的可選設定。

1. ssl.client.auth=none ("required" => 客戶端認證是必須的， "requested" => 客戶端認證是必須的，沒有證照的客戶端仍然可以連線。不鼓勵使用 "requested"，因為它提供了一種虛假的安全感，配置錯誤的客戶端仍然可以成功連線。)
2. ssl.cipher.suites (可選)。密碼套件是一個命名的認證、加密、MAC和金鑰交換演算法的組合，用於使用TLS或SSL網路協議協商網路連線的安全設定。(預設為空列表)
3. ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1 (列出你要從客戶端接受的SSL協議。請注意，SSL已經被TLS取代，不建議在生產中使用SSL。)
4. ssl.keystore.type=JKS
5. ssl.truststore.type=JKS
6. ssl.secure.random.implement=SHA1PRNG。

如果你想為broker之間的通訊啟用SSL，請在server.properties檔案中新增以下內容（預設為PLAINTEXT）。

            security.inter.broker.protocol=SSL

 

由於某些國家的進口法規，Oracle的實施限制了預設情況下可用的加密演算法的強度。如果需要更強的演算法（例如，256位金鑰的AES），則必須獲得JCE無限強度Jurisdiction策略檔案並安裝在JDK/JRE中。更多資訊請參見JCA供應商文件。

JRE/JDK會有一個預設的偽隨機數生成器（PRNG），用於加密操作，因此不需要配置與ssl.secure.random.實現一起使用的實現。但是，有些實現存在效能問題（特別是Linux系統上選擇的預設的NativePRNG，利用了全域性鎖）。在SSL連線的效能成為問題的情況下，可以考慮明確設定要使用的實現。SHA1PRNG實現是非阻塞的，並且在重負載下表現出了非常好的效能特性（每個broker每秒產生50 MB的訊息，加上覆制流量）。

一旦你啟動了broker，你應該能夠在server.log中看到以下資訊

            with addresses: PLAINTEXT -> EndPoint(192.168.64.1,9092,PLAINTEXT),SSL -> EndPoint(192.168.64.1,9093,SSL)

 

要快速檢查伺服器keystore和truststore是否設定正確，你可以執行以下命令

openssl s_client -debug -connect localhost:9093 -tls1

 

(注意：TLSv1應該列在ssl.enabled.protocols下)
在這個命令的輸出中，你應該看到伺服器的證照。

            -----BEGIN CERTIFICATE-----
            {variable sized random bytes}
            -----END CERTIFICATE-----
            subject=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=Sriharsha Chintalapani
            issuer=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=kafka/emailAddress=test@test.com

如果證照沒有顯示出來，或者有任何其他錯誤資訊，那麼你的keystore沒有正確設定。

配置Kafka客戶端

SSL只支援新的Kafka生產者和消費者，不支援舊的API。對於生產者和消費者來說，SSL的配置將是相同的。
如果在broker中不需要客戶端認證，那麼下面是一個最小的配置示例。

            security.protocol=SSL
            ssl.truststore.location=/var/private/ssl/client.truststore.jks
            ssl.truststore.password=test1234

注意：ssl.truststore.password在技術上是可選的，但強烈建議使用。如果沒有設定密碼，對truststore的訪問仍然是可用的，但完整性檢查被禁用。如果需要客戶端認證，那麼必須像步驟1那樣建立一個keystore，並且還必須配置以下內容。

            ssl.keystore.location=/var/private/ssl/client.keystore.jks
            ssl.keystore.password=test1234
            ssl.key.password=test1234

根據我們的要求和broker配置，可能還需要其他配置設定。

1. ssl.provider (可選)。用於 SSL 連線的安全提供商的名稱。預設值是JVM的預設安全提供商。
2. ssl.cipher.suites（可選）。密碼套件是一個命名的認證、加密、MAC和金鑰交換演算法的組合，用於使用TLS或SSL網路協議協商網路連線的安全設定。
3. ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1.它應該列出至少一個在broker端配置的協議。
4. ssl.truststore.type=JKS
5. ssl.keystore.type=JKS

使用控制檯-生產者和控制檯-消費者的例子：

            kafka-console-producer.sh --bootstrap-server localhost:9093 --topic test --producer.config client-ssl.properties
            kafka-console-consumer.sh --bootstrap-server localhost:9093 --topic test --consumer.config client-ssl.properties

7.3 使用SASL進行認證

（1）JAAS配置

Kafka使用Java認證和授權服務（JAAS）進行SASL配置。

 

Kafkabroker的JAAS配置

KafkaServer是JAAS檔案中每個KafkaServer/Broker使用的部分名稱。該部分為broker提供了SASL配置選項，包括broker為broker間通訊所做的任何SASL客戶端連線。如果多個監聽器被配置為使用SASL，則該部分名稱可以以監聽器名稱為字首，用小寫字母，後面加句號，例如：sasl_ssl.KafkaServer。

客戶端部分用於驗證與zookeeper的SASL連線。它還允許broker在zookeeper節點上設定SASL ACL，將這些節點鎖定，只有broker可以修改它。所有的broker必須有相同的主名。如果你想使用Client以外的部分名稱，請將系統屬性zookeeper.sasl.clientconfig設定為適當的名稱（例如，-Dzookeeper.sasl.clientconfig=ZkClient）。

ZooKeeper預設使用 "zookeeper "作為服務名。如果你想改變這一點，請將系統屬性zookeeper.sasl.client.username設定為適當的名稱（例如，-Dzookeeper.sasl.client.username=zk）。

broker也可以使用broker配置屬性sasl.jaas.config來配置JAAS。屬性名必須以監聽器為字首，包括SASL機制，即listener.name.{listenerName}.{saslMechanism}.sasl.jaas.config。config值中只能指定一個登入模組。如果在一個監聽器上配置了多個機制，必須使用監聽器和機制字首為每個機制提供配置。例如

        listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
            username="admin" \
            password="admin-secret";
        listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
            username="admin" \
            password="admin-secret" \
            user_admin="admin-secret" \
            user_alice="alice-secret";

如果JAAS配置定義在不同的級別，使用的優先順序是：

1. broker配置屬性listener.name.{listenerName}.{saslMechanism}.sasl.jaas.config。
2. 靜態JAAS配置的{listenerName}.KafkaServer部分。
3. 靜態JAAS配置的KafkaServer部分

注意，ZooKeeper JAAS配置只能使用靜態JAAS配置。
請參閱GSSAPI（Kerberos），PLAIN，SCRAM或OAUTHBEARER的broker配置的例子。

Kafka客戶端的JAAS配置

 

客戶端可以使用客戶端配置屬性sasl.jaas.config或使用類似於brokers的靜態JAAS配置檔案來配置JAAS。

 

使用客戶端配置屬性進行JAAS配置

客戶端可以將JAAS配置指定為生產者或消費者屬性，而無需建立物理配置檔案。這種模式還可以使同一JVM中的不同生產者和消費者通過為每個客戶端指定不同的屬性來使用不同的憑證。如果同時指定了靜態 JAAS 配置系統屬性 java.security.auth.login.config 和客戶端屬性 sasl.jaas.config，則將使用客戶端屬性。

請參閱GSSAPI（Kerberos）、PLAIN、SCRAM或OAUTHBEARER的配置示例。

 

使用靜態配置檔案進行JAAS配置

使用靜態JAAS配置檔案在客戶端配置SASL認證。

1. 新增一個JAAS配置檔案，其中有一個名為KafkaClient的客戶端登入部分。在KafkaClient中為所選機制配置登入模組，如設定GSSAPI（Kerberos）、PLAIN、SCRAM或OAUTHBEARER的示例中所述。例如，GSSAPI憑證可以配置為：

   •         KafkaClient {
             com.sun.security.auth.module.Krb5LoginModule required
             useKeyTab=true
             storeKey=true
             keyTab="/etc/security/keytabs/kafka_client.keytab"
             principal="kafka-client-1@EXAMPLE.COM";
         };

2. 將JAAS配置檔案的位置作為JVM引數傳遞給每個客戶端JVM。例如：

    -Djava.security.auth.login.config=/etc/kafka/kafka_client_jaas.conf

---------------------------------------

（2）SASL配置

SASL可與PLAINTEXT或SSL一起使用，分別使用安全協議SASL_PLAINTEXT或SASL_SSL作為傳輸層。如果使用SASL_SSL，那麼也必須配置SSL。

 

1.SASL機制

Kafka支援以下SASL機制。　

• GSSAPI (Kerberos)
• PLAIN
• SCRAM-SHA-256
• SCRAM-SHA-512
• OAUTHBEARER

　　2.Kafkabroker的SASL配置

　　　　1.在server.properties中配置一個SASL埠，在listeners引數中加入至少一個SASL_PLAINTEXT或SASL_SSL，其中包含一個或多個逗號分隔的值。

　　　　    listeners=SASL_PLAINTEXT://host.name:port　　　　

　　　　如果你只配置一個SASL埠（或者你想讓Kafkabroker使用SASL相互認證），那麼請確保你為broker之間的通訊設定相同的SASL協議。

　　　　2.選擇一個或多個受支援的機制在broker中啟用，並按照步驟為該機制配置SASL。要在broker中啟用多個機制，請按照這裡的步驟進行操作。

　　3.Kafka客戶端的SASL配置

　　　　

SASL 身份驗證只支援新的 Java Kafka 生產者和消費者，不支援舊的 API。

要在客戶端上配置SASL身份驗證，請選擇一個在broker中啟用的SASL機制進行客戶端身份驗證，並按照步驟為所選機制配置SASL。

 

---------------------------------------

 （3）使用SASL/Kerberos進行認證

1）先決條件

1.Kerberos
如果您的組織已經使用了 Kerberos 伺服器 (例如，通過使用 Active Directory)，就不需要為 Kafka 安裝一個新的伺服器。否則，您需要安裝一個，您的 Linux 供應商可能有 Kerberos 的軟體包和關於如何安裝和配置它的簡短指南 (Ubuntu、Redhat)。注意， 如果您使用的是 Oracle Java， 則需要下載 Java 版本的 JCE 策略檔案， 並將其複製到 $JAVA_HOME/jre/lib/security 中。

2.建立 Kerberos 標準
如果您正在使用組織的 Kerberos 或 Active Directory 伺服器，請向 Kerberos 管理員詢問叢集中每個 Kafka broker和每個通過 Kerberos 身份驗證訪問 Kafka 的作業系統使用者（通過客戶端和工具）的 principal。
如果您已經安裝了自己的 Kerberos，則需要使用以下命令來建立這些 principal。

        sudo /usr/sbin/kadmin.local -q 'addprinc -randkey kafka/{hostname}@{REALM}'
        sudo /usr/sbin/kadmin.local -q "ktadd -k /etc/security/keytabs/{keytabname}.keytab kafka/{hostname}@{REALM}"

3.確保所有的主機都可以使用主機名進行訪問

 Kerberos 要求所有的主機都可以使用 FQDNs 進行解析。

2）配置Kafkabroker

1.在每個Kafka broker的config目錄下新增一個經過適當修改的類似於下面的JAAS檔案，在這個例子中，我們稱它為kafka_server_jaas.conf（注意，每個broker應該有自己的keytab）。

        KafkaServer {
            com.sun.security.auth.module.Krb5LoginModule required
            useKeyTab=true
            storeKey=true
            keyTab="/etc/security/keytabs/kafka_server.keytab"
            principal="kafka/kafka1.hostname.com@EXAMPLE.COM";
        };

        // Zookeeper client authentication
        Client {
        com.sun.security.auth.module.Krb5LoginModule required
        useKeyTab=true
        storeKey=true
        keyTab="/etc/security/keytabs/kafka_server.keytab"
        principal="kafka/kafka1.hostname.com@EXAMPLE.COM";
        };

JAAS檔案中的KafkaServer部分告訴broker要使用哪個principal，以及存放這個principal的keytab的位置。它允許broker使用本節中指定的keytab登入。關於Zookeeper SASL配置的更多細節，請參見注釋。

2.將 JAAS 和可選的 krb5 檔案位置作為 JVM 引數傳遞給每個 Kafka broker（詳見這裡）。

1.     -Djava.security.krb5.conf=/etc/kafka/krb5.conf
           -Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf

 

3.確保在JAAS檔案中配置的keytabs可以被啟動kafka broker的作業系統使用者讀取。
4.在server.properties中配置SASL埠和SASL機制，如這裡所述。例如：

    listeners=SASL_PLAINTEXT://host.name:port
        security.inter.broker.protocol=SASL_PLAINTEXT
        sasl.mechanism.inter.broker.protocol=GSSAPI
        sasl.enabled.mechanisms=GSSAPI

我們還必須在server.properties中配置服務名，服務名應該與kafka brokers的principal名一致。在上面的例子中，principal是 "kafka/kafka1.hostname.com@EXAMPLE.com"，所以。

    sasl.kerberos.service.name=kafka

3）配置kafka客戶端

要在客戶端配置SASL認證：

（1）客戶端（生產者、消費者、連線工作者等）將用自己的委託人（通常與執行客戶端的使用者同名）對叢集進行身份驗證，因此根據需要獲取或建立這些委託人。然後為每個客戶端配置JAAS配置屬性。在一個JVM中，不同的客戶端可以通過指定不同的principals來作為不同的使用者執行。producer.properties或consumer.properties中的屬性sasl.jaas.config描述了生產者和消費者等客戶端如何連線到Kafka Broker。下面是一個使用keytab的客戶端的配置示例（推薦用於長期執行的程式）。

    sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
        useKeyTab=true \
        storeKey=true  \
        keyTab="/etc/security/keytabs/kafka_client.keytab" \
        principal="kafka-client-1@EXAMPLE.COM";

對於kafka-console-consumer或kafka-console-producer這樣的命令列實用程式，kinit可以和 "useTicketCache=true "一起使用，如：

    sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
        useTicketCache=true;

客戶端的JAAS配置也可以指定為JVM引數，類似於這裡描述的broker。客戶端使用名為KafkaClient的登入部分。這個選項只允許一個使用者從JVM的所有客戶端連線。

（2）確保在JAAS配置中配置的keytabs可以被啟動kafka客戶端的作業系統使用者讀取。

（3）可以選擇將krb5檔案的位置作為JVM引數傳遞給每個客戶端JVM（更多細節見這裡）。

 

    -Djava.security.krb5.conf=/etc/kafka/krb5.conf

 

（4）在 producer.properties 或 consumer.properties 中配置以下屬性。

    security.protocol=SASL_PLAINTEXT (or SASL_SSL)
    sasl.mechanism=GSSAPI
    sasl.kerberos.service.name=kafka

　------------------------------------　

 （4）使用SASL/PLAIN進行認證

SASL/PLAIN是一種簡單的使用者名稱/密碼認證機制，通常與TLS一起用於加密以實現安全認證。Kafka支援SASL/PLAIN的預設實現，可以按照這裡的描述對其進行擴充套件以用於生產。

使用者名稱作為認證的Principal，用於配置ACL等。

 

1）配置Kafkabroker
（1）在每個Kafka broker的config目錄下新增一個適當修改的類似於下面的JAAS檔案，在本例中我們稱之為kafka_server_jaas.conf。

        KafkaServer {
            org.apache.kafka.common.security.plain.PlainLoginModule required
            username="admin"
            password="admin-secret"
            user_admin="admin-secret"
            user_alice="alice-secret";
        };

這個配置定義了兩個使用者（admin和alice）。KafkaServer部分的屬性使用者名稱和密碼被broker用來發起與其他broker的連線。在本例中，admin是用於broker之間通訊的使用者。屬性集user_userName定義了所有連線到broker的使用者的密碼，broker使用這些屬性驗證所有客戶端連線，包括來自其他broker的連線。

（2）將JAAS配置檔案位置作為JVM引數傳遞給每個Kafka broker。

 

    -Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf

 

（3）在server.properties中配置SASL埠和SASL機制，如這裡所述。例如：

    listeners=SASL_SSL://host.name:port
        security.inter.broker.protocol=SASL_SSL
        sasl.mechanism.inter.broker.protocol=PLAIN
        sasl.enabled.mechanisms=PLAIN

2）配置Kafka客戶端
要在客戶端配置SASL認證。
（1）在producer.properties或consumer.properties中為每個客戶端配置JAAS配置屬性。登入模組描述了生產者和消費者等客戶端如何連線到Kafka Broker。下面是一個PLAIN機制的客戶端的配置示例。

    sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
        username="alice" \
        password="alice-secret";

username和password這兩個選項被客戶端用來配置客戶端連線的使用者。在這個例子中，客戶端以使用者alice的身份連線到broker。在一個JVM中，不同的客戶端可以通過在sasl.jaas.config中指定不同的使用者名稱和密碼作為不同的使用者進行連線。

客戶端的JAAS配置也可以像這裡描述的那樣，作為類似於broker的JVM引數來指定。客戶端使用名為KafkaClient的登入部分。這個選項只允許一個使用者從JVM的所有客戶端連線。

 

（2）在 producer.properties 或 consumer.properties 中配置以下屬性。

    security.protocol=SASL_SSL
    sasl.mechanism=PLAIN

（3）在生產中使用SASL/PLAIN

• SASL/PLAIN應該只在SSL作為傳輸層的情況下使用，以確保明確的密碼在沒有加密的情況下不會在有線上傳輸。
• Kafka中SASL/PLAIN的預設實現在JAAS配置檔案中指定使用者名稱和密碼，如圖所示。從Kafka 2.0版本開始，你可以通過配置選項sasl.server.callback.handler.class和sasl.client.callback.handler.class配置自己的回撥處理程式，從外部獲取使用者名稱和密碼，從而避免在磁碟上儲存清晰的密碼。
• 在生產系統中，外部認證伺服器可以實現密碼認證。從Kafka 2.0版本開始，你可以通過配置sasl.server.callback.handler.class，插入自己的回撥處理程式，使用外部認證伺服器進行密碼驗證。

-------------------------------------

（ 5）使用SASL/SCRAM進行認證

鹽化挑戰響應認證機制（SCRAM）是一個SASL機制系列，它解決了傳統機制（如PLAIN和DIGEST-MD5）執行使用者名稱/密碼認證的安全問題。該機制定義在RFC 5802中。Kafka支援SCRAM-SHA-256和SCRAM-SHA-512，它們可以和TLS一起執行安全認證。使用者名稱作為認證的Principal，用於配置ACL等。Kafka中預設的SCRAM實現將SCRAM憑證儲存在Zookeeper中，適用於Zookeeper在私有網路上的Kafka安裝。更多細節請參考安全注意事項。

 

1）建立SCRAM證照
Kafka中的SCRAM實現使用Zookeeper作為憑證儲存。可以使用kafka-configs.sh在Zookeeper中建立憑證。對於每個已啟用的SCRAM機制，必須通過新增一個帶有機制名稱的配置來建立憑證。在Kafkabroker啟動之前，必須建立broker間通訊的憑證。客戶端憑證可以動態建立和更新，更新後的憑證將用於驗證新連線。

為使用者alice建立SCRAM憑證，密碼為alice-secret。

    > bin/kafka-configs.sh --zookeeper localhost:2182 --zk-tls-config-file zk_tls_config.properties --alter --add-config 'SCRAM-SHA-256=[iterations=8192,password=alice-secret],SCRAM-SHA-512=[password=alice-secret]' --entity-type users --entity-name alice

 

如果沒有指定迭代次數，則使用預設的4096迭代次數。隨機建立一個salt，並在Zookeeper中儲存由salt、iterations、StoredKey和ServerKey組成的SCRAM標識。關於SCRAM標識和各個欄位的細節，請參見RFC 5802。

下面的例子還需要一個使用者管理員來進行broker之間的通訊，可以使用建立。

    > bin/kafka-configs.sh --zookeeper localhost:2182 --zk-tls-config-file zk_tls_config.properties --alter --add-config 'SCRAM-SHA-256=[password=admin-secret],SCRAM-SHA-512=[password=admin-secret]' --entity-type users --entity-name admin

 

可以使用--describe選項列出現有的憑證。

    > bin/kafka-configs.sh --zookeeper localhost:2182 --zk-tls-config-file zk_tls_config.properties --describe --entity-type users --entity-name alice

 

使用--alter--delete-config選項可以刪除一個或多個SCRAM機制的證照。

 

    > bin/kafka-configs.sh --zookeeper localhost:2182 --zk-tls-config-file zk_tls_config.properties --alter --delete-config 'SCRAM-SHA-512' --entity-type users --entity-name alice

 

 

2）配置Kafkabroker
（1）在每個Kafka broker的config目錄下新增一個適當修改的類似於下面的JAAS檔案，在本例中我們稱之為kafka_server_jaas.conf。

    KafkaServer {
        org.apache.kafka.common.security.scram.ScramLoginModule required
        username="admin"
        password="admin-secret";
    };

 

KafkaServer部分的屬性使用者名稱和密碼被broker用來發起與其他broker的連線。在本例中，admin是broker之間通訊的使用者。

（2）將JAAS配置檔案位置作為JVM引數傳遞給每個Kafka broker。

 

    -Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf

 

 

（3）在server.properties中配置SASL埠和SASL機制，如這裡所述。例如：

   listeners=SASL_SSL://host.name:port
    security.inter.broker.protocol=SASL_SSL
    sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256 (or SCRAM-SHA-512)
    sasl.enabled.mechanisms=SCRAM-SHA-256 (or SCRAM-SHA-512)

3）配置Kafka客戶端
要在客戶端配置SASL認證。
（1）在producer.properties或consumer.properties中為每個客戶端配置JAAS配置屬性。登入模組描述了生產者和消費者等客戶端如何連線到Kafka Broker。下面是一個SCRAM機制的客戶端的配置示例。

   sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
        username="alice" \
        password="alice-secret";

username和password這兩個選項被客戶端用來配置客戶端連線的使用者。在這個例子中，客戶端以使用者alice的身份連線到broker。在一個JVM中，不同的客戶端可以通過在sasl.jaas.config中指定不同的使用者名稱和密碼作為不同的使用者進行連線。

客戶端的JAAS配置也可以像這裡描述的那樣，作為類似於broker的JVM引數來指定。客戶端使用名為KafkaClient的登入部分。這個選項只允許一個使用者從JVM的所有客戶端連線。

 

（2）在 producer.properties 或 consumer.properties 中配置以下屬性。

    security.protocol=SASL_SSL
    sasl.mechanism=SCRAM-SHA-256 (or SCRAM-SHA-512)

 

4）SASL/SCRAM的安全注意事項

• Kafka中預設的SASL/SCRAM實現在Zookeeper中儲存SCRAM證照。這適用於在Zookeeper安全的私有網路中的生產使用。
• Kafka只支援強雜湊函式SHA-256和SHA-512，最小迭代次數為4096。強雜湊函式與強密碼和高迭代次數相結合，可以在Zookeeper安全受到威脅時防止蠻力攻擊。
• SCRAM應該只與TLS加密一起使用，以防止SCRAM交換被攔截。這可以防止字典或蠻力攻擊，並在Zookeeper受到損害時防止冒名頂替。
• 從Kafka 2.0版本開始，在Zookeeper不安全的安裝中，可以通過配置sasl.server.callback.handler.class，使用自定義回撥處理程式覆蓋預設的SASL/SCRAM憑證儲存。
• 關於安全考慮的更多細節，請參考RFC 5802。
  
  

-----------------------------------

（6）使用SASL/OAUTHBEARER進行認證

OAuth 2授權框架 "使第三方應用程式能夠代表資源所有者獲得對HTTP服務的有限訪問，通過協調資源所有者和HTTP服務之間的審批互動，或允許第三方應用程式代表自己獲得訪問"。SASL OAUTHBEARER機制能夠在SASL（即非HTTP）上下文中使用該框架；它在RFC 7628中進行了定義。Kafka中預設的OAUTHBEARER實現建立和驗證Unsecured JSON Web Tokens，只適合在非生產型Kafka安裝中使用。更多細節請參考安全注意事項。

1）配置Kafkabroker
（1）在每個Kafka broker的config目錄下新增一個適當修改的類似於下面的JAAS檔案，在本例中我們稱之為kafka_server_jaas.conf

    KafkaServer {
        org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required
        unsecuredLoginStringClaim_sub="admin";
    };

KafkaServer部分中的屬性unsecuredLoginStringClaim_sub被broker在發起與其他broker的連線時使用。在這個例子中，admin將出現在主題（sub）索賠中，並將成為broker之間通訊的使用者。

（2）將JAAS配置檔案位置作為JVM引數傳遞給每個Kafka broker。

 

    -Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf

 

 

（3）在server.properties中配置SASL埠和SASL機制，如這裡所述。例如，在server.properties中配置SASL埠和SASL機制。

    listeners=SASL_SSL://host.name:port (or SASL_PLAINTEXT if non-production)
    security.inter.broker.protocol=SASL_SSL (or SASL_PLAINTEXT if non-production)
    sasl.mechanism.inter.broker.protocol=OAUTHBEARER
    sasl.enabled.mechanisms=OAUTHBEARER

2）配置Kafka客戶端
要在客戶端配置SASL認證
（1）在producer.properties或consumer.properties中為每個客戶端配置JAAS配置屬性。登入模組描述了生產者和消費者等客戶端如何連線到Kafka Broker。下面是一個客戶端對OAUTHBEARER機制的配置示例。

   sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
        unsecuredLoginStringClaim_sub="alice";

選項unsecuredLoginStringClaim_sub被客戶端用來配置主題（sub）索賠，它決定了客戶端連線的使用者。在這個例子中，客戶端以使用者alice的身份連線到broker。在一個JVM中，不同的客戶端可以通過在sasl.jaas.config中指定不同的主題（子）宣告作為不同的使用者進行連線。

客戶端的JAAS配置也可以像這裡描述的那樣，作為類似於broker的JVM引數來指定。客戶端使用名為KafkaClient的登入部分。這個選項只允許一個使用者從JVM的所有客戶端連線。

 

（2）在 producer.properties 或 consumer.properties 中配置以下屬性

    security.protocol=SASL_SSL (or SASL_PLAINTEXT if non-production)
    sasl.mechanism=OAUTHBEARER

（3）SASL/OAUTHBEARER的預設實現依賴於jackson-databind庫。由於它是一個可選的依賴項，使用者必須通過他們的構建工具將其配置為一個依賴項。

 

3）為SASL/OAUTHBEARER建立無擔保的令牌選項

Kafka中SASL/OAUTHBEARER的預設實現可以建立和驗證Unsecured JSON Web Tokens。雖然只適合非生產性使用，但它確實提供了在DEV或TEST環境中建立任意令牌的靈活性。
下面是客戶端支援的各種JAAS模組選項（如果OAUTHBEARER是broker間協議，則在broker端也支援）

 

用於無擔保令牌建立的JAAS模組選項	文件
unsecuredLoginStringClaim_<claimname>="value"	用給定的名稱和值建立一個字串索賠。除了 "iat "和 "exp "之外，可以指定任何有效的索賠名稱（這些名稱是自動生成的）。
unsecuredLoginNumberClaim_<claimname>="value"	用給定的名稱和值建立一個Number索賠。除了 "iat "和 "exp "之外，可以指定任何有效的索賠名稱（這些名稱是自動生成的）。
unsecuredLoginListClaim_<claimname>="value"	用給定的名稱和從給定的值中解析出的值建立一個字串列表請求，其中第一個字元作為定界符。例如：unsecuredLoginListClaim_fubar="|value1|value2"。除了'iat'和'exp'之外，可以指定任何有效的索賠名稱（這些名稱是自動生成的）。
unsecuredLoginExtension_<extensionname>="value"	用給定的名稱和值建立一個字串擴充套件。例如：unsecuredLoginExtension_traceId="123"。有效的副檔名是小寫或大寫字母的任意序列。此外，"auth "副檔名是保留的。有效的擴充套件值是ASCII碼1-127的任意字元組合。
unsecuredLoginPrincipalClaimName	如果您希望持有主名的字串權利要求的名稱不是 "sub"，則設定為自定義權利要求名稱。
unsecuredLoginLifetimeSeconds	如果令牌過期時間要設定為預設值3600秒（即1小時）以外的其他值，則設定為一個整數值。exp "要求將被設定為反映過期時間。
unsecuredLoginScopeClaimName	如果您希望持有任何標記作用域的字串或字串列表權利要求的名稱是 "作用域 "以外的其他名稱，則設定為自定義權利要求名稱。

 

4）SASL/OAUTHBEARER的不安全令牌驗證選項

以下是broker端支援的各種JAAS模組選項，用於不安全的JSON Web Token驗證

用於非安全令牌驗證的JAAS模組選項	文件
unsecuredValidatorPrincipalClaimName="value"	如果您希望檢查持有主名稱的特定字串權利要求是否存在，則設定為非空值；預設為檢查 "子 "權利要求是否存在。
unsecuredValidatorScopeClaimName="value"	如果您希望持有任何標記作用域的字串或字串列表權利要求的名稱是 "作用域 "以外的其他名稱，則設定為自定義權利要求名稱。
unsecuredValidatorRequiredScope="value"	如果您希望檢查持有標記作用域的String/String List權利要求，以確保它包含某些值，則設定為以空格限定的作用域值列表。
unsecuredValidatorAllowableClockSkewMs="value"	如果您希望允許時鐘偏移的正毫秒數，則設定為正整數（預設為0）。

預設的不安全的SASL/OAUTHBEARER實現可以使用自定義登入和SASL伺服器回撥處理程式來覆蓋（在生產環境中必須覆蓋）。

有關安全考慮的更多細節，請參考RFC 6749第10節。

 

5）為SASL/OAUTHBEARER重新整理令牌

 

Kafka會在任何令牌過期前定期重新整理，以便客戶端可以繼續與broker進行連線。影響重新整理演算法操作方式的引數被指定為生產者/消費者/broker配置的一部分，如下所示。詳情請參見其他地方的這些屬性的文件。預設值通常是合理的，在這種情況下，這些配置引數就不需要明確設定了。

生產者/消費者/broker配置屬性

• sasl.login.refresh.window.factor
• sasl.login.refresh.window.jitter
• sasl.login.refresh.min.period.seconds
• sasl.login.refresh.min.buffer.seconds

 

6）SASL/OAUTHBEARER的安全/生產使用

 

生產用例需要編寫一個org.apache.kafka.common.security.auth.AuthenticateCallbackHandler的實現，它可以處理org.apache.kafka.common.security.oauthbearer.OAuthBearerTokenCallback的例項，並通過sasl.login.callback.handler.class配置選項為非broker客戶端宣告它，或者通過listener.name.sasl_ssl.oauthbearer.sasl.login.callback.handler.class配置選項宣告它。 login.callback.handler.class配置選項來宣告它，或者通過listener.name.sasl_ssl.oauthbearer.sasl.login.callback.handler.class配置選項來宣告它（當SASL/OAUTHBEARER是broker之間的協議時）。

生產用例還需要編寫一個org.apache.kafka.common.security.auth.AuthenticateCallbackHandler的實現，它可以處理org.apache.kafka.common.security.oauthbearer.OAuthBearerValidatorCallback的例項，並通過listener.name.sasl_ssl.oauthbearer.sasl.server.callback.handler.classbroker配置選項來宣告它。

 

 

7）SASL/OAUTHBEARER的安全考慮因素

• Kafka中SASL/OAUTHBEARER的預設實現可以建立和驗證不安全的JSON網路令牌。這隻適合非生產性使用。
• OAUTHBEARER只能在生產環境中使用，並使用TLS加密來防止令牌的攔截。
• 預設的不安全的SASL/OAUTHBEARER實現可以使用自定義登入和SASL伺服器回撥處理程式來覆蓋（在生產環境中必須覆蓋），如上所述。
• 有關 OAuth 2 一般安全注意事項的更多細節，請參考 RFC 6749 第 10 節。

 

----------------------------------

（7）在broker中啟用多個SASL機制

1）在JAAS配置檔案的KafkaServer部分指定所有啟用機制的登入模組的配置。例如

        KafkaServer {
            com.sun.security.auth.module.Krb5LoginModule required
            useKeyTab=true
            storeKey=true
            keyTab="/etc/security/keytabs/kafka_server.keytab"
            principal="kafka/kafka1.hostname.com@EXAMPLE.COM";

            org.apache.kafka.common.security.plain.PlainLoginModule required
            username="admin"
            password="admin-secret"
            user_admin="admin-secret"
            user_alice="alice-secret";
        };

2）在server.properties中啟用SASL機制

 

    sasl.enabled.mechanisms=GSSAPI,PLAIN,SCRAM-SHA-256,SCRAM-SHA-512,OAUTHBEARER

 

3）如果需要的話，在server.properties中指定broker間通訊的SASL安全協議和機制

    security.inter.broker.protocol=SASL_PLAINTEXT (or SASL_SSL)
    sasl.mechanism.inter.broker.protocol=GSSAPI (or one of the other enabled mechanisms)

4）按照GSSAPI (Kerberos)、PLAIN、SCRAM和OAUTHBEARER中特定的機制步驟，為已啟用的機制配置SASL。

 

---------------------------

（8）修改執行中叢集的SASL機制

在執行的叢集中，可以使用以下順序修改 SASL 機制。

1. 啟用新的SASL機制，在server.properties中的sasl.enabled.methods中為每個broker新增該機制。更新 JAAS 配置檔案以包含這裡描述的兩種機制。增量反彈叢集節點。
2. 使用新機制重新啟動客戶端。
3. 要更改broker間通訊的機制（如果需要的話），將server.properties中的sasl.mechanism.inter.broker.protocol設定為新的機制，並再次增量反彈叢集。
4. 要刪除舊機制（如果需要），請從server.properties中的sasl.enabled.misms中刪除舊機制，並從JAAS配置檔案中刪除舊機制的條目。再次遞增地彈出叢集。

 

---------------------------

（9）使用授權令牌進行認證

基於委託令牌的身份驗證是一種輕量級的身份驗證機制，用於補充現有的SASL/SSL方法。委託令牌是kafkabroker和客戶端之間的共享祕密。委託令牌將幫助處理框架在安全的環境中把工作負載分配給可用的工作者，而不需要在使用2-way SSL時增加分配Kerberos TGT/keytabs或金鑰儲存的成本。更多細節請參見 KIP-48。

授權令牌使用的典型步驟是

1. 使用者通過SASL或SSL對Kafka叢集進行身份驗證，並獲得一個授權令牌。這可以使用Admin APIs或使用kafka-delegation-tokens.sh指令碼來完成。
2. 使用者將授權令牌安全地傳遞給Kafka客戶端，以便與Kafka叢集進行身份驗證。
3. 令牌所有者/更新者可以更新/到期授權令牌。

1）Token管理
主金鑰/祕密用於生成和驗證授權令牌。這是由config選項digation.token.master.key提供的。必須在所有broker中配置相同的祕鑰。如果祕鑰沒有設定或設定為空字串，則broker將禁用授權令牌驗證。

在當前的實現中，令牌的詳細資訊儲存在Zookeeper中，適合在Zookeeper處於私有網路的Kafka安裝中使用。另外，目前主金鑰/祕密是以純文字形式儲存在server.properties配置檔案中。我們打算在未來的Kafka版本中對其進行配置。

一個令牌有一個當前的壽命，和一個最大的可更新的壽命。預設情況下，令牌必須每24小時更新一次，最多7天。這些都可以使用 delegation.token.exp expiry.time.ms 和 delegation.token.max.life.ms 配置選項來配置。

也可以明確地取消令牌。如果一個令牌在到期時間前沒有更新，或者令牌超過了最大生命期，它將從所有的broker快取和zookeeper中刪除。

2）建立授權令牌
可以通過使用管理API或使用kafka-delegation-tokens.sh指令碼建立令牌。授權令牌請求(建立/更新/到期/描述)只能在SASL或SSL認證的通道上發出。如果初始認證是通過授權令牌完成的，則不能請求令牌。kafka-delegation-tokens.sh指令碼示例如下。

建立一個授權令牌。

    > bin/kafka-delegation-tokens.sh --bootstrap-server localhost:9092 --create   --max-life-time-period -1 --command-config client.properties --renewer-principal User:user1

 

更新一個授權令牌。

    > bin/kafka-delegation-tokens.sh --bootstrap-server localhost:9092 --renew    --renew-time-period -1 --command-config client.properties --hmac ABCDEFGHIJK

 

過期一個授權令牌。

    > bin/kafka-delegation-tokens.sh --bootstrap-server localhost:9092 --expire   --expiry-time-period -1   --command-config client.properties  --hmac ABCDEFGHIJK

 

可以使用--describe選項來描述現有的tokens。

 

    > bin/kafka-delegation-tokens.sh --bootstrap-server localhost:9092 --describe --command-config client.properties  --owner-principal User:user1

 

 

3）令牌認證
委託令牌認證搭載在當前的SASL/SCRAM認證機制上，我們必須在Kafka叢集上啟用SASL/SCRAM機制，如這裡所述。我們必須在Kafka叢集上啟用SASL/SCRAM機制，如這裡所述。

（1）配置Kafka客戶端

在producer.properties或consumer.properties中為每個客戶端配置JAAS配置屬性。登入模組描述了生產者和消費者等客戶端如何連線到Kafka Broker。下面是一個客戶端的令牌認證的配置示例。

   sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
        username="tokenID123" \
        password="lAYYSFmLs4bTjf+lTZ1LCHR/ZZFNA==" \
        tokenauth="true";

選項username和password是客戶端用來配置token id和token HMAC的，而選項tokenauth是用來指示伺服器關於token認證的。而選項tokenauth用於向伺服器指示token認證。在本例中，客戶端使用token id：tokenID123連線到broker。在一個JVM中，不同的客戶端可以通過在sasl.jaas.config中指定不同的token細節，使用不同的token進行連線。

客戶端的JAAS配置也可以指定為JVM引數，類似於這裡描述的broker。客戶端使用名為KafkaClient的登入部分。這個選項只允許一個使用者從JVM的所有客戶端連線。

 

4）手動旋轉祕密的程式
當需要旋轉祕密時，我們需要重新部署。在這個過程中，已經連線的客戶端將繼續工作。但任何新的連線請求和用舊的令牌更新/過期請求都可能失敗。步驟如下。

1. 過期所有現有令牌。
2. 通過滾動升級來輪換祕密，並
3. 生成新的Token

我們打算在未來的Kafka版本中實現自動化。

 

5）關於授權令牌的說明
目前，我們只允許一個使用者只為該使用者建立授權令牌。所有者/更新者可以更新或到期Token。所有者/更新者可以隨時描述他們自己的Token。要描述其他Token，我們需要在Token資源上新增DESCRIBE許可權。 macos/deepLFree.translatedWithDeepL.text

 

 

---------------------------

 

7.4 授權和ACL

Kafka提供了一個可插拔的Authorizer和一個開箱即用的Authorizer實現，它使用zookeeper來儲存所有的acls。Authorizer通過在server.properties中設定authorizer.class.name進行配置。要啟用開箱即用的實現，請使用。

authorizer.class.name=kafka.security.authorizer.AclAuthorizer 

Kafka acls的一般格式定義為 "Principal P is [Allowed/Denied] Operation O From Host H on any Resource R matching ResourcePattern RP"。您可以在KIP-11中閱讀更多關於acl結構的內容，在KIP-290中閱讀資源模式的內容。為了新增、刪除或列出acl，你可以使用Kafka授權器CLI。預設情況下，如果沒有資源模式（ResourcePatterns）與特定的資源R相匹配，那麼R就沒有相關的acl，因此除了超級使用者之外，其他任何人都不允許訪問R，如果你想改變這種行為，你可以在server.properties中包含以下內容。

allow.everyone.if.no.acl.found=true

你也可以在server.properties中新增超級使用者，如下所示（注意分號是分號，因為SSL使用者名稱可能包含逗號）。預設的PrincipalType字串 "User "是區分大小寫的。

super.users=User:Bob;User:Alice

 

自定義SSL使用者名稱

 

預設情況下，SSL使用者名稱的形式為 "CN=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown"。可以通過在server.properties中設定ssl.principal.mapping.rules為自定義規則來改變。這個配置允許一個規則列表，用於將X.500區分名對映為短名。這些規則是按順序評估的，第一個匹配的規則會被用來將其對映為短名。列表中後面的任何規則都會被忽略。
ssl.principal.mapping.rule的格式是一個列表，其中每條規則以 "rule: "開頭，幷包含一個表示式，格式如下。預設規則將返回X.500證照區分名的字串表示。如果該名稱與模式匹配，那麼替換命令將在該名稱上執行。這也支援小寫/大寫選項，以強制翻譯結果為小寫/大寫。這可以通過在規則末尾新增"/L "或"/U "來實現。

        RULE:pattern/replacement/
        RULE:pattern/replacement/[LU]

示例ssl.principal.mapping.規則值為。

        RULE:^CN=(.*?),OU=ServiceUsers.*$/$1/,
        RULE:^CN=(.*?),OU=(.*?),O=(.*?),L=(.*?),ST=(.*?),C=(.*?)$/$1@$2/L,
        RULE:^.*[Cc][Nn]=([a-zA-Z0-9.]*).*$/$1/L,
        DEFAULT

以上規則將區別名稱 "CN=serviceuser,OU=ServiceUsers,O=Unknown,L=Unknown,ST=Unknown,C=Unknown "翻譯為 "serviceuser"，將 "CN=adminUser,OU=Admin,O=Unknown,L=Unknown,ST=Unknown,C=Unknown "翻譯為 "adminuser@admin"。
對於高階用例，可以通過在server.properties中設定一個自定義的PrincipalBuilder來自定義名稱，如以下所示：

principal.builder.class=CustomizedPrincipalBuilderClass

 

自定義SASL使用者名稱

預設情況下， SASL 使用者名稱是 Kerberos principal 的主要部分。可以通過在 server.properties 中將 sasl.kerberos.principal.to.local.rules 設定為自定義規則來改變。sasl.kerberos.principal.to.local.rules 的格式是一個列表， 其中每條規則的工作方式與 Kerberos 配置檔案 (krb5.conf) 中的 auth_to_local 相同。這也支援額外的小寫/大寫規則， 以強制翻譯結果全部為小寫/大寫。這是通過在規則的結尾新增 "/L" 或 "/U" 來實現的。 檢視下面的語法格式。每條規則都以RULE:開頭，包含一個表示式，格式如下。更多細節請參見 kerberos 文件。

        RULE:[n:string](regexp)s/pattern/replacement/
        RULE:[n:string](regexp)s/pattern/replacement/g
        RULE:[n:string](regexp)s/pattern/replacement//L
        RULE:[n:string](regexp)s/pattern/replacement/g/L
        RULE:[n:string](regexp)s/pattern/replacement//U
        RULE:[n:string](regexp)s/pattern/replacement/g/U

新增一個規則來正確地將user@MYDOMAIN.COM 翻譯成使用者，同時保留預設規則的例子是。

sasl.kerberos.principal.to.local.rules=RULE:[1:$1@$0](.*@MYDOMAIN.COM)s/@.*//,DEFAULT

 

命令列介面

Kafka授權管理CLI可以在bin目錄下和其他CLI一起找到。CLI指令碼名為kafka-acls.sh。下面列出了該指令碼支援的所有選項。

 

選項	描述	預設值	選項類別
--add	向指令碼表示使用者正在嘗試新增一個ACL。		Action
--remove	向指令碼表明使用者正在嘗試刪除一個cl。		Action
--list	向指令碼表示使用者正在嘗試列出acls。		Action
--authorizer	授權人的全稱類名稱。	kafka.security.authorizer.AclAuthorizer	Configuration
--authorizer-properties	key=val對，將被傳遞給authorizer進行初始化。對於預設的授權器，例子中的值是：zookeeper.connect=localhost:2181。		Configuration
--bootstrap-server	用於建立與Kafka叢集連線的主機/埠對列表。只能指定--bootstrap-server或--authorizer選項中的一個。		Configuration
--command-config	一個包含要傳遞給管理客戶端的配置的屬性檔案。這個選項只能和--bootstrap-server選項一起使用。		Configuration
--cluster	向指令碼表明，使用者正試圖在單個叢集資源上與acls互動。		ResourcePattern
--topic [topic-name]	向指令碼表明使用者正試圖與acls就主題資源模式進行互動。		ResourcePattern
--group [group-name]	向指令碼表明，使用者正試圖與消費者組資源模式的acls互動。		ResourcePattern
--transactional-id [transactional-id]	應該新增或刪除ACL的transactionalId。值為*表示ACLs應該適用於所有transactionalIds。		ResourcePattern
--delegation-token [delegation-token]	應新增或刪除ACL的授權標記。值為*表示ACL應適用於所有標記。		ResourcePattern
--resource-pattern-type [pattern-type]	向指令碼表明使用者希望使用的資源模式型別（用於--新增）或資源模式過濾器（用於--list和--remove）。 當新增acls時，應該是一個特定的模式型別，例如 "字面 "或 "字首"。 當列出或刪除 acls 時，可以使用特定的模式型別過濾器來列出或刪除特定型別的資源模式中的 acls，也可以使用 "any "或 "match "的過濾器值，其中 "any "將匹配任何模式型別，但將與資源名稱完全匹配，而 "match "將執行模式匹配，以列出或刪除所有影響所提供資源的 acls。 警告：當'match'與'--remove'開關結合使用時，應謹慎使用。	literal	Configuration
--allow-principal	Principal為PrincipalType:name格式，將被新增到允許許可權的ACL中。預設的PrincipalType字串 "User "是區分大小寫的。 你可以在一個命令中指定多個--allow-principal。		Principal
--deny-principal	Principal為PrincipalType:name格式，將被新增到ACL的Deny許可權中。預設 PrincipalType 字串 "User" 是區分大小寫的。 您可以在一條命令中指定多個 --deny-principal。		Principal
--principal	Principal是PrincipalType:name格式，將與-list選項一起使用。預設的PrincipalType字串 "User "是區分大小寫的。這將列出指定Principal的ACL。 你可以在一條命令中指定多個--principal。		Principal
--allow-host	在--allow-principal中列出的委託人可以訪問的IP地址。	if --allow-principal is specified defaults to * which translates to "all hosts"	Host
--deny-host	拒絕訪問 --deny-principal 中列出的 principals 的 IP 地址。	if --deny-principal is specified defaults to * which translates to "all hosts"	Host
--operation	允許或拒絕的操作。 有效值為： Read Write Create Delete Alter Describe ClusterAction DescribeConfigs AlterConfigs IdempotentWrite All	All	Operation
--producer	可以方便地新增/刪除生產者角色的acls。這將生成允許寫入、描述和建立主題的 acls。		Convenience
--consumer	為消費者角色新增/刪除 acls 的方便選項。這將生成允許READ、DESCRIBE on topic和READ on consumer-group的acls。		Convenience
--idempotent	啟用生產者的同位素。這應該與--producer選項結合使用。 請注意，如果生產者被授權使用某個特定的事務ID，則會自動啟用冪等性。		Convenience
--force	方便的選項，對所有的查詢都假定是，不做提示。		Convenience
--zk-tls-config-file	標識ZooKeeper客戶端TLS連線性屬性的授權者定義的檔案。除了下列屬性之外的任何屬性（無論是否有 "authorizer. "字首）都會被忽略：zookeeper.clientCnxnSocket, zookeeper.ssl.cipher.suites, zookeeper.ssl.client.enable, zookeeper.ssl.crl.enable, zookeeper.ssl.enabled.protocols, zookeeper.ssl.endpoint.identification.algorithm, zookeeper.ssl.keystore.location, zookeeper.ssl.keystore.password, zookeeper.ssl.keystore.type, zookeeper.ssl.ocsp.enable, zookeeper.ssl.protocol, zookeeper.ssl.truststore.location, zookeeper.ssl.truststore.password, zookeeper.ssl.truststore.type		Configuration

 

例子

新增Acls

假設你想新增一個 acl "Principals User:Bob 和 User:Alice are allowed to perform Operation Read and Write on Topic Test-Topic from IP 198.51.100.0 and IP 198.51.100.1"。您可以通過以下選項執行CLI。
bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:Bob --allow-principal User:Alice --allow-host 198.51.100.0 --allow-host 198.51.100.1 --operation Read --operation Write --topic Test-topic。
預設情況下，所有沒有明確的允許對資源進行訪問操作的 acl 的 principal 都會被拒絕。在極少數情況下，如果定義了一個允許訪問所有資源但不允許訪問某些 principal 的 acl，我們將不得不使用 --deny-principal 和 --deny-host 選項。例如，如果我們想允許所有使用者從Test-topic讀取資料，但只拒絕來自IP 198.51.100.3的User:BadBob，我們可以使用以下命令。

bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:* --allow-host * --deny-principal User:BadBob --deny-host 198.51.100.3 --operation Read --topic Test-topic

 

請注意，--allow-host和--deny-host只支援IP地址（不支援主機名）。上面的例子通過指定--topic [topic-name]作為資源模式選項，將acls新增到一個主題中。同樣，使用者可以通過指定--cluster將acls新增到叢集，通過指定--group [group-name]將acls新增到消費者組。你可以在任何特定型別的資源上新增acls，例如，假設你想新增一個acl "Principal User:Peter is allowed to produce to any Topic from IP 198.51.200.0"，你可以通過使用萬用字元資源'*'來實現，例如，通過執行CLI的以下選項。

bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:Peter --allow-host 198.51.200.1 --producer --topic *

 

你可以在字首資源模式上新增acl，例如，假設你想新增一個acl "Principal User:Jane is allowed to produce to any Topic whose name starts with 'Test-' from any host"。你可以通過以下選項執行CLI來實現。

bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:Jane --producer --topic Test- --resource-pattern-type prefixed

 

注意，--resource-pattern-type預設為 "literal"，它隻影響具有完全相同名稱的資源，或者在萬用字元資源名稱 "*"的情況下，影響具有任何名稱的資源。

刪除 Acls

刪除acls的方法大同小異，唯一不同的是，使用者必須指定--remove選項，而不是--add選項。唯一不同的是，使用者必須指定--remove選項，而不是--add選項。要刪除上面第一個例子中新增的acls，我們可以通過以下選項執行CLI。

 bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --remove --allow-principal User:Bob --allow-principal User:Alice --allow-host 198.51.100.0 --allow-host 198.51.100.1 --operation Read --operation Write --topic Test-topic 

 

如果你想刪除上面新增在字首資源模式中的acl，我們可以通過以下選項執行CLI。
bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --remove --allow-principal User:Jane --producer --topic Test--resource-pattern-type Prefixed(字首資源模式)

List Acls

我們可以通過指定資源的 --list 選項來列出任何資源的 acls。要列出Test-topic這個資源模式的所有acls，我們可以通過以下選項執行CLI。

bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --list --topic Test-topic

 

但是，這將只返回已經新增到這個資源模式的 acls。其他的 acls 可能會影響對主題的訪問，例如，主題萬用字元 '*' 上的任何 acls，或者字首資源模式上的任何 acls。萬用字元資源模式上的acls可以被顯式查詢。

bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --list --topic *

 

然而，不一定能明確地查詢與 Test-topic 匹配的字首資源模式的 acls，因為這些模式的名稱可能不知道。我們可以使用'--resource-pattern-type match'來列出所有影響Test-topic的acls，如

bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --list --topic Test-topic --resource-pattern-type match

 

這將列出所有匹配的文字、萬用字元和字首資源模式的acls。 macos/deepLFree.translatedWithDeepL.text

 

增加或刪除作為生產者或消費者的委託人

在 acl 管理中，最常見的使用情況是新增/刪除一個委託人作為生產者或消費者，所以我們新增了方便的選項來處理這些情況。為了新增User:Bob作為Test-topic的生產者，我們可以執行以下命令。

 bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:Bob --producer --topic Test-topic

 

同樣的，如果要新增Alice作為Test-topic的消費者，並加入消費者組Group-1，我們只需要通過--consumer選項。

 bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:Bob --consumer --topic Test-topic --group Group-1 

 

請注意，對於消費者選項，我們還必須指定消費者組。為了從生產者或消費者角色中移除一個委託人，我們只需要傳遞--remove選項。

基於管理API的ACL管理

在ClusterResource上擁有Alter許可權的使用者可以使用Admin API來管理ACL。kafka-acls.sh指令碼支援AdminClient API來管理ACL，而不需要直接與zookeeper/authorizer互動。以上所有的例子都可以通過使用--bootstrap-server選項來執行。例如

            bin/kafka-acls.sh --bootstrap-server localhost:9092 --command-config /tmp/adminclient-configs.conf --add --allow-principal User:Bob --producer --topic Test-topic
            bin/kafka-acls.sh --bootstrap-server localhost:9092 --command-config /tmp/adminclient-configs.conf --add --allow-principal User:Bob --consumer --topic Test-topic --group Group-1
            bin/kafka-acls.sh --bootstrap-server localhost:9092 --command-config /tmp/adminclient-configs.conf --list --topic Test-topic

授權基元

協議呼叫通常是對Kafka中的某些資源進行一些操作。需要了解這些操作和資源，才能設定有效的保護。在本節中，我們將列出這些操作和資源，然後列出這些操作和資源與協議的組合，看看有效的場景。

 

kafka中的操作

有一些操作基元可以用來建立許可權。這些操作可與某些資源相匹配，以允許特定使用者進行特定協議呼叫。這些資源是：

• Read
• Write
• Create
• Delete
• Alter
• Describe
• ClusterAction
• DescribeConfigs
• AlterConfigs
• IdempotentWrite
• All

kafka中的資源

上面的操作可以應用在某些資源上，下面將對這些資源進行說明。

• Topic：這只是代表一個Topic。所有對topic進行操作（如讀、寫）的協議呼叫都需要新增相應的許可權。如果一個topic資源出現授權錯誤，那麼將返回一個TOPIC_AUTHORIZATION_FAILED（錯誤程式碼：29）。
• Group：這代表了broker中的消費者組。所有與消費者組一起工作的協議呼叫，比如加入一個組，必須在主題中擁有組的許可權。如果沒有給定許可權，那麼協議響應中會返回一個GROUP_AUTHORIZATION_FAILED（錯誤程式碼：30）。
• Cluster：該資源代表叢集。影響整個叢集的操作，比如受控關機，都是由Cluster資源上的許可權保護的。如果叢集資源上存在授權問題，那麼將返回一個CLUSTER_AUTHORIZATION_FAILED（錯誤程式碼：31）。
• TransactionalId：這個資源表示與事務相關的操作，比如提交。如果發生任何錯誤，那麼broker將返回一個TRANSACTIONAL_ID_AUTHORIZATION_FAILED（錯誤程式碼：53）。
• DelegationToken：這代表叢集中的授權令牌。諸如描述授權令牌的行為可以通過對DelegationToken資源的許可權來保護。由於這些物件在Kafka中的行為有點特殊，建議閱讀KIP-48和相關的上游文件，在Authentication using Delegation Tokens。

關於議定書的業務和資源

在下面的表格中，我們將列出Kafka API協議執行的對資源的有效操作：

 

協議(API KEY)	操作	資源	備註
PRODUCE (0)	Write	TransactionalId	一個設定了transactional.id的事務生產者需要這個許可權。
PRODUCE (0)	IdempotentWrite	Cluster	冪等的產生行動需要這種特權。
PRODUCE (0)	Write	Topic	這適用於正常的生產動作。
FETCH (1)	ClusterAction	Cluster	追隨者必須在Cluster資源上有ClusterAction，才能獲取分割槽資料。
FETCH (1)	Read	Topic	常規的Kafka消費者需要在他們獲取的每個分割槽上獲得READ許可權。
LIST_OFFSETS (2)	Describe	Topic
METADATA (3)	Describe	Topic
METADATA (3)	Create	Cluster	如果啟用了topic自動建立，那麼broker端API將檢查是否存在Cluster級別的許可權。如果找到了，那麼就會允許建立主題，否則就會遍歷主題級別的許可權（見下一個）。
METADATA (3)	Create	Topic	如果啟用了自動建立主題，但給定的使用者沒有群集級別的許可權（以上），這將授權自動建立主題。
LEADER_AND_ISR (4)	ClusterAction	Cluster
STOP_REPLICA (5)	ClusterAction	Cluster
UPDATE_METADATA (6)	ClusterAction	Cluster
CONTROLLED_SHUTDOWN (7)	ClusterAction	Cluster
OFFSET_COMMIT (8)	Read	Group	一個偏移只有在被授權給給定的組和主題時才能被提交（見下文）。首先檢查組的訪問權，然後檢查主題的訪問權。
OFFSET_COMMIT (8)	Read	Topic	由於偏移提交是消耗過程的一部分，所以它需要有讀取操作的許可權。
OFFSET_FETCH (9)	Describe	Group	與OFFSET_COMMIT類似，應用程式也必須有組和主題級別的許可權才能獲取。然而在這種情況下，它需要的是描述訪問而不是讀取。首先檢查組的訪問許可權，然後檢查主題的訪問許可權。
OFFSET_FETCH (9)	Describe	Topic
FIND_COORDINATOR (10)	Describe	Group	FIND_COORDINATOR請求可以是 "Group "型別，在這種情況下，它是在尋找消費者組協調人。這個特權將代表Group模式。
FIND_COORDINATOR (10)	Describe	TransactionalId	這隻適用於事務性生產者，當生產者試圖尋找事務協調人時，會被檢查。
JOIN_GROUP (11)	Read	Group
HEARTBEAT (12)	Read	Group
LEAVE_GROUP (13)	Read	Group
SYNC_GROUP (14)	Read	Group
DESCRIBE_GROUPS (15)	Describe	Group
LIST_GROUPS (16)	Describe	Cluster	當broker檢查授權一個list_groups請求時，它首先檢查這個群集級別的授權。如果沒有找到，那麼它就繼續逐個檢查各組。這個操作不會返回CLUSTER_AUTHORIZATION_FAILED。
LIST_GROUPS (16)	Describe	Group	如果沒有任何一個組被授權，那麼只會返回一個空的響應，而不是一個錯誤。這個操作不會返回CLUSTER_AUTHORIZATION_FAILED。這是從2.1版本開始適用的。
SASL_HANDSHAKE (17)			SASL握手是認證過程的一部分，因此這裡不可能應用任何形式的授權。
API_VERSIONS (18)			API_VERSIONS請求是Kafka協議握手的一部分，發生在連線時和任何認證之前。因此不可能通過授權來控制。
CREATE_TOPICS (19)	Create	Cluster	如果沒有叢集級別的授權，那麼就不會返回CLUSTER_AUTHORIZATION_FAILED，而是回落到使用主題級別，也就是下面。如果有問題的話，那就會丟擲錯誤。
CREATE_TOPICS (19)	Create	Topic	這是從2.0版本開始適用的。
DELETE_TOPICS (20)	Delete	Topic
DELETE_RECORDS (21)	Delete	Topic
INIT_PRODUCER_ID (22)	Write	TransactionalId
INIT_PRODUCER_ID (22)	IdempotentWrite	Cluster
OFFSET_FOR_LEADER_EPOCH (23)	ClusterAction	Cluster	如果這個操作沒有群集級別的許可權，那麼就會檢查主題一級。
OFFSET_FOR_LEADER_EPOCH (23)	Describe	Topic	這是從2.1版本開始適用的。
ADD_PARTITIONS_TO_TXN (24)	Write	TransactionalId	這個API只適用於事務性請求。它首先檢查TransactionalId資源上的寫操作，然後檢查主題中的Topic（如下）。
ADD_PARTITIONS_TO_TXN (24)	Write	Topic
ADD_OFFSETS_TO_TXN (25)	Write	TransactionalId	與ADD_PARTITIONS_TO_TXN類似，它只適用於事務性請求。它首先檢查TransactionalId資源上是否有寫操作，然後檢查是否可以在給定的組上進行讀操作（如下）。
ADD_OFFSETS_TO_TXN (25)	Read	Group
END_TXN (26)	Write	TransactionalId
WRITE_TXN_MARKERS (27)	ClusterAction	Cluster
TXN_OFFSET_COMMIT (28)	Write	TransactionalId
TXN_OFFSET_COMMIT (28)	Read	Group
TXN_OFFSET_COMMIT (28)	Read	Topic
DESCRIBE_ACLS (29)	Describe	Cluster
CREATE_ACLS (30)	Alter	Cluster
DELETE_ACLS (31)	Alter	Cluster
DESCRIBE_CONFIGS (32)	DescribeConfigs	Cluster	如果broker配置被請求，那麼broker將檢查叢集級別的許可權。
DESCRIBE_CONFIGS (32)	DescribeConfigs	Topic	如果請求主題配置，那麼broker將檢查主題級別的許可權。
ALTER_CONFIGS (33)	AlterConfigs	Cluster	如果broker配置被改變，那麼broker將檢查叢集級別的許可權。
ALTER_CONFIGS (33)	AlterConfigs	Topic	如果話題配置被更改，那麼broker將檢查話題級別的許可權。
ALTER_REPLICA_LOG_DIRS (34)	Alter	Cluster
DESCRIBE_LOG_DIRS (35)	Describe	Cluster	授權失敗時將返回一個空的響應。
SASL_AUTHENTICATE (36)			SASL_AUTHENTICATE是認證過程的一部分，因此這裡不可能應用任何形式的授權。
CREATE_PARTITIONS (37)	Alter	Topic
CREATE_DELEGATION_TOKEN (38)			建立授權令牌有特殊的規則，關於這一點，請參見使用授權令牌的認證部分。
RENEW_DELEGATION_TOKEN (39)			更新授權令牌有特殊的規則，關於這一點，請參見使用授權令牌的認證部分。
EXPIRE_DELEGATION_TOKEN (40)			過期的授權令牌有特殊的規則，關於這一點，請參見使用授權令牌的認證部分。
DESCRIBE_DELEGATION_TOKEN (41)	Describe	DelegationToken	描述授權令牌有特殊的規則，關於這一點請參見使用授權令牌的認證部分。
DELETE_GROUPS (42)	Delete	Group
ELECT_PREFERRED_LEADERS (43)	ClusterAction	Cluster
INCREMENTAL_ALTER_CONFIGS (44)	AlterConfigs	Cluster	如果broker配置被改變，那麼broker將檢查叢集級別的許可權。
INCREMENTAL_ALTER_CONFIGS (44)	AlterConfigs	Topic	如果話題配置被更改，那麼broker將檢查話題級別的許可權。
ALTER_PARTITION_REASSIGNMENTS (45)	Alter	Cluster
LIST_PARTITION_REASSIGNMENTS (46)	Describe	Cluster
OFFSET_DELETE (47)	Delete	Group
OFFSET_DELETE (47)	Read	Topic

 

------------------------------

7.5 在執行的群集中加入安全功能

您可以通過前面討論的一個或多個支援的協議來保護正在執行的群集。這是分階段進行的。

• 逐步反彈群集節點以開啟額外的安全埠。
• 使用安全埠而非 PLAINTEXT 埠重新啟動客戶端（假設您正在確保客戶端-代理連線的安全）。
• 再次遞增反彈群集，以啟用代理對代理的安全（如果需要的話）。
• 最後增量彈出，關閉PLAINTEXT埠。

配置SSL和SASL的具體步驟在7.2和7.3節中描述。按照這些步驟為您所需的協議啟用安全功能。
安全性實現允許您為代理-客戶和代理-代理通訊配置不同的協議。這些協議必須在單獨的彈跳中啟用。PLAINTEXT埠必須在整個過程中保持開放，以便broker和/或客戶可以繼續通訊。
當執行增量反彈時，通過SIGTERM乾淨利落地停止broker。在進入下一個節點之前，等待重啟的副本返回到ISR列表也是一個好的做法。
舉個例子，比如說我們希望用SSL加密broker-客戶和broker-broker的通訊。在第一次增量反彈中，每個節點上都會開啟一個SSL埠。

            listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092

 

然後我們重啟客戶機，修改他們的配置指向新開啟的安全埠。

            bootstrap.servers = [broker1:9092,...]
            security.protocol = SSL
            ...etc

在第二次增量伺服器跳轉中，我們指示Kafka使用SSL作為broker-broker協議（將使用相同的SSL埠）。

            listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092
            security.inter.broker.protocol=SSL

在最後的反彈中，我們通過關閉PLAINTEXT埠來保證叢集的安全。

            listeners=SSL://broker1:9092
            security.inter.broker.protocol=SSL

另外，我們也可以選擇開放多個埠，以便不同的協議可以用於broker-broker和broker-客戶端的通訊。假設我們希望在整個過程中使用 SSL 加密（即用於 broker-broker 和 broker-client 通訊），但我們也希望在 broker-client 連線中新增 SASL 認證。我們將通過在第一次跳轉時開啟兩個額外的埠來實現。

            listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092,SASL_SSL://broker1:9093

 

然後我們重啟客戶機，修改他們的配置指向新開啟的SASL和SSL安全埠。

            bootstrap.servers = [broker1:9093,...]
            security.protocol = SASL_SSL
            ...etc

第二次伺服器跳轉會將叢集切換到使用加密的broker-broker通訊，通過我們之前開通的SSL埠9092埠。

            listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092,SASL_SSL://broker1:9093
            security.inter.broker.protocol=SSL

最後反彈通過關閉PLAINTEXT埠來保證叢集的安全。

        listeners=SSL://broker1:9092,SASL_SSL://broker1:9093
        security.inter.broker.protocol=SSL

ZooKeeper可以獨立於Kafka叢集而被保護。這樣做的步驟在7.6.2節中介紹。

 

----------------------

7.6 ZooKeeper認證

ZooKeeper從3.5.x版本開始支援相互TLS(mTLS)認證。Kafka支援使用SASL和mTLS對ZooKeeper進行身份驗證--可以單獨使用，也可以同時使用--從2.5版本開始。參見KIP-515: 啟用ZK客戶端使用新的TLS支援的身份驗證瞭解更多細節。
當單獨使用mTLS時，每個代理和任何CLI工具(如ZooKeeper安全遷移工具)應該用相同的區別名稱(DN)來識別自己，因為它是ACL'ed的DN。這可以按照下面的描述進行更改，但這涉及到編寫和部署一個自定義的ZooKeeper驗證提供商。一般來說，每個證照都應該有相同的DN，但有不同的主題替代名(SAN)，這樣ZooKeeper對broker和任何CLI工具的主機名驗證就會成功。

當使用SASL認證到ZooKeeper與mTLS一起使用時，SASL身份和建立znode的DN(即建立broker的證照)或安全遷移工具的DN(如果遷移是在znode建立後進行的)將被ACL'ed，所有broker和CLI工具將被授權，即使他們都使用不同的DN，因為他們都將使用相同的ACL'ed SASL身份。只有當單獨使用mTLS身份驗證時，所有的DN必須匹配（SAN變得至關重要--同樣，在沒有編寫和部署自定義ZooKeeper身份驗證提供商的情況下，如下所述）。

使用broker屬性檔案為broker設定TLS配置，如下所述。

使用--zk-tls-config-file <file>選項在Zookeeper安全遷移工具中設定TLS配置。kafka-acls.sh和kafka-configs.sh CLI工具也支援--zk-tls-config-file <file>選項。

使用-zk-tls-config-file <file>選項（注意是單斜線而不是雙斜線）為zookeeper-shell.sh CLI工具設定TLS配置。

 

7.6.1 新的叢集

7.6.1.1 ZooKeeper SASL認證

要在broker上啟用ZooKeeper SASL認證，有兩個必要的步驟。

1. 建立一個JAAS登入檔案，並設定相應的系統屬性指向它，如上所述。
2. 將每個broker的配置屬性zookeeper.set.acl設定為true。

儲存在ZooKeeper中的Kafka叢集的後設資料是世界可讀的，但只能由broker修改。這個決定背後的理由是，儲存在ZooKeeper中的資料並不敏感，但對這些資料的不當操作會導致叢集中斷。我們還建議通過網路分段限制對ZooKeeper的訪問（只有broker和一些管理工具需要訪問ZooKeeper）。

 

7.6.1.2 ZooKeeper相互TLS認證

ZooKeeper的mTLS認證可以在有或沒有SASL認證的情況下啟用。如上所述，當單獨使用mTLS時，每個broker和任何CLI工具(如ZooKeeper安全遷移工具)一般都必須用相同的區分名(DN)來標識自己，因為是DN被ACL'ed，這意味著每個證照都應該有一個合適的Subject Alternative Name(SAN)，這樣ZooKeeper對broker和任何CLI工具的主機名驗證才能成功。

可以通過編寫一個擴充套件 org.apache.zookeeper.server.auth.X509AuthenticationProvider 的類，並覆蓋 protected String getClientId(X509Certificate clientCert)的方法，來使用 DN 以外的其他東西作為 mTLS 客戶的身份。選擇一個方案名，並在ZooKeeper中設定authProvider.[scheme]為自定義實現的全限定類名；然後設定ssl.authProvider=[scheme]來使用它。

 

這裡是ZooKeeper啟用TLS認證的一個示例（部分）配置。這些配置在ZooKeeper管理指南中有所描述。

        secureClientPort=2182
        serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory
        authProvider.x509=org.apache.zookeeper.server.auth.X509AuthenticationProvider
        ssl.keyStore.location=/path/to/zk/keystore.jks
        ssl.keyStore.password=zk-ks-passwd
        ssl.trustStore.location=/path/to/zk/truststore.jks
        ssl.trustStore.password=zk-ts-passwd

重要提示：ZooKeeper不支援將ZooKeeper伺服器keystore中的金鑰密碼設定為與keystore密碼本身不同的值。請務必將金鑰密碼設定為與keystore密碼相同。
這裡是一個使用mTLS認證連線到ZooKeeper的Kafka Broker配置示例（部分）。這些配置在上面的Broker Configs裡有描述:

        # connect to the ZooKeeper port configured for TLS
        zookeeper.connect=zk1:2182,zk2:2182,zk3:2182
        # required to use TLS to ZooKeeper (default is false)
        zookeeper.ssl.client.enable=true
        # required to use TLS to ZooKeeper
        zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
        # define key/trust stores to use TLS to ZooKeeper; ignored unless zookeeper.ssl.client.enable=true
        zookeeper.ssl.keystore.location=/path/to/kafka/keystore.jks
        zookeeper.ssl.keystore.password=kafka-ks-passwd
        zookeeper.ssl.truststore.location=/path/to/kafka/truststore.jks
        zookeeper.ssl.truststore.password=kafka-ts-passwd
        # tell broker to create ACLs on znodes
        zookeeper.set.acl=true

重要提示：ZooKeeper不支援將ZooKeeper客戶端（即broker）keystore中的金鑰密碼設定為與keystore密碼本身不同的值。請務必將金鑰密碼設定為與keystore密碼相同。

7.6.2 遷移群組

如果你執行的Kafka版本不支援安全，或者只是禁用了安全功能，而你又想讓叢集變得安全，那麼你需要執行以下步驟來啟用ZooKeeper身份驗證，並儘量減少對你的操作的干擾。

1. 在ZooKeeper上啟用SASL和/或mTLS認證。如果啟用mTLS，你現在會有一個非TLS埠和一個TLS埠，像這樣
   • 　　

         clientPort=2181
         secureClientPort=2182
         serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory
         authProvider.x509=org.apache.zookeeper.server.auth.X509AuthenticationProvider
         ssl.keyStore.location=/path/to/zk/keystore.jks
         ssl.keyStore.password=zk-ks-passwd
         ssl.trustStore.location=/path/to/zk/truststore.jks
         ssl.trustStore.password=zk-ts-passwd

2. 根據需要對brokers進行滾動重啟，設定JAAS登入檔案和/或定義ZooKeeper相互的TLS配置（包括連線到啟用TLS的ZooKeeper埠），這使得brokers能夠對ZooKeeper進行認證。在滾動重啟結束時，broker能夠用嚴格的ACL操縱znodes，但他們不會用這些ACL建立znodes。
3. 如果您啟用了mTLS，請在ZooKeeper中禁用非TLS埠。
4. 對brokers進行第二次滾動重啟，這次將配置引數zookeeper.set.acl設定為true，這樣可以在建立znodes時使用安全的ACL。
5. 執行ZkSecurityMigrator工具。要執行這個工具，有這樣一個指令碼：bin/zookeeper-security-migration.sh，其中zookeeper.acl設定為secure。這個工具會遍歷相應的子樹，改變znodes的ACL。如果你啟用了mTLS，請使用--zk-tls-config-file <file>選項。

也可以在安全叢集中關閉身份驗證。要做到這一點，請按照以下步驟進行:

1. 對設定JAAS登入檔案和/或定義ZooKeeper相互TLS配置的brokers進行滾動重啟，使brokers能夠進行身份驗證，但將zookeeper.set.acl設定為false。在滾動重啟結束時，broker停止建立具有安全ACL的znodes，但仍然能夠驗證和操作所有znodes。
2. 執行ZkSecurityMigrator工具。要執行該工具，執行這個指令碼 bin/zookeeper-security-migration.sh，並將zookeeper.acl設定為unsecure。這個工具會遍歷相應的子樹，改變znodes的ACL。如果你需要設定TLS配置，請使用--zk-tls-config-file <file>選項。
3. 如果你禁用mTLS，請在ZooKeeper中啟用非TLS埠。
4. 對brokers進行第二次滾動重啟，這次省略設定JAAS登入檔案的系統屬性和/或按要求刪除ZooKeeper相互TLS配置（包括連線到未啟用TLS的ZooKeeper埠）。
5. 如果您正在禁用mTLS，請在ZooKeeper中禁用TLS埠。
   
   

下面是一個如何執行遷移工具的例子:

    bin/zookeeper-security-migration.sh --zookeeper.acl=secure --zookeeper.connect=localhost:2181

 

執行此功能可檢視完整的引數列表。

 

    bin/zookeeper-security-migration.sh --help

 

7.6.3 遷移ZooKeeper合集

還需要在ZooKeeper合集上啟用SASL和/或mTLS認證。要做到這一點，我們需要執行伺服器的滾動重啟並設定一些屬性。請看上面的mTLS資訊。更多細節請參考ZooKeeper文件。

1. Apache ZooKeeper文件
2. Apache ZooKeeper wiki

7.6.4 ZooKeeper Quorum Mutual TLS認證

可以啟用ZooKeeper伺服器之間的mTLS認證。更多細節請參考ZooKeeper檔案。

7.7 ZooKeeper加密

ZooKeeper使用相互TLS的連線是加密的。從ZooKeeper 3.5.7版本開始（Kafka 2.5版本附帶的版本），ZooKeeper支援server端配置ssl.clientAuth（不區分大小寫：want/need/none為有效選項，預設為need），在ZooKeeper中把這個值設定為none，允許客戶端通過TLS加密的連線，而不需要出示自己的證照。這裡是一個僅用TLS加密連線到ZooKeeper的Kafka Broker配置示例（部分）。這些配置在上面的Broker Configs裡有描述。

        # connect to the ZooKeeper port configured for TLS
        zookeeper.connect=zk1:2182,zk2:2182,zk3:2182
        # required to use TLS to ZooKeeper (default is false)
        zookeeper.ssl.client.enable=true
        # required to use TLS to ZooKeeper
        zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
        # define trust stores to use TLS to ZooKeeper; ignored unless zookeeper.ssl.client.enable=true
        # no need to set keystore information assuming ssl.clientAuth=none on ZooKeeper
        zookeeper.ssl.truststore.location=/path/to/kafka/truststore.jks
        zookeeper.ssl.truststore.password=kafka-ts-passwd
        # tell broker to create ACLs on znodes (if using SASL authentication, otherwise do not set this)
        zookeeper.set.acl=true

 

8. KAFKA CONNECT

8.1 概述

Kafka Connect是一個用於在Apache Kafka和其他系統之間可擴充套件和可靠地流式資料的工具。它使快速定義聯結器變得簡單，這些聯結器可以將大量的資料集合移入和移出Kafka。Kafka Connect可以從您的所有應用伺服器中攝取整個資料庫或收集指標到Kafka主題中，使資料可用於低延遲的流處理。匯出作業可以將Kafka主題中的資料傳送到二級儲存和查詢系統中，或者傳送到批處理系統中進行離線分析。

Kafka Connect的功能包括：

• Kafka聯結器的通用框架--Kafka Connect標準化了其他資料系統與Kafka的整合，簡化了聯結器的開發、部署和管理。
• 分散式和獨立模式--擴大到支援整個組織的大型集中管理服務，或縮小到開發、測試和小型生產部署。
• REST介面--通過一個易於使用的REST API提交和管理聯結器到您的Kafka Connect叢集。
• 自動偏移管理--只需從聯結器中獲取一點資訊，Kafka Connect就能自動管理偏移提交過程，因此聯結器開發人員無需擔心聯結器開發中容易出錯的部分。
• 預設的分散式和可擴充套件性--Kafka Connect建立在現有的組管理協議上。可以新增更多的工作者來擴充套件Kafka Connect叢集。
• 流式/批處理整合--利用Kafka現有的功能，Kafka Connect是銜接流式和批處理資料系統的理想解決方案。

 

8.2 使用者指南

快速入門提供了一個簡短的例子，說明如何執行獨立版本的Kafka Connect。本節將詳細介紹如何配置、執行和管理Kafka Connect。

 

執行Kafka連線

Kafka Connect目前支援兩種執行模式：獨立模式（單程式）和分散式模式。

在獨立模式下，所有的工作都在一個程式中執行。這種配置更容易設定和上手，在只有一個worker的情況下可能很有用（例如收集日誌檔案），但它不能從Kafka Connect的一些功能中受益，例如容錯。您可以使用以下命令啟動一個獨立的程式。

    > bin/connect-standalone.sh config/connect-standalone.properties connector1.properties [connector2.properties ...]

 

第一個引數是worker的配置。這包括諸如Kafka連線引數、序列化格式以及提交偏移的頻率等設定。所提供的示例在使用config/server.properties提供的預設配置執行的本地叢集中應該可以很好地工作。它將需要調整以用於不同的配置或生產部署。所有的工作者（包括單機和分散式）都需要一些配置。

• bootstrap.server - 用於引導連線到Kafka的Kafka伺服器列表。
• key.converter - 轉換器類，用於在Kafka Connect格式和寫入Kafka的序列化形式之間進行轉換。這控制了向Kafka寫入或從Kafka讀取的訊息中鍵的格式，由於這與聯結器無關，所以允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。
• value.converter - 轉換器類，用於在Kafka Connect格式和寫入Kafka的序列化形式之間進行轉換。這控制了向Kafka寫入或從Kafka讀取的訊息中的值的格式，由於這與聯結器無關，它允許任何聯結器與任何序列化格式一起工作。常見格式的例子包括JSON和Avro。
• 單機模式特有的重要配置選項是。

offset.storage.file.filename - 要在其中儲存偏移資料的檔案。
這裡配置的引數是為了讓Kafka Connect使用的生產者和消費者訪問配置、偏移和狀態主題。對於Kafka源任務使用的生產者和Kafka匯任務使用的消費者的配置，可以使用相同的引數，但需要分別以producer.和consumer.為字首。唯一一個從worker配置中繼承的沒有字首的Kafka客戶端引數是bootstrap.servers，在大多數情況下，這就足夠了，因為經常使用同一個叢集來實現所有目的。一個明顯的例外是安全叢集，它需要額外的引數來允許連線。這些引數最多需要在worker配置中設定三次，一次用於管理訪問，一次用於Kafka源，一次用於Kafka匯。

從2.3.0開始，客戶端配置覆蓋可以通過使用字首producer.override.和consumer.override.分別為Kafka源或Kafka匯單獨配置每個聯結器。這些覆蓋項與聯結器的其他配置屬性一起包含在其中。

其餘的引數是聯結器的配置檔案。你可以包含任意多的配置檔案，但所有的配置檔案都會在同一個程式中執行（在不同的執行緒上）。

分散式模式處理工作的自動平衡，允許您動態地擴大（或縮小）規模，並在活動任務中以及對配置和偏移提交資料提供容錯。執行方式與單機模式非常相似。

    > bin/connect-distributed.sh config/connect-distributed.properties

 

區別在於啟動的類和配置引數，這些引數改變了Kafka Connect程式如何決定在哪裡儲存配置、如何分配工作以及在哪裡儲存偏移量和任務狀態。在分散式模式下，Kafka Connect將偏移量、配置和任務狀態儲存在Kafka主題中。建議手動建立偏移、配置和狀態的主題，以達到所需的分割槽數量和複製因子。如果在啟動Kafka Connect時還沒有建立主題，主題將以預設的分割槽數和複製因子自動建立，這可能不是最適合它的使用。

特別是，除了上面提到的常用設定外，以下配置引數是啟動叢集前必須設定的關鍵。

• group.id(預設的connect-cluster)--群集的唯一名稱，用於組建Connect群叢集組；注意不能與消費者群組ID衝突。
• config.storage.topic（預設的connect-configs）--用於儲存聯結器和任務配置的topic；請注意，這應該是一個單一分割槽、高度複製、壓縮的topic。您可能需要手動建立主題以確保正確的配置，因為自動建立的主題可能有多個分割槽或自動配置為刪除而不是壓縮
• offset.storage.topic (預設連線-offsets) - 用於儲存偏移量的topic；這個topic應該有很多分割槽，可以複製，並配置為壓實。
• status.storage.topic (預設的connect-status) - 用於儲存狀態的topic；這個topic可以有多個分割槽，並且應該被複制和配置為壓實。

請注意，在分散式模式下，聯結器配置不會在命令列中傳遞。相反，使用下面描述的REST API來建立、修改和銷燬聯結器。

 

配置聯結器

聯結器配置是簡單的鍵值對映。對於單機模式，這些配置在屬性檔案中定義，並在命令列上傳遞給Connect程式。在分散式模式下，它們將包含在建立（或修改）聯結器的請求的JSON有效載荷中。

大多數配置都是依賴於聯結器的，所以不能在這裡概述。然而，有幾個常見的選項。

• name -聯結器的唯一名稱。試圖用相同的名稱再次註冊將失敗。
• connector.class - 聯結器的Java類。
• tasks.max - 該聯結器應建立的最大任務數。如果聯結器不能達到這個級別的並行性，則可能會建立更少的任務。
• key.converter - （可選） 覆蓋worker設定的預設key轉換器。
• value.converter - (可選) 覆蓋worker設定的預設值轉換器。

connector.class配置支援以下幾種格式：該聯結器的類的全名或別名。如果聯結器是org.apache.kafka.connect.file.FileStreamSinkConnector，你可以指定這個全名，或者使用FileStreamSink或FileStreamSinkConnector來使配置更短一些。

sink connector也有一些額外的選項來控制它們的輸入。每個sink都必須設定以下內容之一。

• topics - 一個以逗號分隔的主題列表，用來作為這個聯結器的輸入。
• topics.regex - 主題的Java正規表示式，用來作為這個聯結器的輸入。

對於任何其他選項，您應該查閱聯結器的文件。

 

Transformations

聯結器可以通過轉換配置來進行輕量級的一次訊息修改。它們可以方便地進行資料群發和事件路由。

可以在聯結器配置中指定一個轉換鏈。

• transforms - 變換的別名列表，指定應用變換的順序。
• transforms.$alias.type - 變換的完全限定類名。
• transforms.$alias.$transformationSpecificConfig - 變換的配置屬性。

例如，讓我們使用內建的檔案源聯結器，並使用轉換來新增一個靜態欄位。

在整個例子中，我們將使用無模式JSON資料格式。為了使用無模式格式，我們將connect-standalone.properties中的以下兩行從true改為false。

 key.converter.schemas.enable
 value.converter.schemas.enable

檔案源聯結器將每一行作為一個字串讀取。我們將把每一行都包在一個Map中，然後新增第二個欄位來識別事件的起源。要做到這一點，我們使用兩個轉換。

• HoistField將輸入行放在Map中
• InsertField來新增靜態欄位。在這個例子中，我們將指出該記錄來自一個檔案聯結器

新增轉換後，connect-file-source.properties檔案如下。

        name=local-file-source
        connector.class=FileStreamSource
        tasks.max=1
        file=test.txt
        topic=connect-test
        transforms=MakeMap, InsertSource
        transforms.MakeMap.type=org.apache.kafka.connect.transforms.HoistField$Value
        transforms.MakeMap.field=line
        transforms.InsertSource.type=org.apache.kafka.connect.transforms.InsertField$Value
        transforms.InsertSource.static.field=data_source
        transforms.InsertSource.static.value=test-file-source

所有以transform開頭的線條都是為變換而新增的。你可以看到我們建立的兩個變換。"InsertSource "和 "MakeMap "是我們選擇給變換的別名。變換型別是基於你可以看到下面的內建變換列表。每個變換型別都有額外的配置。HoistField需要一個名為 "field "的配置，它是地圖中欄位的名稱，將包含檔案中的原始String。InsertField轉換讓我們指定欄位名和我們要新增的值。

當我們在我的示例檔案上執行沒有轉化的檔案源聯結器，然後使用kafka-console-consumer.sh讀取它們，結果是：

        "foo"
        "bar"
        "hello world"

然後，我們建立一個新的檔案聯結器，這次是在配置檔案中新增變換後。這一次，結果將是。

 

        {"line":"foo","data_source":"test-file-source"}
        {"line":"bar","data_source":"test-file-source"}
        {"line":"hello world","data_source":"test-file-source"}

你可以看到，我們已經讀取的行現在是JSON對映的一部分，並且有一個額外的欄位與我們指定的靜態值。這只是一個例子，說明你可以通過轉換來實現。

 

內建轉換

Kafka Connect中包含了一些廣泛適用的資料和路由轉換。

• InsertField - 使用靜態資料或記錄後設資料新增欄位。
• ReplaceField - 篩選或重新命名欄位
• MaskField - 用有效的空值（0，空字串等）或自定義替換（非空字串或數值）替換欄位。
• ValueToKey - 用記錄值中的欄位子集形成的新鍵替換記錄鍵。
• HoistField - 將整個事件作為一個單獨的欄位包在Struct或Map中。
• ExtractField - 從Struct和Map中提取一個特定的欄位，並在結果中只包含這個欄位。
• SetSchemaMetadata - 修改模式名稱或版本。
• TimestampRouter - 根據原始主題和時間戳修改記錄的主題。當使用需要根據時間戳寫入不同的表或索引的sink時非常有用。
• RegexRouter - 根據原始主題、替換字串和正規表示式修改記錄的主題。
• Filter - 從所有進一步的處理中刪除訊息。這與謂詞一起使用，以選擇性地過濾某些訊息。

下面列出瞭如何配置每個轉換的細節：

org.apache.kafka.connect.transforms.InsertField

 

使用記錄後設資料的屬性或配置的靜態值插入欄位。
使用為記錄鍵(org.apache.kafka.connect.transform.InsertField$Key)或值(org.apache.kafka.connect.transform.InsertField$Value)設計的具體轉換型別。

offset.field
Kafka偏移的欄位名--僅適用於sink。
字尾為 !使其成為必填欄位，或 ? 保持其為可選欄位（預設）。

型別：字串
預設值: null
有效值。
重要性：中等

 

partition.field
Kafka分割槽的欄位名。字尾為 !使其成為必填欄位，或 ? 保持其為可選欄位（預設）。

型別：字串
預設值: null
有效值。
重要性：中等

 

static.field
靜態資料欄位的欄位名。用 ! 字尾使其成為必填欄位，或用 ? 保持其為可選欄位（預設）。

型別：字串
預設值: null
有效值。
重要性：中等

 

static.value
靜態欄位值，如果配置了欄位名。

型別：字串
預設值: null
有效值。
重要性：中等

 timestamp.field

記錄時間戳的欄位名。字尾為 !使其成為必填欄位，或 ? 保持為可選欄位（預設）。

型別：字串
預設值: null
有效值。
重要性：中等

  

 topic.field

Kafka主題的欄位名。字尾為 !使其成為必填欄位，或 ? 保持為可選欄位（預設）。

型別：字串
預設值: null
有效值。
重要性：中等

org.apache.kafka.connect.transforms.ReplaceField

 

過濾或重新命名欄位。
使用為記錄鍵(org.apache.kafka.connect.transform.ReplaceField$Key)或值(org.apache.kafka.connect.transform.ReplaceField$Value)設計的具體轉換型別。

 

 

exclude
要排除的欄位。這優先於要包含的欄位。

型別：列表
預設：""
有效值。
重要性：中等

 

 

 

include
要包含的欄位。如果指定，將只使用這些欄位。

型別：列表
預設：""
有效值。
重要性：中等

 

 

 

renames
欄位重新命名對映。

型別：列表
預設：""
有效值：以冒號分隔的列表，如foo:bar,abc:xyz。
重要性：中等

 

 

 

blacklist
已不適用。使用exclude代替。

型別：列表
預設值: null
有效值。
重要性：低

 

 

 

whitelist
已廢棄。使用include代替。

型別：列表
預設值: null
有效值。
重要性：低

 

org.apache.kafka.connect.transforms.MaskField

 

用欄位型別的有效空值（如0、false、空字串等）來遮蔽指定的欄位。
對於數字和字串欄位，可以指定一個可選的替換值，該值會被轉換為正確的型別。
使用為記錄鍵（org.apache.kafka.connect.transform.MaskField$Key）或值（org.apache.kafka.connect.transform.MaskField$Value）設計的具體轉換型別。

 

 

fields
要遮蔽的欄位名稱。

型別：列表
預設值。
有效值：非空列表
重要性：高

  

 

replacement
自定義值替換，將應用於所有 "欄位 "值（僅數字或非空字串值）。

型別：字串
預設值: null
有效值：非空字串
重要性：低

 

org.apache.kafka.connect.transforms.ValueToKey

 

用記錄值中的欄位子集形成的新鍵替換記錄鍵。

 

fields
記錄值上的欄位名作為記錄鍵提取。

型別：列表
預設值。
有效值：非空列表
重要性：高

 

org.apache.kafka.connect.transforms.HoistField

 

當模式存在時，使用指定的欄位名將資料封裝在Struct中，如果是無模式資料，則使用Map。
使用為記錄鍵(org.apache.kafka.connect.transform.HoistField$Key)或值(org.apache.kafka.connect.transform.HoistField$Value)設計的具體轉換型別。

 

field
將在生成的結構或地圖中建立的單個欄位的欄位名。

型別：字串
預設值。
有效值。
重要性：中等

 

org.apache.kafka.connect.transforms.ExtractField

 

當模式存在時，從Struct中提取指定的欄位，如果是無模式資料，則從Map中提取。任何空值都會不加修改地傳遞。
使用為記錄鍵(org.apache.kafka.connect.transform.ExtractField$Key)或值(org.apache.kafka.connect.transform.ExtractField$Value)設計的具體轉換型別。

 

 

field
要提取的欄位名。

型別：字串
預設值。
有效值。
重要性：中等

 

org.apache.kafka.connect.transforms.SetSchemaMetadata

 在記錄的key(org.apache.kafka.connect.transforms.SetSchemaMetadata$Key)或value(org.apache.kafka.connect.transforms.SetSchemaMetadata$Value)模式上設定模式名稱、版本或兩者。

 

schema.name
要設定的模式名稱。

型別：字串
預設值: null
有效值。
重要性：高

 

 

 

 

schema.version
要設定的模式版本。

型別：int
預設值: null
有效值。
重要性：高

 

org.apache.kafka.connect.transforms.TimestampRouter

 

更新記錄的主題欄位，作為原始主題值和記錄時間戳的函式。
這對於sink來說主要是有用的，因為主題欄位經常被用來確定目標系統中的等價實體名稱（如資料庫表或搜尋索引名稱）。

  

 

timestamp.format
與java.text.SimpleDateFormat相容的時間戳的格式字串。

型別：字串
預設：yyyMMdd
有效值。
重要性：高

 

 

 

topic.format
格式字串，可以包含${topic}和${timestamp}，分別作為主題和時間戳的佔位符。

型別：字串
預設值：${topic}-${timestamp}。
有效值。
重要性：高

 

org.apache.kafka.connect.transforms.RegexRouter

 

使用配置的正規表示式和替換字串更新記錄主題。
在引擎蓋下，regex被編譯成java.util.regex.Pattern。如果模式與輸入的主題相匹配，java.util.regex.Matcher#replaceFirst()將與替換字串一起使用，以獲得新的主題。

 

 

regex
用於匹配的正規表示式。

型別：字串
預設值:
有效值：有效的regex
重要性：高

 

 

replacement
替換字串。

型別：字串
預設值。
有效值。
重要性：高

 

 

org.apache.kafka.connect.transforms.Flatten

 

扁平化一個巢狀的資料結構，通過在每個層次上用一個可配置的定界符連線欄位名，為每個欄位生成名稱。當存在模式時，適用於Struct，如果是無模式資料，則適用於Map。預設定界符是'.'。
使用為記錄鍵(org.apache.kafka.connect.transform.Flatten$Key)或值(org.apache.kafka.connect.transform.Flatten$Value)設計的具體轉換型別。

 

delimiter
為輸出記錄生成欄位名時，在輸入記錄的欄位名之間插入定界符。

型別：字串
預設值： 。
有效值： 。
重要性：中等

 

org.apache.kafka.connect.transforms.Cast

 

將欄位或整個鍵或值轉換為特定的型別，例如將一個整數字段強制轉換為較小的寬度。只支援簡單的基元型別--整數、浮點數、布林值和字串。
使用為記錄鍵（org.apache.kafka.connect.transform.Cast$Key）或值（org.apache.kafka.connect.transform.Cast$Value）設計的具體轉換型別。

 

 

spec
欄位列表以及要將它們投向的型別，形式為field1:type,field2:type，用於投向Maps或Structs的欄位。一個單一的型別可以投出整個值。有效的型別有int8、int16、int32、int64、float32、float64、boolean和string。

型別：list
預設值。
有效值：以冒號分隔的數字對列表，例如：foo:bar,abc:xyz。
重要性：高

 

 

org.apache.kafka.connect.transforms.TimestampConverter

 

在不同的格式之間轉換時間戳，如Unix epoch、字串和Connect Date/Timestamp型別。
使用為記錄鍵(org.apache.kafka.connect.transform.TimestampConverter$Key)或值(org.apache.kafka.connect.transform.TimestampConverter$Value)設計的具體轉換型別。

 

target.type
所需的時間戳表示方式：字串、unix、日期、時間或時間戳。

型別：字串
預設值。
有效值。
重要性：高

 

 

field
包含時間戳的欄位，如果整個值是時間戳，則為空。

型別：字串
預設：""
有效值。
重要性：高

 

format
一個與SimpleDateFormat相容的時間戳格式，當type=string時用於生成輸出，如果輸入是字串，則用於解析輸入。當type=string時用於生成輸出，如果輸入是字串，則用於解析輸入。

型別：字串
預設：""
有效值。
重要性：中等

 

 

org.apache.kafka.connect.transforms.Filter

 

丟棄所有記錄，從鏈中的後續轉換中過濾出這些記錄。這是有條件地用於過濾掉與特定謂詞匹配（或不匹配）的記錄。

 

Predicates

變換可以用謂詞來配置，以便變換隻適用於滿足某些條件的訊息。特別是，當與Filter變換相結合時，謂詞可以用來選擇性地過濾掉某些訊息。

謂詞是在聯結器配置中指定的。

• predicates - 要應用於某些轉換的謂詞的別名集。
• predicates.$alias.type - 謂詞的完全限定類名。
• predicates.$alias.$predicateSpecificConfig - 謂詞的配置屬性。

所有的轉換都有隱式的配置屬性 predicate 和 negate。通過將變換的 predicate config 設定為 predicate 的別名，可以將 predicular predicate 與變換關聯起來。謂詞的值可以使用否定配置屬性來反轉。

例如，假設你有一個源聯結器，它產生了許多不同主題的訊息，而你想："過濾掉'f'中的訊息。

• 完全過濾掉'foo'主題中的訊息。
• 將欄位名為'other_field'的ExtractField轉換應用於除主題'bar'以外的所有主題中的記錄。

要做到這一點，我們首先需要過濾掉主題 "foo "的記錄。過濾轉換將記錄從進一步的處理中移除，並且可以使用 TopicNameMatches 謂詞只將轉換應用於符合特定正規表示式的主題中的記錄。TopicNameMatches的唯一配置屬性是pattern，它是一個Java正規表示式，用於與主題名進行匹配。配置如下。

 

        transforms=Filter
        transforms.Filter.type=org.apache.kafka.connect.transforms.Filter
        transforms.Filter.predicate=IsFoo

        predicates=IsFoo
        predicates.IsFoo.type=org.apache.kafka.connect.predicates.TopicNameMatches
        predicates.IsFoo.pattern=foo

接下來我們需要只在記錄的主題名不是'bar'時應用ExtractField。我們不能直接使用 TopicNameMatches，因為那樣會將轉換應用於匹配的主題名，而不是不匹配的主題名。變換的隱式否定配置屬性允許我們反轉謂詞匹配的記錄集。在前面的例子中加入這方面的配置，我們就可以得到。

 

        transforms=Filter,Extract
        transforms.Filter.type=org.apache.kafka.connect.transforms.Filter
        transforms.Filter.predicate=IsFoo

        transforms.Extract.type=org.apache.kafka.connect.transforms.ExtractField$Key
        transforms.Extract.field=other_field
        transforms.Extract.predicate=IsBar
        transforms.Extract.negate=true

        predicates=IsFoo,IsBar
        predicates.IsFoo.type=org.apache.kafka.connect.predicates.TopicNameMatches
        predicates.IsFoo.pattern=foo

        predicates.IsBar.type=org.apache.kafka.connect.predicates.TopicNameMatches
        predicates.IsBar.pattern=bar

Kafka Connect包括以下謂詞。

TopicNameMatches - 匹配主題中具有與特定Java正規表示式匹配的名稱的記錄。
HasHeaderKey - 匹配具有給定鍵的頭的記錄。
RecordIsTombstone - 匹配墓碑記錄，即具有空值的記錄。
下面列出瞭如何配置每個謂詞的細節：

org.apache.kafka.connect.transforms.predicates.HasHeaderKey

對於至少一個帶有配置名稱的頭的記錄來說，這個前提條件為真。

 

 

name
頭部名稱。

型別：字串
預設值。
有效值：非空字串
重要性：中等

 

org.apache.kafka.connect.transforms.predicates.RecordIsTombstone

 

墓碑記錄（即有空值）的前提條件為真。

 

org.apache.kafka.connect.transforms.predicates.TopicNameMatches

 

一個謂詞，對於具有與配置的正規表示式相匹配的主題名稱的記錄，該謂詞為真。

 

pattern
一個Java正規表示式，用於與記錄的主題名稱進行匹配。

型別：字串
預設值。
有效值：非空字串，有效的regex。
重要性：中等

 

REST API

由於Kafka Connect旨在作為服務執行，它還提供了一個REST API用於管理聯結器。REST API伺服器可以使用監聽器配置選項進行配置。這個欄位應該包含一個監聽器列表，格式如下：protocol://host:port,protocol2://host2:port2。目前支援的協議有http和https。例如：http和https：

        listeners=http://localhost:8080,https://localhost:8443

 

預設情況下，如果沒有指定監聽器，REST伺服器使用HTTP協議在8083埠上執行。當使用HTTPS時，配置必須包括SSL配置。預設情況下，它將使用ssl.*設定。如果需要為REST API使用與連線Kafka經紀商不同的配置，可以用listeners.https作為欄位的字首。當使用字首時，只有字首選項會被使用，而沒有字首的ssl.*選項將被忽略。以下欄位可以用來配置REST API的HTTPS。

• ssl.keystore.location
• ssl.keystore.password
• ssl.keystore.type
• ssl.key.password
• ssl.truststore.location
• ssl.truststore.password
• ssl.truststore.type
• ssl.enabled.protocols
• ssl.provider
• ssl.protocol
• ssl.cipher.suites
• ssl.keymanager.algorithm
• ssl.secure.random.implementation
• ssl.trustmanager.algorithm
• ssl.endpoint.identification.algorithm
• ssl.client.auth

REST API不僅被使用者用來監控/管理Kafka Connect。它還用於Kafka Connect的跨叢集通訊。在跟隨節點REST API上收到的請求將被轉發到領導節點REST API。如果給定的主機可到達的URI與它監聽的URI不同，配置選項 rest.advertised.host.name、 rest.advertised.port和 rest.advertised.listener可以用來改變跟隨者節點與領導者連線的URI。當同時使用HTTP和HTTPS監聽器時，還可以使用rest.advertised.listener選項來定義哪個監聽器將用於跨叢集通訊。當使用HTTPS進行節點間通訊時，將使用相同的ssl.*或listeners.https選項來配置HTTPS客戶端。

以下是當前支援的REST API端點。

• GET /connectors - 返回活動聯結器的列表。
• POST /connectors - 建立一個新的聯結器；請求體應該是一個JSON物件，包含一個字串名稱欄位和一個包含聯結器配置引數的物件配置欄位。
• GET /connectors/{name} - 獲取特定聯結器的資訊。
• GET /connectors/{name}/config - 獲取特定聯結器的配置引數。
• PUT /connectors/{name}/config - 更新特定聯結器的配置引數。
• GET /connectors/{name}/status - 獲取聯結器的當前狀態，包括它是否正在執行、失敗、暫停等，它被分配給哪個worker，如果失敗，則獲取錯誤資訊，以及它所有任務的狀態。
• GET /connectors/{name}/tasks - 獲取一個聯結器當前執行的任務列表。
• GET /connectors/{name}/tasks/{taskid}/status - 獲取任務的當前狀態，包括是否正在執行、失敗、暫停等，分配給哪個工作者，以及失敗時的錯誤資訊。
• PUT /connectors/{name}/pause - 暫停聯結器及其任務，這將停止訊息處理，直到聯結器恢復。
• PUT /connectors/{name}/resume - 恢復已暫停的聯結器（如果聯結器沒有暫停，則不做任何事情）。
• POST /connectors/{name}/restart - 重新啟動一個聯結器（通常是因為它已經失敗了）。
• POST /connectors/{name}/tasks/{taskId}/restart - 重新啟動一個單獨的任務（通常是因為它已經失敗）。
• DELETE /connectors/{name} - 刪除一個聯結器，停止所有任務並刪除其配置。
• GET /connectors/{name}/topics - 獲取特定聯結器在建立聯結器後或發出重置其活動主題集的請求後正在使用的主題集。
• PUT /connectors/{name}/topics/reset - 傳送一個請求來清空聯結器的活動主題集。

Kafka Connect還提供了一個REST API來獲取聯結器外掛的資訊。

• GET /connector-plugins-返回Kafka Connect叢集中安裝的聯結器外掛列表。請注意，該API只檢查處理請求的worker上的聯結器，這意味著您可能會看到不一致的結果，特別是在滾動升級期間，如果您新增了新的聯結器jar的話
• PUT /connector-plugins/{connector-type}/config/validate - 根據配置定義驗證提供的配置值。該API執行每個配置驗證，在驗證過程中返回建議值和錯誤資訊。

以下是頂層（root）端點支援的REST請求。

• GET /-返回Kafka Connect叢集的基本資訊，如服務於REST請求的Connect worker的版本（包括原始碼的git commit ID）和連線到的Kafka叢集ID。 

 

連線中的錯誤報告

Kafka Connect提供了錯誤報告，以處理在處理的各個階段遇到的錯誤。預設情況下，在轉換過程中或轉換過程中遇到的任何錯誤都會導致聯結器失敗。每個聯結器配置也可以通過跳過這些錯誤來啟用容忍此類錯誤，選擇性地將每個錯誤以及失敗操作和問題記錄的細節（具有不同的細節級別）寫入Connect應用日誌。這些機制還可以在匯接器處理從其Kafka主題中消耗的訊息時捕獲錯誤，所有的錯誤都可以寫入可配置的 "死信佇列"（DLQ）Kafka主題。

要將聯結器的轉換器、變換器或匯接器本身內部的錯誤報告到日誌中，請在聯結器配置中設定 errors.log.enable=true，以記錄每個錯誤和問題記錄的主題、分割槽和偏移的詳細資訊。出於額外的除錯目的，設定 errors.log.include.messages=true，以將問題記錄的鍵、值和標題也記錄到日誌中（注意這可能會記錄敏感資訊）。

要將聯結器的轉換器、變換器或匯接器本身內部的錯誤報告給死信佇列主題，請設定 errors.deadletterqueue.topic.name，並可選 errors.deadletterqueue.context.headers.enable=true。

預設情況下，聯結器在出現錯誤或異常時，會立即表現出 "快速失敗 "行為。這相當於在聯結器配置中新增以下配置屬性及其預設值。

        # disable retries on failure
        errors.retry.timeout=0

        # do not log the error and their contexts
        errors.log.enable=false

        # do not record errors in a dead letter queue topic
        errors.deadletterqueue.topic.name=

        # Fail on first error
        errors.tolerance=none

這些和其他相關的聯結器配置屬性可以被更改以提供不同的行為。例如，可以將以下配置屬性新增到聯結器配置中，以設定具有多次重試的錯誤處理，記錄到應用程式日誌和my-connector-errors Kafka主題，並通過報告錯誤而不是失敗聯結器任務來容忍所有錯誤。

 

        # retry for at most 10 minutes times waiting up to 30 seconds between consecutive failures
        errors.retry.timeout=600000
        errors.retry.delay.max.ms=30000

        # log error context along with application logs, but do not include configs and messages
        errors.log.enable=true
        errors.log.include.messages=false

        # produce error context into the Kafka topic
        errors.deadletterqueue.topic.name=my-connector-errors

        # Tolerate all errors.
        errors.tolerance=all

8.3 聯結器開發指南

本指南介紹了開發人員如何為Kafka Connect編寫新的聯結器，以便在Kafka和其他系統之間移動資料。它簡要回顧了幾個關鍵概念，然後介紹瞭如何建立一個簡單的聯結器。

 

核心概念和API

聯結器和任務

要在Kafka和另一個系統之間複製資料，使用者要為他們要從的系統中提取資料或推送資料的系統建立一個聯結器。聯結器有兩種口味。SourceConnectors從另一個系統匯入資料（如JDBCSourceConnector將關係型資料庫匯入Kafka），SinkConnectors匯出資料（如HDFSSinkConnector將Kafka主題的內容匯出到HDFS檔案）。

聯結器本身並不執行任何資料複製：它們的配置描述了要複製的資料，而聯結器負責將該任務分解成一組可以分配給worker的Task。這些Task也有兩種相應的口味。SourceTask和SinkTask。

有了任務後，每個Task必須將它的資料子集複製到Kafka或從Kafka複製。在Kafka Connect中，應該總是可以將這些任務構架為一組由具有一致模式的記錄組成的輸入和輸出流。有時，這種對映是顯而易見的：一組日誌檔案中的每個檔案都可以被視為一個流，每個解析行都使用相同的模式和偏移量形成一個記錄，並作為位元組偏移量儲存在檔案中。在其他情況下，可能需要更多的努力來對映到這種模式：JDBC聯結器可以將每個表對映到流，但偏移量不太清楚。一種可能的對映使用時間戳列生成查詢，遞增返回新的資料，最後查詢的時間戳可以作為偏移量。

流和記錄

每個資料流應該是一個鍵值記錄的序列。鍵和值都可以有複雜的結構 -- -- 提供了許多原始型別，但也可以表示陣列、物件和巢狀資料結構。執行時資料格式不假定任何特定的序列化格式；這種轉換由框架內部處理。

除了鍵和值之外，記錄（包括那些由源產生的記錄和傳遞到sink的記錄）還有相關的流ID和偏移量。框架使用這些來定期提交已處理的資料的偏移量，以便在發生故障時，可以從最後提交的偏移量開始恢復處理，避免不必要的重新處理和重複事件。

 

動態聯結器

並非所有的任務都是靜態的，因此，Connector實現還負責監控外部系統的任何可能需要重新配置的變化。例如，在JDBCSourceConnector的例子中，Connector可能為每個Task分配一組表。當建立新表時，它必須發現這一點，以便通過更新配置將新表分配給其中一個Task。當它注意到需要重新配置的變化（或Task數量的變化）時，它就會通知框架，框架就會更新任何相應的Task。

 

開發一個簡單的聯結器

開發一個聯結器只需要實現兩個介面，即聯結器和任務。檔案包中的Kafka原始碼中包含了一個簡單的例子。這個聯結器是為了在單機模式下使用，它實現了一個SourceConnector/SourceTask，用於讀取檔案的每一行並將其作為記錄發出，以及一個SinkConnector/SinkTask，用於將每個記錄寫入檔案。

本節其餘部分將通過一些程式碼來演示建立聯結器的關鍵步驟，但開發人員還應該參考完整的示例原始碼，因為為了簡潔起見，很多細節都被省略了。

 

聯結器示例

我們將以SourceConnector作為一個簡單的例子來介紹。SinkConnector的實現非常相似。首先建立繼承自SourceConnector的類，並新增幾個欄位來儲存解析的配置資訊（要讀取的檔名和要傳送資料的主題）。

 

    public class FileStreamSourceConnector extends SourceConnector {
        private String filename;
        private String topic;

最容易填寫的方法是taskClass()，它定義了應該在worker程式中例項化的類來實際讀取資料。

 

    @Override
    public Class<? extends Task> taskClass() {
        return FileStreamSourceTask.class;
    }

下面我們將定義FileStreamSourceTask類。接下來，我們新增一些標準的生命週期方法，start()和stop()。

 

    @Override
    public void start(Map<String, String> props) {
        // The complete version includes error handling as well.
        filename = props.get(FILE_CONFIG);
        topic = props.get(TOPIC_CONFIG);
    }

    @Override
    public void stop() {
        // Nothing to do since no background monitoring is required.
    }

最後，真正的實現核心是在 taskConfigs()中。在這種情況下，我們只處理一個檔案，所以即使我們可能被允許根據maxTasks引數生成更多的任務，但我們返回的列表只有一個條目。

 

    @Override
    public List<Map<String, String>> taskConfigs(int maxTasks) {
        ArrayList<Map<String, String>> configs = new ArrayList<>();
        // Only one input stream makes sense.
        Map<String, String> config = new HashMap<>();
        if (filename != null)
            config.put(FILE_CONFIG, filename);
        config.put(TOPIC_CONFIG, topic);
        configs.add(config);
        return configs;
    }

雖然在示例中沒有使用，但SourceTask還提供了兩個API來提交源系統中的偏移量：commit和commitRecord。這些API是為具有訊息確認機制的源系統提供的。過載這些方法可以讓源聯結器在源系統中確認訊息，無論是批量還是單獨的，一旦它們被寫入Kafka。提交API會在源系統中儲存偏移量，最多是poll返回的偏移量。這個API的實現應該阻塞，直到提交完成。commitRecord API將每個SourceRecord寫入Kafka後，會在源系統中儲存偏移量。由於Kafka Connect會自動記錄偏移量，所以不需要SourceTasks來實現。在聯結器確實需要在源系統中確認訊息的情況下，通常只需要實現其中一個API。

即使有多個任務，這個方法的實現通常也很簡單。它只需要確定輸入任務的數量，可能需要聯絡它要拉取資料的遠端服務，然後將它們分工。因為一些任務之間分工的模式非常常見，所以在ConnectorUtils中提供了一些實用程式來簡化這些情況。

請注意，這個簡單的例子不包括動態輸入。關於如何觸發任務配置的更新，請參閱下一節的討論。

任務示例 - 源任務

接下來我們將介紹相應的SourceTask的實現。這個實現很短，但太長了，在本指南中無法完全介紹。我們將使用虛擬碼來描述大部分的實現，但你可以參考原始碼來了解完整的例子。

就像聯結器一樣，我們需要建立一個繼承自相應基礎Task類的類。它也有一些標準的生命週期方法。

    public class FileStreamSourceTask extends SourceTask {
        String filename;
        InputStream stream;
        String topic;

        @Override
        public void start(Map<String, String> props) {
            filename = props.get(FileStreamSourceConnector.FILE_CONFIG);
            stream = openOrThrowError(filename);
            topic = props.get(FileStreamSourceConnector.TOPIC_CONFIG);
        }

        @Override
        public synchronized void stop() {
            stream.close();
        }

這些都是略微簡化的版本，但表明這些方法應該是比較簡單的，它們應該執行的唯一工作就是分配或釋放資源。關於這個實現有兩點需要注意。首先，start()方法還不能處理從以前的偏移量恢復，這將在後面的章節中解決。第二，stop()方法是同步的。這將是必要的，因為SourceTasks被賦予了一個專門的執行緒，它們可以無限期地阻塞，所以需要用Worker中不同執行緒的呼叫來停止它們。

接下來，我們實現任務的主要功能--poll()方法，它從輸入系統中獲取事件並返回一個List<SourceRecord>。

    @Override
    public List<SourceRecord> poll() throws InterruptedException {
        try {
            ArrayList<SourceRecord> records = new ArrayList<>();
            while (streamValid(stream) && records.isEmpty()) {
                LineAndOffset line = readToNextLine(stream);
                if (line != null) {
                    Map<String, Object> sourcePartition = Collections.singletonMap("filename", filename);
                    Map<String, Object> sourceOffset = Collections.singletonMap("position", streamOffset);
                    records.add(new SourceRecord(sourcePartition, sourceOffset, topic, Schema.STRING_SCHEMA, line));
                } else {
                    Thread.sleep(1);
                }
            }
            return records;
        } catch (IOException e) {
            // Underlying stream was killed, probably as a result of calling stop. Allow to return
            // null, and driving thread will handle any shutdown if necessary.
        }
        return null;
    }

同樣，我們省略了一些細節，但我們可以看到重要的步驟：poll()方法會被反覆呼叫，對於每一次呼叫，它都會迴圈嘗試從檔案中讀取記錄。對於它讀取的每一行，它也會跟蹤檔案的偏移量。它使用這些資訊來建立一個輸出的SourceRecord，其中包含四條資訊：源分割槽（只有一個，就是被讀取的單個檔案）、源偏移量（檔案中的位元組偏移量）、輸出主題名和輸出值（行，我們包含一個模式，表明這個值將永遠是一個字串）。SourceRecord建構函式的其他變體也可以包括一個特定的輸出分割槽、一個鍵和標題。

請注意，這個實現使用正常的Java InputStream介面，如果資料不可用，可能會睡眠。這是可以接受的，因為Kafka Connect為每個任務提供了一個專用執行緒。雖然任務實現必須符合基本的poll()介面，但它們在如何實現方面有很大的靈活性。在這種情況下，基於NIO的實現會更有效，但這種簡單的方法是可行的，實現速度快，而且相容舊版本的Java。

 

Sink任務

上一節介紹瞭如何實現一個簡單的SourceTask。與SourceConnector和SinkConnector不同的是，SourceTask和SinkTask的介面非常不同，因為SourceTask使用的是拉介面，而SinkTask使用的是推介面。兩者共享共同的生命週期方法，但SinkTask介面卻截然不同。

 

    public abstract class SinkTask implements Task {
        public void initialize(SinkTaskContext context) {
            this.context = context;
        }

        public abstract void put(Collection<SinkRecord> records);

        public void flush(Map<TopicPartition, OffsetAndMetadata> currentOffsets) {
        }

SinkTask文件包含了完整的細節，但這個介面幾乎和SourceTask一樣簡單。put()方法應該包含大部分的實現，接受SinkRecords的集合，執行任何所需的翻譯，並將它們儲存在目標系統中。這個方法不需要在返回之前確保資料已經完全寫入目的系統。事實上，在許多情況下，內部緩衝將是有用的，因此可以一次傳送整批記錄，減少將事件插入下游資料儲存的開銷。SinkRecords包含的資訊與SourceRecords基本相同。Kafka主題，分割槽，偏移，事件的鍵和值，以及可選的頭資訊。

flush()方法在偏移提交過程中使用，它允許任務從失敗中恢復，並從安全點恢復，這樣就不會錯過任何事件。該方法應該將任何未完成的資料推送到目標系統，然後阻塞，直到寫入被確認。offsets引數通常可以被忽略，但在某些情況下是有用的，在這些情況下，實現者希望在目標儲存中儲存偏移資訊，以提供精確的一次交付。例如，HDFS聯結器可以做到這一點，並使用原子移動操作來確保flush()操作原子地將資料和偏移量提交到HDFS中的最終位置。

錯誤記錄報告器

當為聯結器啟用錯誤報告時，聯結器可以使用ErrantRecordReporter來報告傳送到sink聯結器的單個記錄的問題。下面的示例顯示了聯結器的SinkTask子類如何獲取和使用ErrantRecordReporter，當DLQ未啟用或聯結器安裝在沒有此報告功能的舊Connect執行時，安全地處理一個空報告。

 

        private ErrantRecordReporter reporter;

        @Override
        public void start(Map<String, String> props) {
            ...
            try {
                reporter = context.errantRecordReporter(); // may be null if DLQ not enabled
            } catch (NoSuchMethodException | NoClassDefFoundError e) {
                // Will occur in Connect runtimes earlier than 2.6
                reporter = null;
            }
        }

        @Override
        public void put(Collection<SinkRecord> records) {
            for (SinkRecord record: records) {
                try {
                    // attempt to process and send record to data sink
                    process(record);
                } catch(Exception e) {
                    if (reporter != null) {
                        // Send errant record to error reporter
                        reporter.report(record, e);
                    } else {
                        // There's no error reporter, so fail
                        throw new ConnectException("Failed on record", e);
                    }
                }
            }
        }

從以前的偏移量恢復

SourceTask的實現包括一個流ID（輸入檔名）和偏移量（在檔案中的位置）與每個記錄。框架使用這個來定期提交偏移量，這樣在失敗的情況下，任務可以恢復並儘量減少被重新處理和可能重複的事件數量（或者從最近的偏移量恢復，如果Kafka Connect被優雅地停止，例如在獨立模式下或由於作業重新配置）。這個提交過程完全由框架自動完成，但只有聯結器知道如何在輸入流中尋找回正確的位置，從該位置恢復。

為了在啟動時正確地恢復，任務可以使用傳遞到其initialize()方法中的SourceContext來訪問偏移資料。在initialize()中，我們將新增更多的程式碼來讀取偏移量(如果存在的話)並尋求到該位置。

        stream = new FileInputStream(filename);
        Map<String, Object> offset = context.offsetStorageReader().offset(Collections.singletonMap(FILENAME_FIELD, filename));
        if (offset != null) {
            Long lastRecordedOffset = (Long) offset.get("position");
            if (lastRecordedOffset != null)
                seekToOffset(stream, lastRecordedOffset);
        }
    

當然，你可能需要為每個輸入流讀取許多鍵。OffsetStorageReader介面還允許您發出批量讀取，以有效地載入所有偏移量，然後通過尋找每個輸入流到適當的位置來應用它們。

 

動態輸入/輸出流

Kafka Connect旨在定義批量資料複製作業，例如複製整個資料庫，而不是建立許多作業來單獨複製每個表。這種設計的一個後果是，一個聯結器的輸入或輸出流的集合可以隨著時間的推移而變化。

源聯結器需要監控源系統的變化，例如資料庫中表的新增/刪除。當它們接收到變化時，應該通過ConnectorContext物件通知框架需要重新配置。例如，在一個SourceConnector:

        if (inputsChanged())
            this.context.requestTaskReconfiguration();

框架會及時請求新的配置資訊並更新任務，讓它們在重新配置之前優雅地提交它們的進度。需要注意的是，在SourceConnector中，這種監控目前是由聯結器實現來完成的。如果需要一個額外的執行緒來執行這個監控，聯結器必須自己分配它。

理想情況下，這種監控變化的程式碼將被隔離在聯結器中，任務不需要擔心這些變化。然而，變化也會影響到任務，最常見的是當它們的一個輸入流在輸入系統中被破壞時，例如，如果一個表從資料庫中被丟棄。如果Task在Connector之前遇到了這個問題，如果Connector需要輪詢變化，這將是常見的，那麼Task將需要處理後續的錯誤。值得慶幸的是，這通常可以簡單地通過捕獲和處理適當的異常來處理。

SinkConnectors通常只需要處理流的新增，這可能轉化為其輸出中的新條目（例如，一個新的資料庫表）。該框架管理Kafka輸入的任何變化，例如當輸入主題集因regex訂閱而改變時。SinkTasks應該期待新的輸入流，這可能需要在下游系統中建立新的資源，例如資料庫中的新表。在這些情況下，最棘手的處理情況可能是多個SinkTasks第一次看到新的輸入流並同時試圖建立新資源之間的衝突。另一方面，SinkConnectors一般不需要特別的程式碼來處理一組動態的流。

連線配置驗證

Kafka Connect允許您在提交聯結器執行之前驗證聯結器配置，並且可以提供有關錯誤和推薦值的反饋。為了利用這一點，聯結器開發者需要提供config()的實現，將配置定義暴露給框架。

FileStreamSourceConnector中的以下程式碼定義了配置並將其暴露給框架。

        private static final ConfigDef CONFIG_DEF = new ConfigDef()
            .define(FILE_CONFIG, Type.STRING, Importance.HIGH, "Source filename.")
            .define(TOPIC_CONFIG, Type.STRING, Importance.HIGH, "The topic to publish data to");

        public ConfigDef config() {
            return CONFIG_DEF;
        }

ConfigDef類用於指定預期配置的集合。對於每個配置，你可以指定名稱、型別、預設值、文件、組資訊、組中的順序、配置值的寬度和適合在UI中顯示的名稱。另外，你還可以通過覆蓋Validator類，提供用於單個配置驗證的特殊驗證邏輯。此外，由於配置之間可能存在依賴關係，例如，一個配置的有效值和可見性可能會根據其他配置的值而改變。為了處理這個問題，ConfigDef允許你指定配置的依賴關係，並提供一個Recommender的實現來獲取配置的有效值，並在當前配置值的基礎上設定配置的可見性。

另外，Connector中的validate()方法提供了一個預設的驗證實現，它返回一個允許的配置列表，以及每個配置的配置錯誤和推薦值。但是，它並沒有使用推薦值進行配置驗證。您可以為自定義配置驗證提供預設實現的重寫，它可以使用推薦值。

 

使用模式

FileStream聯結器是一個很好的例子，因為它們很簡單，但它們也有微不足道的結構化資料--每一行只是一個字串。幾乎所有實用的聯結器都需要具有更復雜資料格式的模式。

要建立更復雜的資料，你需要使用Kafka Connect資料API。大多數結構化記錄除了原始型別外，還需要與兩個類進行互動。Schema和Struct。

API文件提供了一個完整的參考，但這裡是一個建立Schema和Struct的簡單例子。

    Schema schema = SchemaBuilder.struct().name(NAME)
        .field("name", Schema.STRING_SCHEMA)
        .field("age", Schema.INT_SCHEMA)
        .field("admin", SchemaBuilder.bool().defaultValue(false).build())
        .build();

    Struct struct = new Struct(schema)
        .put("name", "Barbara Liskov")
        .put("age", 75);

如果你正在實現一個源聯結器，你需要決定何時以及如何建立模式。在可能的情況下，你應該儘可能地避免重新計算它們。例如，如果你的聯結器保證有一個固定的模式，就靜態地建立它，並重用一個例項。

然而，許多聯結器將具有動態模式。一個簡單的例子是資料庫聯結器。考慮到即使只是一張表，整個聯結器的模式也不會是預定義的（因為它因表而異）。但在聯結器的生命週期內，它也可能不會固定在一張表上，因為使用者可能會執行ALTER TABLE命令。聯結器必須能夠檢測到這些變化並做出適當的反應。

匯接器通常比較簡單，因為它們正在消耗資料，因此不需要建立模式。然而，它們應該同樣小心地驗證它們接收的模式是否具有預期的格式。當模式不匹配時 -- -- 通常表明上游生產者正在生成無法正確翻譯到目的系統的無效資料 -- -- 水槽聯結器應該丟擲一個異常，向系統指出這個錯誤。

Kafka連線管理

Kafka Connect的REST層提供了一組API來實現叢集的管理。這包括用於檢視聯結器的配置和其任務的狀態，以及改變其當前行為（例如更改配置和重新啟動任務）的API。

當一個聯結器首次提交到叢集時，Connect工作者之間會觸發重新平衡，以便分配由新聯結器的任務組成的負載。當聯結器增加或減少其所需的任務數量時，當聯結器的配置發生變化時，或者當作為Connect叢集有意升級的一部分或由於故障而從組中新增或刪除工作者時，也會使用這種相同的再平衡過程。

在 2.3.0 之前的版本中，Connect 工作者會重新平衡群集中的全部聯結器及其任務，以此作為一種簡單的方式，確保每個工作者的工作量大致相同。這個行為仍然可以通過設定connect.protocol=eager來啟用。

從2.3.0開始，Kafka Connect預設使用的協議是執行增量合作再平衡，增量地平衡Connect worker中的聯結器和任務，隻影響新的、要刪除的或需要從一個worker轉移到另一個worker的任務。在重新平衡期間，其他任務不會像舊協議那樣被停止和重新啟動。

如果 Connect 工人有意或因故障離開組，Connect 會在觸發重新平衡之前等待 scheduled.rebalance.max.delay.ms。該延遲預設為五分鐘(300000ms)，以容忍工人的故障或升級，而不會立即重新分配離開工人的負載。如果這個工人在配置的延遲內返回，它將獲得之前分配的全部任務。但是，這意味著在 scheduled.rebalance.max.delay.ms 指定的時間過去之前，任務將保持未分配。如果某個工作者沒有在該時間限制內返回，Connect 將在 Connect 叢集中的剩餘工作者之間重新分配這些任務。

當組成 Connect 群集的所有 Worker 都被配置為 connect.protocol=compatible 時，新的 Connect 協議就會被啟用，當該屬性缺失時，它也是預設值。因此，當所有工作者升級到 2.3.0 時，會自動升級到新的 Connect 協議。當最後一個工作者加入2.3.0版本時，Connect叢集的滾動升級將啟用增量合作再平衡。

您可以使用 REST API 來檢視聯結器及其任務的當前狀態，包括每個聯結器被分配到的工作者的 ID。例如，GET /connectors/file-source/status請求顯示名為file-source的聯結器的狀態：

    {
    "name": "file-source",
    "connector": {
        "state": "RUNNING",
        "worker_id": "192.168.1.208:8083"
    },
    "tasks": [
        {
        "id": 0,
        "state": "RUNNING",
        "worker_id": "192.168.1.209:8083"
        }
    ]
    }

聯結器及其任務將狀態更新發布到一個共享主題（用status.storage.topic配置），叢集中的所有工作者都會監控這個主題。由於工作者非同步地消耗這個主題，因此在通過狀態API看到狀態變化之前通常會有一個（短暫的）延遲。聯結器或其任務之一可能有以下狀態。

• UNASSIGNED。該聯結器/任務尚未分配給工人。
• RUNNING：聯結器/任務正在執行。
• PAUSED（暫停）：該聯結器/任務已被管理。該聯結器/任務在管理上已被暫停。
• FAILED：聯結器/任務已經失敗。聯結器/任務失敗了（通常通過引發異常，並在狀態輸出中報告）。
• DESTROYED：聯結器/任務在管理上已經暫停。該聯結器/任務已被管理刪除，並將停止出現在Connect叢集中。

在大多數情況下，聯結器和任務狀態將匹配，儘管在發生變化或任務失敗時，它們可能會在短時間內有所不同。例如，當聯結器首次啟動時，在聯結器及其任務全部過渡到RUNNING狀態之前，可能會有一個明顯的延遲。由於Connect不會自動重啟失敗的任務，因此在任務失敗時，狀態也會出現分歧。要手動重啟聯結器/任務，您可以使用上面列出的重啟 API。請注意，如果您試圖在重新平衡進行時重新啟動任務，Connect 將返回 409（衝突）狀態程式碼。您可以在重新平衡完成後重試，但可能沒有必要，因為重新平衡會有效地重新啟動叢集中的所有聯結器和任務。

從2.5.0開始，Kafka Connect使用status.storage.topic也儲存與每個聯結器正在使用的主題相關的資訊。Connect Workers使用這些每個聯結器的主題狀態更新來響應對REST端點GET /connectors/{name}/topics的請求，返回聯結器正在使用的主題名稱集。向REST端點PUT /connectors/{name}/topics/reset發出的請求會重置聯結器的活動主題集，並允許根據聯結器最新的主題使用模式填充新的主題集。當聯結器被刪除時，聯結器的活動主題集也會被刪除。話題跟蹤預設是啟用的，但可以通過設定topic.tracking.enable=false來禁用。如果您想在執行時禁止請求重置聯結器的活動主題，請設定Worker屬性topic.tracking.allow.reset=false。

有時，暫時停止聯結器的訊息處理很有用。例如，如果遠端系統正在進行維護，那麼源聯結器最好停止對其進行新資料的輪詢，而不是用異常垃圾資訊填充日誌。對於這種用例，Connect提供了一個暫停/恢復API。當源聯結器被暫停時，Connect將停止對其進行額外記錄的輪詢。當sink聯結器暫停時，Connect將停止向其推送新訊息。暫停狀態是持久的，因此即使您重新啟動群集，聯結器也不會再次開始訊息處理，直到任務被恢復。請注意，在聯結器的所有任務過渡到paused狀態之前，可能會有一個延遲，因為它們可能需要時間來完成它們在被暫停時正在進行的任何處理。此外，失敗的任務在重新啟動之前不會過渡到PAUSED狀態。

9. KAFKA STREAMS

Kafka Streams是一個用於處理和分析儲存在Kafka中的資料的客戶端庫。它建立在重要的流處理概念之上，如正確區分事件時間和處理時間、視窗支援、精確的一次性處理語義和簡單而高效的應用狀態管理。

Kafka Streams的入門門檻很低。你可以在一臺機器上快速編寫和執行一個小規模的概念驗證；你只需要在多臺機器上執行你的應用的額外例項，就可以擴充套件到大批量的生產工作負載。Kafka Streams通過利用Kafka的並行模型透明地處理同一應用的多個例項的負載平衡。

 

瞭解更多關於Kafka流的資訊請閱讀下一篇文章。