kafka官網翻譯一：簡介與用例及安裝手冊

1.入門

1.1簡介

ApacheKafka®是一個分佈式流媒體平臺。這到底是什麼意思？

我們認爲流媒體平臺具有三個關鍵功能：

1. 它可以讓你發佈和訂閱記錄流。在這方面，它類似於消​​息隊列或企業消息傳遞系統。
2. 它允許您以容錯方式存儲記錄流。
3. 它可以讓您在發生記錄時處理記錄流。

什麼是卡夫卡好？

它被用於兩大類的應用程序：

1. 構建可在系統或應用程序之間可靠獲取數據的實時流數據管道
2. 構建實時流應用程序，可以轉換或響應數據流

要了解卡夫卡如何做這些事情，讓我們深入探索卡夫卡的能力。

首先幾個概念：

• Kafka作爲一個或多個服務器上的集羣運行。
• Kafka集羣以稱爲主題的類別存儲記錄流。
• 每個記錄由一個鍵，一個值和一個時間戳組成。

卡夫卡有四個核心API：

• 該製片API允許應用程序發佈的記錄流至一個或多個卡夫卡的話題。
• 該消費者API允許應用程序訂閱一個或多個主題，並處理所產生的對他們記錄的數據流。
• 所述流API允許應用程序充當流處理器，從一個或多個主題消耗的輸入流，併產生一個輸出流至一個或多個輸出的主題，有效地變換所述輸入流，以輸出流。
• 該連接器API允許構建和運行卡夫卡主題連接到現有的應用程序或數據系統中重用生產者或消費者。例如，連接到關係數據庫的連接器可能會捕獲對錶的每個更改。

 

在Kafka中，客戶端和服務器之間的通信是通過一個簡單的，高性能的，與語言無關的TCP協議完成的。這個協議是版本化的，並保持與舊版本的向後兼容性。我們爲Kafka提供了一個Java客戶端，但客戶端可以使用多種語言。

主題和日誌

讓我們首先深入核心抽象Kafka提供了一個記錄流 - 主題。

主題是記錄發佈到的類別或飼料名稱。卡夫卡的話題總是多用戶的; 也就是說，一個主題可以有零個，一個或多個訂閱寫入數據的消費者。

對於每個主題，Kafka集羣維護一個分區日誌，如下所示：

 

每個分區是一個有序的，不可變的記錄序列，不斷追加到結構化的提交日誌中。分區中的記錄每個分配一個連續的id號，稱爲偏移量，用於唯一標識分區內的每條記錄。

Kafka集羣使用可配置的保留期限來保留所有已發佈的記錄（無論是否已被使用）。例如，如果保留策略設置爲兩天，則在記錄發佈後的兩天內，保留策略可供使用，之後將被丟棄以騰出空間。卡夫卡的性能在數據大小方面是有效的，所以長時間存儲數據不成問題。

 

實際上，以消費者爲單位保留的唯一元數據是消費者在日誌中的偏移或位置。這個偏移量是由消費者控制的：消費者通常會在讀取記錄時線性地推進其偏移量，但事實上，由於消費者的位置是由消費者控制的，所以它可以以任何喜歡的順序消費記錄。例如，消費者可以重置爲較舊的偏移量以重新處理來自過去的數據，或者跳至最近的記錄並從“now”開始消費。

這些功能的組合意味着卡夫卡的消費者非常便宜 - 他們可以來來去去，對集羣或其他消費者沒有太大的影響。例如，您可以使用我們的命令行工具來“尾巴”任何主題的內容，而不會改變現有的使用者所使用的內容。

日誌中的分區有幾個用途。首先，它們允許日誌的大小超出適合單個服務器的大小。每個單獨的分區必須適合託管它的服務器，但是一個主題可能有許多分區，因此它可以處理任意數量的數據。其次，它們作爲並行的單位 - 更多的是在一點上。

分配

日誌的分區分佈在Kafka集羣中的服務器上，每個服務器處理數據並請求共享分區。每個分區都通過可配置數量的服務器進行復制，以實現容錯。

每個分區有一個服務器充當“領導者”，零個或多個服務器充當“追隨者”。領導處理分區的所有讀取和寫入請求，而追隨者被動地複製領導。如果領導失敗，其中一個追隨者將自動成爲新領導。每個服務器充當其中一些分區的領導者和其他人的追隨者，因此負載在集羣內平衡良好。

生產者

生產者發佈數據到他們選擇的主題。生產者負責選擇哪個記錄分配給主題內的哪個分區。這可以以循環的方式完成，只是爲了平衡負載，或者可以根據某些語義分區功能（例如基於記錄中的某個鍵）來完成。更多關於使用分區在第二！

消費者

消費者用消費者組名稱標記自己，並且發佈到主題的每個記錄被傳遞到每個訂閱消費者組中的一個消費者實例。消費者實例可以在不同的進程中或在不同的機器上。

如果所有消費者實例具有相同的消費者組，則記錄將有效地在消費者實例上負載平衡。

如果所有消費者實例具有不同的消費者組，則每個記錄將被廣播給所有消費者進程。

 

兩個服務器Kafka集羣託管四個分區（P0-P3）與兩個消費者組。消費者組A有兩個消費者實例，而組B有四個消費者實例。

然而，更普遍的是，我們發現話題中有少量消費羣體，每個“邏輯用戶”都有一個消費羣體。每個組由許多消費者實例組成，具有可擴展性和容錯性。這不過是發佈 - 訂閱語義，訂閱者是一羣消費者而不是一個進程。

在Kafka中實現消費的方式是將日誌中的分區劃分爲消費者實例，以便每個實例在任何時間點都是“公平分享”分區的唯一消費者。這個維護組中成員資格的過程是由Kafka協議動態地處理的。如果新實例加入組，他們將接管來自組中其他成員的一些分區; 如果一個實例死亡，其分區將分配給其餘的實例。

卡夫卡只提供一個分區內的記錄總數，而不是主題中的不同分區之間。每個分區排序與按鍵分區數據的能力相結合，足以滿足大多數應用程序的需求。但是，如果您需要全部訂單而不是記錄，則可以通過僅具有一個分區的主題來實現，但這意味着每個消費者組只有一個消費者進程。

擔保

在一個高層次的卡夫卡提供以下保證：

• 由製作者發送到特定主題分區的消息將按照它們發送的順序附加。也就是說，如果記錄M1由同一個生產者作爲記錄M2被髮送，並且M1被首先發送，則M1將具有比M2更低的偏移並且出現在日誌中較早的地方。
• 消費者實例按照存儲在日誌中的順序查看記錄。
• 對於具有複製因子N的主題，我們將容忍多達N-1個服務器故障，而不會丟失任何提交給日誌的記錄。

有關這些保證的更多細節在文檔的設計部分給出。

卡夫卡作爲消息系統

卡夫卡的流概念如何與傳統的企業消息傳遞系統相比較？

消息傳統上有兩種模式：排隊和發佈 - 訂閱。在隊列中，消費者池可以從服務器讀取並且每個記錄都轉到其中的一個; 在發佈 - 訂閱記錄被廣播給所有消費者。這兩種模式都有其優點和缺點。排隊的優勢在於，它允許您將數據處理劃分爲多個消費者實例，這樣可以擴展您的處理。不幸的是，隊列不是多用戶的，一旦一個進程讀取了數據，發佈 - 訂閱允許您將數據廣播到多個進程，但無法進行擴展處理，因爲每條消息都發送給每個訂閱者。

卡夫卡的消費羣體概念概括了這兩個概念。與隊列一樣，消費者組允許您將一系列流程（消費者組的成員）的處理分開。與發佈 - 訂閱一樣，Kafka允許您向多個消費者羣體廣播消息。

Kafka模型的優點是每個主題都具有這些屬性 - 它可以擴展處理，也可以是多用戶 - 不需要選擇其中一個。

Kafka也比傳統的消息系統有更強的訂單保證。

傳統隊列在服務器上按順序保留記錄，並且如果多個使用者從隊列中消耗，則服務器按照存儲的順序提交記錄。然而，雖然服務器按順序提交記錄，但是記錄是異步傳送給消費者的，所以它們可能會在不同的消費者中出現。這實際上意味着記錄的排序在並行消耗的情況下丟失。消息傳遞系統通常具有“排他消費者”的概念，只允許一個進程從隊列中消費，但這當然意味着在處理過程中沒有並行性。

卡夫卡做得更好。通過在主題內部具有並行的概念 - 分區，Kafka能夠提供訂單保證和對消費者流程池的負載平衡。這是通過將主題中的分區分配給使用者組中的使用者來實現的，以便每個分區僅由組中的一個使用者使用。通過這樣做，我們確保消費者是該分區的唯一讀者，並按順序使用這些數據。由於有很多分區，這仍然可以平衡許多消費者實例的負載。但請注意，消費羣組中的消費者實例不能多於分區。

卡夫卡作爲存儲系統

任何允許將消息發佈出去的消息隊列都可以充當存儲系統。Kafka的不同之處在於它是一個非常好的存儲系統。

寫入Kafka的數據寫入磁盤並進行復制以實現容錯。Kafka允許生產者等待確認，以便在完全複製之前寫入不被認爲是完整的，並且即使寫入的服務器失敗也能保證持續。

Kafka的磁盤結構使用了很好的規模 - 無論您在服務器上有50 KB還是50 TB的持久性數據，Kafka都會執行相同的操作。

由於認真考慮存儲並允許客戶端控制其讀取位置，所以可以將Kafka視爲專用於高性能，低延遲提交日誌存儲，複製和傳播的專用分佈式文件系統。

有關Kafka提交日誌存儲和複製設計的詳細信息，請閱讀此頁。

卡夫卡流處理

只讀取，寫入和存儲數據流是不夠的，目的是啓用流的實時處理。

在Kafka中，流處理器是指從輸入主題獲取連續數據流，對該輸入執行一些處理，併產生連續數據流以輸出主題的任何東西。

例如，零售應用程序可能會接受輸入的銷售和貨運流，並輸出一系列重新排序和對這些數據進行計算的價格調整。

直接使用生產者和消費者API可以做簡單的處理。但是對於更復雜的轉換，Kafka提供了一個完全集成的Streams API。這允許構建應用程序進行非平凡的處理，從而計算聚合關閉流或將流連接在一起。

這個工具有助於解決這類應用程序面臨的難題：處理亂序數據，重新處理代碼更改的輸入，執行有狀態的計算等等。

流API基於Kafka提供的核心原語構建：它使用生產者和消費者API進行輸入，使用Kafka進行有狀態存儲，並在流處理器實例之間使用相同的組機制來實現容錯。

放在一起

消息傳遞，存儲和流處理的這種組合看起來很不尋常，但對於Kafka作爲一個流媒體平臺來說，這是非常重要的。

像HDFS這樣的分佈式文件系統允許存儲用於批處理的靜態文件。有效地，這樣的系統允許存儲和處理過去的歷史數據。

傳統的企業消息傳遞系統允許處理將來訂閱的消息。以這種方式構建的應用程序在到達時處理將來的數據。

Kafka結合了這兩種功能，而且這兩種組合對於Kafka用作流媒體應用平臺和流式數據流水線都是至關重要的。

通過將存儲和低延遲訂閱相結合，流式應用程序可以同樣的方式處理過去和未來的數據。這是一個單一的應用程序可以處理歷史，存儲的數據，而不是結束，當它達到最後一個記錄，它可以繼續處理未來的數據到達。這是流處理的概括概念，包括批處理以及消息驅動的應用程序。

同樣，對於流式傳輸數據流水線，訂閱實時事件的組合使得可以將Kafka用於非常低延遲的流水線; 但是可靠地存儲數據的能力可以將其用於必須保證數據交付的關鍵數據，或者與只能定期加載數據的離線系統集成，或者可能長時間停機進行維護。流處理設施可以在數據到達時進行轉換。

有關Kafka提供的擔保，API和功能的更多信息，請參閱文檔的其餘部分。

1.2用例

下面是一些ApacheKafka®流行用例的描述。有關這些領域的概述，請參閱此博客文章。

消息

卡夫卡可以很好地替代傳統的信息經紀人。消息代理被用於各種原因（將數據處理與數據生成器分離，緩衝未處理的消息等）。與大多數消息傳遞系統相比，Kafka具有更好的吞吐量，內置的分區，複製和容錯功能，使其成爲大型消息處理應用程序的理想解決方案。

根據我們的經驗，消息傳遞的使用往往是相對較低的吞吐量，但可能需要較低的端到端延遲，並且通常取決於Kafka提供的強大的持久性保證。

在這個領域，Kafka與傳統的消息系統（如ActiveMQ或 RabbitMQ）相當。

網站活動跟蹤

Kafka的原始用例是能夠將用戶活動跟蹤管道重建爲一組實時發佈 - 訂閱訂閱源。這意味着網站活動（用戶可能採用的網頁瀏覽量，搜索或其他操作）將發佈到每個活動類型一個主題的中心主題。這些訂閱源可用於訂閱各種用例，包括實時處理，實時監控，加載到Hadoop或離線數據倉庫系統以進行離線處理和報告。

活動跟蹤通常是非常高的量，因爲爲每個用戶頁面視圖生成許多活動消息。

度量

卡夫卡通常用於運行監控數據。這涉及從分佈式應用程序彙總統計數據以生成操作數據的集中式源。

日誌聚合

許多人使用Kafka作爲日誌聚合解決方案的替代品。日誌聚合通常從服務器收集物理日誌文件，並將其置於中央位置（可能是文件服務器或HDFS）進行處理。Kafka提取文件的細節，並將日誌或事件數據作爲消息流進行更清晰的抽象。這樣可以實現更低延遲的處理，並且更容易支持多個數據源和分佈式數據消耗。與Scribe或Flume等以日誌爲中心的系統相比，Kafka提供同樣出色的性能，由複製產生的更強大的持久性保證以及更低的端到端延遲。

流處理

Kafka的許多用戶在處理管道中處理數據，這些數據由多個階段組成，其中原始輸入數據從Kafka主題中消耗，然後聚合，豐富或以其他方式轉化爲新的主題，以供進一步消費或後續處理。例如，用於推薦新聞文章的處理流水線可以從RSS提要抓取文章內容並將其發佈到“文章”主題; 進一步的處理可以對這個內容進行標準化或者重複刪除，並且將已清理的文章內容發佈到新的主題; 信讀亦讀信息範範信息亦讀信息範範信息中信息 這種處理流水線基於各個主題創建實時數據流的圖表。從0.10.0.0開始，這是一個輕量但功能強大的流處理庫，稱爲Kafka Streams 在Apache Kafka中可用於執行如上所述的數據處理。除了Kafka Streams之外，替代性的開源流處理工具還包括Apache Storm和 Apache Samza。

事件採購

事件源是應用程序設計的一種風格，其中狀態更改以時間排序的記錄序列進行記錄。Kafka對非常大的存儲日誌數據的支持使得它成爲以這種風格構建的應用程序的優秀後端。

提交日誌

Kafka可以作爲分佈式系統的一種外部提交日誌。日誌有助於複製節點之間的數據，並作爲失敗節點恢復數據的重新同步機制。Kafka中的日誌壓縮功能有助於支持這種用法。在這個用法中，Kafka與Apache BookKeeper項目類似。

1.3快速入門

本教程假定您開始新鮮，沒有現有的Kafka或ZooKeeper數據。由於基於Unix和Windows平臺的Kafka控制檯腳本不同，因此在Windows平臺上使用bin\windows\而不是bin/，並將腳本擴展名更改爲.bat。

第1步：下載代碼

下載 1.0.0版本並解壓縮。

1 2	> tar -xzf kafka_2.11-1.0.0.tgz > cd kafka_2.11-1.0.0

第2步：啓動服務器

Kafka使用ZooKeeper，因此如果您還沒有ZooKeeper服務器，則需要先啓動ZooKeeper服務器。您可以使用與kafka一起打包的便捷腳本來獲取快速而簡單的單節點ZooKeeper實例。

1 2 3

> bin/zookeeper-server-start.sh config/zookeeper.properties [2013-04-22 15:01:37,495] INFO Reading configuration from: config/zookeeper.properties (org.apache.zookeeper.server.quorum.QuorumPeerConfig) ...

現在啓動Kafka服務器：

1 2 3 4

> bin/kafka-server-start.sh config/server.properties [2013-04-22 15:01:47,028] INFO Verifying properties (kafka.utils.VerifiableProperties) [2013-04-22 15:01:47,051] INFO Property socket.send.buffer.bytes is overridden to 1048576 (kafka.utils.VerifiableProperties) ...

第3步：創建一個主題

我們用一個分區和一個副本創建一個名爲“test”的主題：

1	> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test

我們現在可以看到這個話題，如果我們運行列表主題命令：

1 2	> bin/kafka-topics.sh --list --zookeeper localhost:2181 test

或者，您也可以將代理配置爲在發佈不存在的主題時自動創建主題，而不是手動創建主題。

第4步：發送一些消息

Kafka帶有一個命令行客戶端，它將從文件或標準輸入中獲取輸入，並將其作爲消息發送到Kafka集羣。默認情況下，每行將作爲單獨的消息發送。

運行生產者，然後在控制檯輸入一些消息發送到服務器。

1 2 3

> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test This is a message This is another message

第5步：啓動一個用戶

卡夫卡也有一個命令行消費者，將消息轉儲到標準輸出。

1 2 3

> bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning This is a message This is another message

如果您將上述每個命令都運行在不同的終端中，則現在應該可以將消息鍵入生產者終端，並將其顯示在消費者終端中。

所有的命令行工具都有其他選項。不帶任何參數運行該命令將顯示使用信息更詳細地記錄它們。

第6步：設置多代理羣集

到目前爲止，我們一直在反對一個經紀人，但這並不好玩。對於卡夫卡來說，一個經紀人只是一個規模一個的集羣，所以除了開始一些經紀人實例之外沒有太大的變化。但是爲了得到它的感覺，讓我們把我們的集羣擴展到三個節點（仍然都在我們的本地機器上）。

首先，我們爲每個代理創建一個配置文件（在Windows上使用copy命令代替）：

1 2	> cp config/server.properties config/server-1.properties > cp config/server.properties config/server-2.properties

現在編輯這些新文件並設置以下屬性：

1 2 3 4 五 6 7 8 9

config/server-1.properties:     broker.id=1     listeners=PLAINTEXT://:9093     log.dir=/tmp/kafka-logs-1   config/server-2.properties:     broker.id=2     listeners=PLAINTEXT://:9094     log.dir=/tmp/kafka-logs-2

該broker.id屬性是羣集中每個節點的唯一且永久的名稱。我們必須重寫端口和日誌目錄，因爲我們在同一臺機器上運行這些端口和日誌目錄，我們希望讓所有代理都試圖在同一個端口註冊或覆蓋彼此的數據。

我們已經有Zookeeper和我們的單節點了，所以我們只需要啓動兩個新的節點：

1 2 3 4

> bin/kafka-server-start.sh config/server-1.properties & ... > bin/kafka-server-start.sh config/server-2.properties & ...

現在創建一個複製因子爲三的新主題：

1	> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic

1 2 3

> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic Topic:my-replicated-topic   PartitionCount:1    ReplicationFactor:3 Configs:     Topic: my-replicated-topic  Partition: 0    Leader: 1   Replicas: 1,2,0 Isr: 1,2,0

好，但現在我們有一個集羣，我們怎麼知道哪個經紀人在做什麼？要查看運行“描述主題”命令：

這裏是對輸出的解釋。第一行給出了所有分區的摘要，每個附加行給出了關於一個分區的信息。由於我們只有一個分區，所以只有一行。

• “leader”是負責給定分區的所有讀取和寫入的節點。每個節點將成爲分區隨機選擇部分的領導者。
• “副本”是複製此分區的日誌的節點列表，無論它們是領導者還是即使他們當前還活着。
• “isr”是一組“同步”副本。這是複製品列表的子集，當前活着並被引導到領導者。

請注意，在我的示例中，節點1是該主題的唯一分區的領導者。

我們可以在我們創建的原始主題上運行相同的命令來查看它的位置：

1 2 3

> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test Topic:test  PartitionCount:1    ReplicationFactor:1 Configs:     Topic: test Partition: 0    Leader: 0   Replicas: 0 Isr: 0

所以這裏並不奇怪，原來的主題沒有副本，而且在服務器0上，這是我們創建集羣時唯一的服務器。

讓我們發表一些信息給我們的新主題：

1 2 3 4 五

> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-replicated-topic ... my test message 1 my test message 2 ^C

現在讓我們消費這些消息：

1 2 3 4 五

> bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic my-replicated-topic ... my test message 1 my test message 2 ^C

現在我們來測試一下容錯。經紀人1是作爲領導者，所以讓我們殺了它：

1 2 3

> ps aux | grep server-1.properties 7564 ttys002    0:15.91 /System/Library/Frameworks/JavaVM.framework/Versions/1.8/Home/bin/java... > kill -9 7564

在Windows上使用：

1 2 3 4

> wmic process where "caption = 'java.exe' and commandline like '%server-1.properties%'" get processid ProcessId 6016 > taskkill /pid 6016 /f

領導已經切換到其中一個從屬節點，並且節點1不再處於同步副本集合中：

1 2 3

> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic Topic:my-replicated-topic   PartitionCount:1    ReplicationFactor:3 Configs:     Topic: my-replicated-topic  Partition: 0    Leader: 2   Replicas: 1,2,0 Isr: 2,0

但是，即使原先寫入的領導者失敗，這些消息仍然可用於消費：

1 2 3 4 五

> bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic my-replicated-topic ... my test message 1 my test message 2 ^C

第7步：使用Kafka Connect來導入/導出數據

從控制檯寫入數據並將其寫回控制檯是一個方便的起點，但您可能想要使用其他來源的數據或將數據從Kafka導出到其他系統。對於許多系統，您可以使用Kafka Connect來導入或導出數據，而不必編寫自定義集成代碼。

Kafka Connect是Kafka包含的一個工具，可以將數據導入和導出到Kafka。它是一個可擴展的工具，運行 連接器，實現與外部系統交互的自定義​​邏輯。在這個快速入門中，我們將看到如何使用簡單的連接器運行Kafka Connect，這些連接器將數據從文件導入到Kafka主題，並將數據從Kafka主題導出到文件。

首先，我們將通過創建一些種子數據開始測試：

1	> echo -e "foo\nbar" > test.txt

或在Windows上：

1 2	> echo foo> test.txt > echo bar>> test.txt

接下來，我們將啓動兩個以獨立模式運行的連接器，這意味着它們將在單個本地專用進程中運行。我們提供三個配置文件作爲參數。首先是Kafka Connect過程的配置，包含常見的配置，例如要連接的Kafka代理以及數據的序列化格式。其餘的配置文件都指定一個要創建的連接器。這些文件包括唯一的連接器名稱，要實例化的連接器類以及連接器所需的任何其他配置。

1	> bin/connect-standalone.sh config/connect-standalone.properties config/connect-file-source.properties config/connect-file-sink.properties

Kafka附帶的這些示例配置文件使用您之前啓動的默認本地羣集配置，並創建兩個連接器：第一個是源連接器，用於讀取輸入文件中的行，並將每個連接生成爲Kafka主題，第二個爲連接器它從Kafka主題讀取消息，並在輸出文件中產生每行消息。

在啓動過程中，您會看到一些日誌消息，其中一些指示連接器正在實例化。Kafka Connect進程啓動後，源連接器應該開始讀取test.txt主題connect-test，並將其生成主題，並且接收器連接器應該開始讀取主題中的消息connect-test 並將其寫入文件test.sink.txt。我們可以通過檢查輸出文件的內容來驗證通過整個管道傳輸的數據：

1 2 3

> more test.sink.txt foo bar

請注意，數據存儲在Kafka主題中connect-test，因此我們也可以運行控制檯使用者來查看主題中的數據（或使用自定義使用者代碼來處理它）：

1 2 3 4

> bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic connect-test --from-beginning {"schema":{"type":"string","optional":false},"payload":"foo"} {"schema":{"type":"string","optional":false},"payload":"bar"} ...

連接器繼續處理數據，所以我們可以將數據添加到文件，並看到它在管道中移動：

1	> echo Another line>> test.txt

您應該看到該行出現在控制檯使用者輸出和接收器文件中。

第8步：使用Kafka流來處理數據

Kafka Streams是用於構建關鍵任務實時應用程序和微服務的客戶端庫，輸入和/或輸出數據存儲在Kafka集羣中。Kafka Streams結合了在客戶端編寫和部署標準Java和Scala應用程序的簡單性以及Kafka服務器端集羣技術的優勢，使這些應用程序具有高度可伸縮性，彈性，容錯性，分佈式等特性。本快速入門示例將演示如何運行在此庫中編碼的流式應用程序。

1.4生態系統

在主發行版之外還有大量與Kafka集成的工具。該生態系統頁面中列出的許多信息，包括流處理系統，Hadoop的集成，監控和部署工具。

 

 

1.5從以前的版本升級

從0.8.x，0.9.x，0.10.0.x，0.10.1.x，0.10.2.x或0.11.0.x升級到1.0.0

卡夫卡1.0.0引入了有線協議的變化。通過遵循以下建議的滾動升級計劃，您可以保證在升級過程中不會出現停機。但是，請在升級之前查看1.0.0中的顯着更改。

對於滾動升級：

1. 更新所有代理上的server.properties並添加以下屬性。CURRENT_KAFKA_VERSION是指您要升級的版本。CURRENT_MESSAGE_FORMAT_VERSION指的是當前正在使用的消息格式版本。如果您以前沒有重寫消息格式，那麼應該將CURRENT_MESSAGE_FORMAT_VERSION設置爲匹配CURRENT_KAFKA_VERSION。
   • inter.broker.protocol.version = CURRENT_KAFKA_VERSION（例如0.8.2,0.9.0,0.10.0,0.10.1,0.10.2,0.11.0）。
2. 一次升級一個代理：關閉代理，更新代碼並重新啓動代理。
3. 整個羣集升級後，通過編輯修改協議版本inter.broker.protocol.version並將其設置爲1.0。
4. 重新啓動代理，以使新的協議版本生效。

其他升級說明：

1. 如果你願意接受停機時間，你可以簡單地把所有的經紀人關閉，更新代碼並重新開始。他們將默認啓動新的協議。
2. 顛覆協議版本並重新啓動可以在代理升級後的任何時候完成。它不一定要在之後立即。同樣的消息格式版本。

1.0.0中的顯着變化

• 主題刪除現在默認啓用，因爲功能現在是穩定的。希望保留以前行爲的用戶應將代理配置設置delete.topic.enable爲false。請記住，主題刪除刪除數據，操作是不可逆的（即沒有“取消刪除”操作）
• 對於支持時間戳搜索的主題，如果沒有爲分區找到偏移量，則該分區現在包含在搜索結果中，並具有空偏移值。以前，分區不包含在地圖中。此更改是爲了使搜索行爲與不支持時間戳搜索的主題的情況一致。
• 如果inter.broker.protocol.version是1.0或更高版本，即使存在脫機日誌目錄，代理現在也將保持聯機，以便在實時日誌目錄上提供副本。由於硬件故障導致的IOException，日誌目錄可能會變爲脫機狀態。用戶需要監視每個代理度量標準offlineLogDirectoryCount來檢查是否存在脫機日誌目錄。
• 增加了KafkaStorageException，這是一個可以回溯的異常。如果客戶端的FetchRequest或ProducerRequest的版本不支持KafkaStorageException，則KafkaStorageException將在響應中轉換爲NotLeaderForPartitionException。
• -XX：在默認的JVM設置中+ DisableExplicitGC被-XX：+ ExplicitGCInvokesConcurrent替換。這有助於避免在某些情況下通過直接緩衝區分配本機內存期間的內存不足異常。
• 重寫的handleError方法實現已經從以下過時類中除去kafka.api：包FetchRequest，GroupCoordinatorRequest，OffsetCommitRequest，OffsetFetchRequest，OffsetRequest，ProducerRequest，和TopicMetadataRequest。這只是爲了在代理上使用，但它不再被使用，實現也沒有被維護。爲了二進制兼容性保留了一個存根實現。
• Java客戶端和工具現在接受任何字符串作爲客戶端ID。
• 棄用的工具kafka-consumer-offset-checker.sh已被刪除。使用kafka-consumer-groups.sh得到消費羣的詳細信息。
• SimpleAclAuthorizer現在默認將訪問拒絕記錄到授權人日誌中。
• 現在，身份驗證失敗報告給客戶端，作爲其中的一個子類AuthenticationException。如果客戶端連接驗證失敗，則不會執行重試。
• 自定義SaslServer實現可能會拋出SaslAuthenticationException提供錯誤消息返回給客戶端，指出身份驗證失敗的原因。執行者應注意不要在異常消息中包含任何不應泄露給未經身份驗證的客戶端的安全關鍵信息。
• app-info向JMX註冊以提供版本和提交ID 的mbean將被棄用，並由提供這些屬性的度量替換。
• 卡夫卡指標現在可能包含非數字值。org.apache.kafka.common.Metric#value()已被棄用，並將0.0在這種情況下返回，以最大限度地減少讀取每個客戶端度量值（通過MetricsReporter實現或調用metrics()方法）的用戶的概率。 org.apache.kafka.common.Metric#metricValue()可以用來檢索數字和非數字度量值。
• 現在，每個Kafka速率指標都有相應的累計計數度量標準，並帶有後綴-total 以簡化下游處理。例如，records-consumed-rate有一個相應的度量標準records-consumed-total。
• 只有系統屬性kafka_mx4jenable設置爲Mx4j才能啓用true。由於邏輯反轉錯誤，它以前是默認啓用的，如果kafka_mx4jenable被設置爲禁用則禁用true。
• org.apache.kafka.common.security.auth客戶端jar 包中的包已經公開並添加到javadoc中。以前在這個軟件包中的內部類已經移到其他地方了。
• 在使用授權人並且用戶對主題沒有必需的權限時，代理將無論主體是否存在，都會將TOPIC_AUTHORIZATION_FAILED錯誤返回給請求。如果用戶具有所需權限並且該主題不存在，則將返回UNKNOWN_TOPIC_OR_PARTITION錯誤代碼。
• config / consumer.properties文件更新爲使用新的使用者配置屬性。

新協議版本

• KIP-112：LeaderAndIsrRequest v1引入了一個分區級別的is_new字段。
• KIP-112：UpdateMetadataRequest v4引入了分區級offline_replicas字段。
• KIP-112：MetadataResponse v5引入了分區級offline_replicas字段。
• KIP-112：ProduceResponse v4引入了KafkaStorageException的錯誤代碼。
• KIP-112：FetchResponse v6引入了KafkaStorageException的錯誤代碼。
• KIP-152：已添加SaslAuthenticate請求以啓用身份驗證失敗的報告。如果SaslHandshake請求版本大於0，將使用此請求。

升級1.0.0 Kafka Streams應用程序

• 將Streams應用程序從0.11.0升級到1.0.0不需要代理升級。Kafka Streams 1.0.0應用程序可以連接到0.11.0，0.10.2和0.10.1代理（儘管如此，不能連接到0.10.0代理）。
• 如果您正在監控流指標，則需要對報告和監控代碼中的指標名稱進行一些更改，因爲指標傳感器層次結構已更改。
• 有一些公共的API，包括ProcessorContext#schedule()，Processor#punctuate()和KStreamBuilder，TopologyBuilder正在被新的API棄用。我們建議進行相應的代碼更改，因爲在升級時新的API看起來非常相似，所以這應該是非常小的。
• 有關更多詳細信息，請參閱1.0.0中的Streams API更改。

從0.8.x，0.9.x，0.10.0.x，0.10.1.x或0.10.2.x升級到0.11.0.0

卡夫卡0.11.0.0引入了一個新的消息格式版本以及有線協議的變化。通過遵循以下建議的滾動升級計劃，您可以保證在升級過程中不會出現停機。不過，請在升級之前查看0.11.0.0中的顯着更改。

從版本0.10.2開始，Java客戶端（生產者和消費者）已經獲得了與舊代理進行通信的能力。版本0.11.0客戶可以與版本0.10.0或更新的代理進行通信。但是，如果您的經紀人年齡大於0.10.0，則必須先升級Kafka集羣中的所有經紀人，然後再升級您的客戶。版本0.11.0經紀人支持0.8.x和更新的客戶端。

對於滾動升級：

1. 更新所有代理上的server.properties並添加以下屬性。CURRENT_KAFKA_VERSION是指您要升級的版本。CURRENT_MESSAGE_FORMAT_VERSION指的是當前正在使用的消息格式版本。如果您以前沒有重寫消息格式，那麼應該將CURRENT_MESSAGE_FORMAT_VERSION設置爲匹配CURRENT_KAFKA_VERSION。
   • inter.broker.protocol.version = CURRENT_KAFKA_VERSION（例如0.8.2,0.9.0,0.10.0,0.10.1或0.10.2）。
   • log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（請參閱升級後的潛在性能影響，瞭解有關此配置的詳細信息。）
2. 一次升級一個代理：關閉代理，更新代碼並重新啓動代理。
3. 整個羣集升級後，通過編輯修改協議版本inter.broker.protocol.version並將其設置爲0.11.0，但不要更改log.message.format.version。
4. 重新啓動代理，以使新的協議版本生效。
5. 一旦所有（或大部分）使用者升級到0.11.0或更高版本，則將每個代理上的log.message.format.version更改爲0.11.0，然後逐個重新啓動它們。請注意，較早的Scala消費者不支持新的消息格式，所以爲了避免下轉換的性能成本（或者只利用一次語義），必須使用新的Java消費者。

其他升級說明：

1. 如果你願意接受停機時間，你可以簡單地把所有的經紀人關閉，更新代碼並重新開始。他們將默認啓動新的協議。
2. 顛覆協議版本並重新啓動可以在代理升級後的任何時候完成。它不一定要在之後立即。同樣的消息格式版本。
3. bin/kafka-topics.sh在更新全局設置之前，還可以使用主題管理工具（）在個別主題上啓用0.11.0消息格式log.message.format.version。
4. 如果要從0.10.0之前的版本升級，則在切換到0.11.0之前，不必先將消息格式更新爲0.10.0。

升級0.10.2 Kafka Streams應用程序

• 將Streams應用程序從0.10.2升級到0.11.0不需要代理升級。Kafka Streams 0.11.0應用程序可以連接到0.11.0，0.10.2和0.10.1代理（儘管如此，不能連接到0.10.0代理）。
• 如果您指定自定義key.serde，value.serde並且timestamp.extractor在配置中，建議使用替換的配置參數，因爲這些配置已被棄用。
• 有關更多詳細信息，請參閱0.11.0中的Streams API更改。

在0.11.0.0中有顯着的變化

• 不潔淨的領導人選舉現在默認禁用。新的默認值有利於耐用性而不是可用性。希望保留以前行爲的用戶應將代理配置設置unclean.leader.election.enable爲true。
• 生產者配置block.on.buffer.full，metadata.fetch.timeout.ms並timeout.ms已被刪除。他們最初在Kafka 0.9.0.0中被棄用。
• 該offsets.topic.replication.factor券商的配置現在在強制汽車主題產生。內部自動主題創建將失敗並帶有GROUP_COORDINATOR_NOT_AVAILABLE錯誤，直到羣集大小滿足此複製因子要求。
• 當用快速壓縮數據時，製造商和代理商將使用壓縮方案的默認塊大小（2 x 32 KB）而不是1 KB來提高壓縮率。信息信息範範範範揮辛區中信息亦範範信亦信息信息信息信息信息 信息內暫名說預全
• 同樣，使用gzip壓縮數據時，生產者和代理將使用8 KB而不是1 KB作爲緩衝區大小。gzip的默認值過低（512字節）。
• 代理配置max.message.bytes現在適用於一批消息的總大小。之前的設置應用於批量壓縮消息，或單獨應用於非壓縮消息。批量消息可能只包含單個消息，因此在大多數情況下，單個消息的大小限制只能通過批量格式的開銷來減少。但是，消息格式轉換有一些細微的含義（詳見下文）。還要注意的是，雖然代理以前會確保每個提取請求中返回至少一條消息（不管總提取大小和分區級別的提取大小如何），但同樣的行爲現在適用於一個消息批處理。
• GC日誌旋轉默認啓用，詳情請參閱KAFKA-3754。
• RecordMetadata，MetricName和Cluster類的棄用構造函數已被刪除。
• 通過提供用戶頭讀寫訪問的新Headers接口增加了用戶頭支持。
• ProducerRecord和ConsumerRecord通過Headers headers()方法調用公開新的Headers API 。
• ExtendedSerializer和ExtendedDeserializer接口被引入來支持頭文件的序列化和反序列化。如果配置的串行器和解串器不是上述類，那麼標題將被忽略。
• group.initial.rebalance.delay.ms引入了一個新的配置。該配置指定以毫秒爲單位的時間GroupCoordinator將延遲最初的消費者重新平衡。group.initial.rebalance.delay.ms新會員加入團隊的價值將進一步推遲重新平衡，最高可達max.poll.interval.ms。這個的默認值是3秒。在開發和測試過程中，爲了不延遲測試執行時間，可能需要將其設置爲0。
• org.apache.kafka.common.Cluster#partitionsForTopic，partitionsForNode和availablePartitionsForTopic方法會返回一個空列表，而不是null在的情況下（這被認爲是不好的做法）的元數據所要求的主題不存在。
• 流API的配置參數timestamp.extractor，key.serde以及value.serde被棄用，替換default.timestamp.extractor，default.key.serde和default.value.serde分別。
• 對於Java消費者commitAsyncAPI 中的偏移提交失敗，當實例RetriableCommitFailedException傳遞給提交回調時，我們不再公開底層原因。有關 更多詳細信息，請參閱 KAFKA-5052。

新協議版本

• KIP-107：FetchRequest v5引入了一個分區級別的log_start_offset字段。
• KIP-107：FetchResponse v5引入了一個分區級別的log_start_offset字段。
• KIP-82：ProduceRequest v3 header在消息協議中引入了一個包含key字段和value字段的數組。
• KIP-82：FetchResponse v5 header在消息協議中引入了一個包含key字段和value字段的數組。

關於一次語義的註記

卡夫卡0.11.0支持生產者的冪等和事務性能力。冪等式傳遞確保消息在單個生產者的生命週期內僅傳遞給特定的主題分區一次。事務交付允許生產者發送數據到多個分區，使得所有的消息都被成功地傳遞，或者它們都不是。在一起，這些功能使卡夫卡“恰好一次語義”。有關這些功能的更多詳細信息，請參閱用戶指南，但下面我們添加一些關於在升級羣集中啓用它們的特定注意事項。請注意，啓用EoS不是必需的，如果未使用，則不會影響經紀人的行爲。

1. 只有新的Java生產者和消費者支持一次語義。
2. 這些功能主要取決於0.11.0消息格式。試圖以較舊的格式使用它們將導致不受支持的版本錯誤。
3. 事務狀態存儲在一個新的內部主題中__transaction_state。直到首次嘗試使用事務性請求API時才創建此主題。類似於消費者偏移主題，有幾個設置來控制主題的配置。例如，transaction.state.log.min.isr控制此主題的最小ISR。請參閱用戶指南中的配置部分以獲取完整的選項列表。
4. 對於安全集羣，事務性API需要新的ACL，可以使用新的ACL打開bin/kafka-acls.sh。工具。
5. Kafka的EoS引入了新的請求API，並修改了幾個現有的API。有關 完整的詳細信息，請參閱 KIP-98

關於0.11.0中新消息格式的說明

爲了支持生產者更好的交付語義（見KIP-98）和改進的複製容錯能力（見KIP-101），0.11.0消息格式包括幾個主要的增強。雖然新格式包含更多信息以使這些改進成爲可能，但是我們已經使批處理格式更有效率。只要每批消息的數量大於2，就可以降低整體開銷。然而，對於較小的批次，可能會有一個小的性能影響。請參閱這裏瞭解我們對新消息格式的初始性能分析結果。您還可以在KIP-98提案中找到關於消息格式的更多細節 。

新消息格式的顯着差異之一是，即使未壓縮的消息一起存儲爲一個批次。這對代理配置有一些影響max.message.bytes，這會限制單個批次的大小。首先，如果一個較老的客戶端使用舊格式產生消息到一個主題分區，並且這些消息比單獨的小 max.message.bytes，那麼代理可能會在上轉換過程中合併爲一個批次後拒絕它們。通常，這可能發生在單個消息的聚合大小大於max.message.bytes。老年消費者閱讀從新格式下轉換的消息也有類似的效果：如果提取大小沒有被設置爲至少與 max.message.bytes即使單個未壓縮的消息小於配置的獲取大小，消費者也可能無法取得進展。此行爲不影響Java客戶端的0.10.1.0及更高版本，因爲它使用更新的獲取協議，該協議確保即使超過獲取大小也能返回至少一條消息。爲了解決這些問題，你應該確保1）生產者的批量大小沒有被設置得大於max.message.bytes，並且2）消費者的獲取大小被設置爲至少與max.message.bytes。

大多數關於升級到0.10.0消息格式對性能影響的討論 仍然與0.11.0升級有關。這主要影響不使用TLS保護的羣集，因爲在這種情況下，“零複製”傳輸已經不可行。爲了避免下變換成本，您應該確保客戶應用程序升級到最新的0.11.0客戶端。重要的是，由於舊消費者已經在0.11.0.0中被棄用，所以它不支持新的消息格式。您必須升級才能使用新消費者使用新的消息格式，而不需要下轉換成本。請注意，0.11.0消費者支持與經紀商0.10.0向下兼容，因此可以先在經紀商之前升級客戶。

從0.8.x，0.9.x，0.10.0.x或0.10.1.x升級到0.10.2.0

0.10.2.0有線協議變化。通過遵循以下建議的滾動升級計劃，您可以保證在升級過程中不會出現停機。但是，請在升級之前查看0.10.2.0中的顯着更改。

從版本0.10.2開始，Java客戶端（生產者和消費者）已經獲得了與舊代理進行通信的能力。版本0.10.2客戶可以與版本0.10.0或更新的代理進行通話。但是，如果您的經紀人年齡大於0.10.0，則必須先升級Kafka集羣中的所有經紀人，然後再升級您的客戶。0.10.2版經紀人支持0.8.x和更新的客戶端。

對於滾動升級：

1. 更新所有代理上的server.properties文件並添加以下屬性：
   • inter.broker.protocol.version = CURRENT_KAFKA_VERSION（例如0.8.2,0.9.0,0.10.0或0.10.1）。
   • log.message.format.version = CURRENT_KAFKA_VERSION（請參閱升級後潛在的性能影響，瞭解有關此配置的詳細信息。）
2. 一次升級一個代理：關閉代理，更新代碼並重新啓動代理。
3. 一旦整個羣集升級，通過編輯inter.broker.protocol.version並將其設置爲0.10.2來提升協議版本。
4. 如果以前的消息格式是0.10.0，則將log.message.format.version更改爲0.10.2（因爲消息格式對於0.10.0，0.10.1和0.10.2而言是相同的，所以這是無操作的）。如果以前的消息格式版本低於0.10.0，則不要更改log.message.format.version - 只有在所有使用者已升級到0.10.0.0或更高版本後，才應更改此參數。
5. 重新啓動代理，以使新的協議版本生效。
6. 如果log.message.format.version此時仍低於0.10.0，請等到所有使用者升級到0.10.0或更高版本，然後在每個代理上將log.message.format.version更改爲0.10.2，重新啓動他們一個。

注意：如果您願意接受停機時間，您可以簡單地關閉所有經紀人，更新代碼並啓動所有代理。他們將默認啓動新的協議。

注意：在升級代理後，可以隨時進行升級協議版本並重新啓動。它不一定要在之後立即。

升級0.10.1 Kafka Streams應用程序

• 將Streams應用程序從0.10.1升級到0.10.2不需要代理升級。Kafka Streams 0.10.2應用程序可以連接到0.10.2和0.10.1代理（儘管如此，不能連接到0.10.0代理）。
• 你需要重新編譯你的代碼。只需交換Kafka Streams庫jar文件將不起作用，並會破壞您的應用程序。
• 如果您使用自定義（即，用戶實現的）時間戳提取器，則需要更新此代碼，因爲TimestampExtractor界面已更改。
• 如果您註冊自定義指標，則需要更新此代碼，因爲StreamsMetric界面已更改。
• 請參閱0.10.2中的Streams API更改以獲取更多詳細信息。

0.10.2.1中的顯着變化

• StreamsConfig類的兩個配置的默認值已更改，以提高Kafka Streams應用程序的彈性。內部Kafka Streams生產者retries默認值從0更改爲10.內部Kafka Streams消費者max.poll.interval.ms 默認值從300000更改爲Integer.MAX_VALUE。

0.10.2.0中的顯着變化

• Java客戶端（生產者和消費者）已經獲得了與舊經紀人溝通的能力。版本0.10.2客戶可以與版本0.10.0或更新的代理進行通話。請注意，某些功能在使用舊代理時不可用或受限。
• InterruptException如果調用線程中斷，則Java消費者的幾個方法現在可能會拋出。請參閱KafkaConsumerJavadoc以獲得對此更改的更深入的解釋。
• Java消費者現在關閉優雅。默認情況下，消費者等待最多30秒以完成待處理的請求。已經添加了一個新的超時關閉API KafkaConsumer來控制最大等待時間。
• 用逗號分隔的多個正則表達式可以通過--whitelist選項與新的Java使用者一起傳遞給MirrorMaker。當使用舊的Scala消費者時，這使得行爲與MirrorMaker一致。
• 將Streams應用程序從0.10.1升級到0.10.2不需要代理升級。Kafka Streams 0.10.2應用程序可以連接到0.10.2和0.10.1代理（儘管如此，不能連接到0.10.0代理）。
• Zookeeper依賴項已從Streams API中刪除。Streams API現在使用Kafka協議來管理內部主題，而不是直接修改Zookeeper。這消除了直接訪問Zookeeper的權限，不應該在Streams應用中設置“StreamsConfig.ZOOKEEPER_CONFIG”。如果Kafka集羣受到保護，Streams應用程序必須具有所需的安全權限才能創建新主題。
• StreamsConfig類添加了幾個新的字段，包括“security.protocol”，“connections.max.idle.ms”，“retry.backoff.ms”，“reconnect.backoff.ms”和“request.timeout.ms”。用戶應該注意默認值，並根據需要進行設置。欲瞭解更多詳情，請參閱3.5卡夫卡流配置。

新協議版本

• KIP-88：OffsetFetchRequest v2支持檢索所有主題的偏移量，如果topics數組設置爲null。
• KIP-88：OffsetFetchResponse v2引入了一個頂級error_code字段。
• KIP-103：UpdateMetadataRequest v3 listener_name爲end_points數組的元素引入一個字段。
• KIP-108：CreateTopicsRequest v1引入了一個validate_only字段。
• KIP-108：CreateTopicsResponse v1 error_message爲topic_errors數組的元素引入一個字段。

從0.8.x，0.9.x或0.10.0.X升級到0.10.1.0

0.10.1.0有線協議變化。通過遵循以下建議的滾動升級計劃，您可以保證在升級過程中不會出現停機。但是，請注意在升級之前0.10.1.0中的潛在中斷更改。 
注意：由於引入了新協議，所以在升級客戶端之前升級您的Kafka羣集非常重要（即，0.10.1.x客戶端僅支持0.10.1.x或更高版本的代理，而0.10.1.x代理也支持較舊的客戶端） 。

對於滾動升級：

1. 更新所有代理上的server.properties文件並添加以下屬性：
   • inter.broker.protocol.version = CURRENT_KAFKA_VERSION（例如0.8.2.0，0.9.0.0或0.10.0.0）。
   • log.message.format.version = CURRENT_KAFKA_VERSION（請參閱升級後潛在的性能影響，瞭解有關此配置的詳細信息。）
2. 一次升級一個代理：關閉代理，更新代碼並重新啓動代理。
3. 一旦整個羣集升級，通過編輯inter.broker.protocol.version並將其設置爲0.10.1.0來提升協議版本。
4. 如果以前的消息格式爲0.10.0，則將log.message.format.version更改爲0.10.1（由於0.10.0和0.10.1的消息格式相同，因此這是無操作）。如果以前的消息格式版本低於0.10.0，則不要更改log.message.format.version - 只有在所有使用者已升級到0.10.0.0或更高版本後，才應更改此參數。
5. 重新啓動代理，以使新的協議版本生效。
6. 如果log.message.format.version此時仍低於0.10.0，請等到所有使用者升級到0.10.0或更高版本，然後在每個代理上將log.message.format.version更改爲0.10.1，重新啓動他們一個。

注意：如果您願意接受停機時間，您可以簡單地關閉所有經紀人，更新代碼並啓動所有代理。他們將默認啓動新的協議。

注意：在升級代理後，可以隨時進行升級協議版本並重新啓動。它不一定要在之後立即。

0.10.1.0中潛在的突破變化

• 日誌保留時間不再基於日誌段的上次修改時間。相反，它將基於日誌段中消息的最大時間戳。
• 日誌滾動時間不再取決於日誌段創建時間。相反，它現在基於消息中的時間戳。進一步來說。如果段中第一條消息的時間戳是T，則當新消息的時間戳大於或等於T + log.roll.ms
• 由於每個段添加了時間索引文件，0.10.0的開放文件處理程序將增加〜33％。
• 時間索引和偏移索引共享相同的索引大小配置。由於每次索引條目是偏移索引條目大小的1.5倍。用戶可能需要增加log.index.size.max.bytes以避免潛在的頻繁的日誌滾動。
• 由於索引文件數量的增加，在一些具有大量日誌段（例如大於15K）的代理上，代理啓動期間的日誌加載過程可能會更長。根據我們的實驗，將num.recovery.threads.per.data.dir設置爲1可能會減少日誌加載時間。

升級0.10.0 Kafka Streams應用程序

• 將Streams應用程序從0.10.0升級到0.10.1確實需要代理升級，因爲Kafka Streams 0.10.1應用程序只能連接到0.10.1代理。
• 有幾個API的變化，這是不是向後兼容（更多的細節比較0.10.1流更改API）。因此，您需要更新並重新編譯您的代碼。只需交換Kafka Streams庫jar文件將不起作用，並會破壞您的應用程序。

0.10.1.0中的顯着變化

• 新的Java消費者不再處於測試階段，我們推薦所有新的開發。舊的Scala消費者仍然支持，但是在下一個版本中它們將被棄用，並將在未來的主要版本中被刪除。
• 將--new-consumer/ --new.consumer開關不再需要使用像MirrorMaker和控制檯消費者與消費者的新工具; 只需要通過一個卡夫卡經紀人來連接，而不是ZooKeeper合奏。此外，與舊用戶一起使用控制檯消費者已被棄用，並將在未來的主要版本中刪除。
• 卡夫卡羣集現在可以由羣集ID唯一標識。當代理升級到0.10.1.0時，它會自動生成。羣集ID可通過kafka.server：type = KafkaServer，name = ClusterId指標獲得，它是元數據響應的一部分。串行器，客戶端攔截器和度量記錄器可以通過實現ClusterResourceListener接口來接收集羣ID。
• BrokerState“RunningAsController”（值4）已被刪除。由於一個錯誤，一個經紀人在轉換出來之前只會處於這個狀態，因此移除的影響應該是最小的。檢測指定代理是否爲控制器的推薦方法是通過kafka.controller：type = KafkaController，name = ActiveControllerCount指標。
• 新的Java使用者現在允許用戶通過分區上的時間戳搜索偏移量。
• 新的Java使用者現在支持來自後臺線程的心跳。有一個新的配置 max.poll.interval.ms，它控制在用戶主動離開組之前輪詢調用之間的最大時間（默認爲5分鐘）。配置的值 request.timeout.ms必須總是大於max.poll.interval.ms因爲這是JoinGroup請求在服務器重新平衡時可以阻止的最大時間，所以我們已經將其默認值更改爲剛好在5分鐘以上。最後，默認值session.timeout.ms已經調整到10秒，默認值max.poll.records已經改爲500。
• 當使用授權人，並且用戶沒有描述對主題的授權時，代理將不再向請求返回TOPIC_AUTHORIZATION_FAILED錯誤，因爲這會泄漏主題名稱。相反，UNKNOWN_TOPIC_OR_PARTITION錯誤代碼將被返回。這可能會導致使用生產者和使用者時出現意外超時或延遲，因爲Kafka客戶端通常會在未知主題錯誤時自動重試。如果您懷疑這可能會發生，您應該諮詢客戶端日誌。
• 提取響應的默認大小限制（消費者爲50 MB，複製爲10 MB）。現有的每個分區限制也適用（1 MB用於消費者和複製）。請注意，這些限制都不是下一個解釋的絕對最大值。
• 如果發現大於響應/分區大小限制的消息，則消費者和副本可以取得進展。更具體地說，如果提取的第一個非空分區中的第一條消息大於一個或兩個限制，則該消息仍將被返回。
• 被添加的重載構造函數被添加到kafka.api.FetchRequest並kafka.javaapi.FetchRequest允許調用者指定分區的順序（因爲在v3中順序是重要的）。先前存在的構造函數已被棄用，在發送請求之前將分區進行混洗，以避免飢餓問題。

新協議版本

• ListOffsetRequest v1支持基於時間戳的精確偏移搜索。
• MetadataResponse v2引入了一個新的字段：“cluster_id”。
• FetchRequest v3支持限制響應大小（除現有的每個分區限制之外），如果需要進行更改，則返回大於限制的消息，並且請求中的分區順序現在很重要。
• JoinGroup v1引入了一個新的字段：“rebalance_timeout”。

從0.8.x或0.9.x升級到0.10.0.0

0.10.0.0有潛在的重大變化（請在升級之前查看）以及升級後可能的 性能影響。通過遵循以下建議的滾動升級計劃，可確保在升級過程中和升級後不會出現停機和性能影響。 
注意：由於引入了新的協議，在升級客戶端之前升級您的Kafka集羣非常重要。

對於版本爲0.9.0.0的客戶的說明：由於在0.9.0.0中引入了一個錯誤，依賴於ZooKeeper的客戶端（舊Scala高級Consumer和MirrorMaker，如果與舊客戶一起使用）將不能與0.10.0.x代理。因此，在將代理升級到0.10.0.x 之前，應將0.9.0.0客戶升級到0.9.0.1。對於0.8.X或0.9.0.1客戶端，這一步不是必需的。

對於滾動升級：

1. 更新所有代理上的server.properties文件並添加以下屬性：
   • inter.broker.protocol.version = CURRENT_KAFKA_VERSION（例如0.8.2或0.9.0.0）。
   • log.message.format.version = CURRENT_KAFKA_VERSION（請參閱升級後潛在的性能影響，瞭解有關此配置的詳細信息。）
2. 升級經紀人。這可以通過簡單地將其關閉，更新代碼並重新啓動它來完成。
3. 一旦整個羣集升級，通過編輯inter.broker.protocol.version並將其設置爲0.10.0.0來衝擊協議版本。注意：您不應該觸摸log.message.format.version - 只有當所有使用者升級到0.10.0.0後，該參數纔會更改
4. 重新啓動代理，以使新的協議版本生效。
5. 一旦所有使用者升級到0.10.0，在每個代理上將log.message.format.version更改爲0.10.0，然後逐個重新啓動。

注意：如果您願意接受停機時間，您可以簡單地關閉所有經紀人，更新代碼並啓動所有代理。他們將默認啓動新的協議。

注意：在升級代理後，可以隨時進行升級協議版本並重新啓動。它不一定要在之後立即。

在升級到0.10.0.0後，可能會對性能造成影響

0.10.0中的消息格式包含一個新的時間戳字段，並使用壓縮消息的相對偏移量。磁盤上的消息格式可以通過server.properties文件中的log.message.format.version來配置。默認的磁盤上消息格式是0.10.0。如果消費者客戶端使用的是0.10.0.0之前的版本，則只能理解0.10.0之前的消息格式。在這種情況下，代理可以將消息從0.10.0格式轉換爲較早的格式，然後將響應發送給舊版本的使用者。但是，在這種情況下，經紀人不能使用零複製轉移。卡夫卡社區對性能影響的報告顯示，在升級之後，CPU使用率從20％上升到100％，迫使所有客戶端立即升級，以使性能恢復正常。爲避免消費者升級到0.10.0.0之前的這種消息轉換，可以將代理升級到0.10.0.0時將log.message.format.version設置爲0.8.2或0.9.0。這樣，經紀人仍然可以使用零拷貝轉移將數據發送給舊消費者。消費者升級之後，可以將代理上的消息格式更改爲0.10.0，並享受包含新時間戳和改進壓縮的新消息格式。支持該轉換以確保兼容性，對於支持尚未更新到較新客戶端的少數應用程序可能會有用，但即使在過度配置的羣集上也不支持所有使用者流量。因此，在經紀人升級後儘可能避免信息轉換是非常重要的，但大多數客戶還沒有。將代理升級到0.10.0.0時，message.format.version爲0.8.2或0.9.0。這樣，經紀人仍然可以使用零拷貝轉移將數據發送給舊消費者。消費者升級之後，可以將代理上的消息格式更改爲0.10.0，並享受包含新時間戳和改進壓縮的新消息格式。支持該轉換以確保兼容性，對於支持尚未更新到較新客戶端的少數應用程序可能會有用，但即使在過度配置的羣集上也不支持所有使用者流量。因此，在經紀人升級後儘可能避免信息轉換是非常重要的，但大多數客戶還沒有。將代理升級到0.10.0.0時，message.format.version爲0.8.2或0.9.0。這樣，經紀人仍然可以使用零拷貝轉移將數據發送給舊消費者。消費者升級之後，可以將代理上的消息格式更改爲0.10.0，並享受包含新時間戳和改進壓縮的新消息格式。支持該轉換以確保兼容性，對於支持尚未更新到較新客戶端的少數應用程序可能會有用，但即使在過度配置的羣集上也不支持所有使用者流量。因此，在經紀人升級後儘可能避免信息轉換是非常重要的，但大多數客戶還沒有。經紀人仍然可以使用零拷貝轉移將數據發送給舊消費者。消費者升級之後，可以將代理上的消息格式更改爲0.10.0，並享受包含新時間戳和改進壓縮的新消息格式。支持該轉換以確保兼容性，對於支持尚未更新到較新客戶端的少數應用程序可能會有用，但即使在過度配置的羣集上也不支持所有使用者流量。因此，在經紀人升級後儘可能避免信息轉換是非常重要的，但大多數客戶還沒有。經紀人仍然可以使用零拷貝轉移將數據發送給舊消費者。消費者升級之後，可以將代理上的消息格式更改爲0.10.0，並享受包含新時間戳和改進壓縮的新消息格式。支持該轉換以確保兼容性，對於支持尚未更新到較新客戶端的少數應用程序可能會有用，但即使在過度配置的羣集上也不支持所有使用者流量。因此，在經紀人升級後儘可能避免信息轉換是非常重要的，但大多數客戶還沒有。支持該轉換以確保兼容性，對於支持尚未更新到較新客戶端的少數應用程序可能會有用，但即使在過度配置的羣集上也不支持所有使用者流量。因此，在經紀人升級後儘可能避免信息轉換是非常重要的，但大多數客戶還沒有。支持該轉換以確保兼容性，對於支持尚未更新到較新客戶端的少數應用程序可能會有用，但即使在過度配置的羣集上也不支持所有使用者流量。因此，在經紀人升級後儘可能避免信息轉換是非常重要的，但大多數客戶還沒有。

對於升級到0.10.0.0的客戶端，不會影響性能。

注意：通過設置消息格式版本，可以證明所有現有消息都在該消息格式版本之上或之下。否則0.10.0.0之前的消費者可能會中斷。特別是，在消息格式設置爲0.10.0之後，不應將其更改回以前的格式，因爲它可能會破壞0.10.0.0之前的版本中的使用者。

注意：由於在每條消息中引入了額外的時間戳，發送小消息的生產者可能由於增加的開銷而看到消息吞吐量下降。同樣，複製現在每個消息傳輸額外的8個字節。如果您運行的是接近集羣的網絡容量，則可能會淹沒網卡，並看到由於過載而導致的故障和性能問題。

注意：如果您在生產者上啓用了壓縮，在某些情況下，您可能會注意到生產者吞吐量降低和/或代理上的壓縮率降低。在接收壓縮消息時，0.10.0的代理避免重新壓縮消息，這通常減少了延遲並提高了吞吐量。然而，在某些情況下，這可能會減少生產者的配料尺寸，這可能導致更差的吞吐量。如果發生這種情況，用戶可以調整生產者的linger.ms和batch.size以獲得更好的吞吐量。另外，用於壓縮snappy消息的生產者緩衝區比代理使用的緩衝區小，這可能會對磁盤上​​的消息的壓縮率產生負面影響。我們打算在未來的Kafka版本中進行配置。

0.10.0.0中潛在的重大更改

• 從Kafka 0.10.0.0開始，Kafka中的消息格式版本被表示爲Kafka版本。例如，消息格式0.9.0指的是Kafka 0.9.0支持的最高消息版本。
• 消息格式0.10.0已經被引入，並且被默認使用。它包含消息中的時間戳字段，相對偏移量用於壓縮消息。
• ProduceRequest / Response v2已被引入，默認情況下使用它來支持消息格式0.10.0
• FetchRequest / Response v2已被引入，默認情況下使用FetchRequest / Response v2來支持消息格式0.10.0
• MessageFormatter接口已從更改def writeTo(key: Array[Byte], value: Array[Byte], output: PrintStream)爲 def writeTo(consumerRecord: ConsumerRecord[Array[Byte], Array[Byte]], output: PrintStream)
• MessageReader接口從def readMessage(): KeyedMessage[Array[Byte], Array[Byte]]改爲 def readMessage(): ProducerRecord[Array[Byte], Array[Byte]]
• MessageFormatter的包已經被更改kafka.tools爲kafka.common
• MessageReader的包已經被更改kafka.tools爲kafka.common
• MirrorMakerMessageHandler不再公開該handle(record: MessageAndMetadata[Array[Byte], Array[Byte]])方法，因爲它從來沒有被調用過。
• 0.7 KafkaMigrationTool不再與Kafka打包在一起。如果您需要從0.7遷移到0.10.0，請先遷移到0.8，然後按照記錄的升級過程從0.8升級到0.10.0。
• 新的消費者已經將其API標準化，以接受java.util.Collection作爲方法參數的序列類型。現有的代碼可能需要更新才能使用0.10.0客戶端庫。
• LZ4壓縮的消息處理已更改爲使用可互操作的幀規範（LZ4f v1.5.1）。爲了保持與舊客戶端的兼容性，此更改僅適用於消息格式0.10.0及更高版本。使用v0 / v1（消息格式0.9.0）生成/獲取LZ4壓縮消息的客戶端應該繼續使用0.9.0成幀實現。使用Produce / Fetch協議v2或更高版本的客戶端應使用可互操作的LZ4f成幀。可在http://www.lz4.org/上找到可互操作的LZ4庫列表。

0.10.0.0中的顯着變化

• 從Kafka 0.10.0.0開始，一個名爲Kafka Streams的新客戶端庫可用於對存儲在Kafka主題中的數據進行流處理。由於上面提到的消息格式更改，此新客戶端庫僅適用於0.10.x版本和向上版本的代理。欲瞭解更多信息，請閱讀Streams文檔。
• 新用戶的配置參數的默認值receive.buffer.bytes現在是64K。
• 新的使用者現在公開配置參數exclude.internal.topics以限制內部主題（例如消費者偏移主題）被意外地包含在正則表達式訂閱中。默認情況下，它被啓用。
• 舊的斯卡拉生產者已被棄用。用戶應儘快將其代碼遷移到包含在kafka-clients JAR中的Java生產者。
• 新的消費者API已被標記爲穩定。

從0.8.0，0.8.1.X或0.8.2.X升級到0.9.0.0

0.9.0.0有潛在的重大變化（請在升級之前查看）以及與之前版本的代理間協議更改。這意味着升級的經紀人和客戶可能與舊版本不兼容。在升級客戶端之前，升級您的Kafka集羣非常重要。如果您正在使用MirrorMaker，則應首先升級下游羣集。

對於滾動升級：

1. 更新所有代理上的server.properties文件並添加以下屬性：inter.broker.protocol.version = 0.8.2.X
2. 升級經紀人。這可以通過簡單地將其關閉，更新代碼並重新啓動它來完成。
3. 一旦整個羣集升級，通過編輯inter.broker.protocol.version並將其設置爲0.9.0.0來打破協議版本。
4. 重新啓動代理，以使新的協議版本生效

注意：如果您願意接受停機時間，您可以簡單地關閉所有經紀人，更新代碼並啓動所有代理。他們將默認啓動新的協議。

注意：在升級代理後，可以隨時進行升級協議版本並重新啓動。它不一定要在之後立即。

0.9.0.0中潛在的重大更改

• Java 1.6不再支持。
• 斯卡拉2.9不再支持。
• 超過1000的經紀商ID現在默認保留爲自動分配的經紀商ID。如果您的羣集具有高於該閾值的現有代理ID，請確保相應地增加reserved.broker.max.id代理配置屬性。
• 配置參數replica.lag.max.messages被刪除。當決定哪些副本同步時，分區領導將不再考慮滯後消息的數量。
• 現在，配置參數replica.lag.time.max.ms不僅指自上次從副本獲取請求之後經過的時間，還指自上次複製最後一次被抓取的時間。仍然從領導獲取消息的副本，但沒有趕上replica.lag.time.max.ms中的最新消息將被視爲不同步。
• 壓縮主題不再接受沒有密鑰的消息，並且如果嘗試這樣做，生產者拋出異常。在0.8.x中，沒有鍵的消息會導致日誌壓縮線程隨後發出抱怨並退出（並停止壓縮所有壓縮的主題）。
• MirrorMaker不再支持多個目標羣集。因此它只接受一個--consumer.config參數。要鏡像多個源羣集，每個源羣集至少需要一個MirrorMaker實例，每個羣集都有自己的消費者配置。
• 在org.apache.kafka.clients.tools。*下打包的工具已被移至org.apache.kafka.tools。*。所有包含的腳本仍然照常運行，只有直接導入這些類的自定義代碼纔會受到影響。
• kafka-run-class.sh中已經更改了默認的Kafka JVM性能選項（KAFKA_JVM_PERFORMANCE_OPTS）。
• kafka-topics.sh腳本（kafka.admin.TopicCommand）現在以非零退出代碼退出。
• kafka-topics.sh腳本（kafka.admin.TopicCommand）現在將在主題名稱由於使用“。”而導致風險度量標準衝突時顯示警告。或主題名稱中的“_”，以及實際發生碰撞時的錯誤。
• kafka-console-producer.sh腳本（kafka.tools.ConsoleProducer）將使用Java生產者而不是舊的Scala生產者作爲默認的，並且用戶必須指定“old-producer”來使用舊的生產者。
• 默認情況下，所有命令行工具都將打印所有日誌消息到stderr而不是stdout。

0.9.0.1中的顯着變化

• 可以通過將broker.id.generation.enable設置爲false來禁用新的代理ID生成功能。
• 配置參數log.cleaner.enable默認爲true。這意味着具有cleanup.policy = compact的主題現在將被默認壓縮，128 MB的堆將通過log.cleaner.dedupe.buffer.size分配給清除進程。您可能需要根據您使用的壓縮主題來查看log.cleaner.dedupe.buffer.size和其他log.cleaner配置值。
• 新用戶的配置參數fetch.min.bytes的默認值現在默認爲1。

在0.9.0.0中棄用

• 已經不建議使用kafka-topics.sh腳本（kafka.admin.TopicCommand）更改主題配置。今後，請使用kafka-configs.sh腳本（kafka.admin.ConfigCommand）來實現此功能。
• kafka-consumer-offset-checker.sh（kafka.tools.ConsumerOffsetChecker）已被棄用。今後，請使用kafka-consumer-groups.sh（kafka.admin.ConsumerGroupCommand）來實現此功能。
• kafka.tools.ProducerPerformance類已被棄用。今後，請使用org.apache.kafka.tools.ProducerPerformance來實現此功能（kafka-producer-perf-test.sh也將更改爲使用新類）。
• 生產者配置block.on.buffer.full已被棄用，並將在未來的版本中被刪除。目前其默認值已被更改爲false。KafkaProducer將不再拋出BufferExhaustedException，而是使用max.block.ms值來阻塞，之後將拋出一個TimeoutException。如果將block.on.buffer.full屬性顯式設置爲true，則會將max.block.ms設置爲Long.MAX_VALUE，並且不會將metadata.fetch.timeout.ms

從0.8.1升級到0.8.2

0.8.2與0.8.1完全兼容。升級可以通過簡單地將其關閉，更新代碼並重新啓動來一次完成一個代理。

從0.8.0升級到0.8.1

0.8.1與0.8完全兼容。升級可以通過簡單地將其關閉，更新代碼並重新啓動來一次完成一個代理。

從0.7升級

版本0.7與新版本不兼容。對API，ZooKeeper數據結構，協議和配置進行了重大更改，以便添加複製（0.7中缺少）。從0.7升級到更高版本需要專門的遷移工具。這種遷移可以在沒有停機的情況下完成。