kafka升級官方指導及注意事項

從0.8.x，0.9.x，0.10.0.x，0.10.1.x，0.10.2.x，0.11.0.x，1.0.x，1.1.x，2.0.x或2.1.x升級到2.2.0

如果要從2.1.x之前的版本升級，請參閱以下注釋，以了解用於存儲使用者偏移量的架構的更改。將inter.broker.protocol.version更改為最新版本后，將無法降級到2.1之前的版本。

對於滾動升級：

1. 在所有代理上更新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（例如0.8.2、0.9.0、0.10.0、0.10.1、0.10.2、0.11.0、1.0、1.1）。
   • log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（有關此配置的詳細信息，請參閱升級后對性能的潛在影響。）
   如果要從0.11.0.x，1.0.x，1.1.x或2.0.x升級，並且尚未覆蓋消息格式，則只需要覆蓋代理間協議版本。
   • inter.broker.protocol.version = CURRENT_KAFKA_VERSION（0.11.0，1.0，1.1，2.0）。
2. 一次升級一個代理：關閉代理，更新代碼，然后重新啟動。完成此操作后，代理將運行最新版本，並且您可以驗證集群的行為和性能是否符合預期。如果有任何問題，此時仍可以降級。
3. 驗證群集的行為和性能后，請通過編輯協議版本inter.broker.protocol.version並將其設置為2.2來提高協議版本 。
4. 逐一重新啟動代理，以使新協議版本生效。代理開始使用最新的協議版本后，將無法再將集群降級到較舊的版本。
5. 如果您已按照上述說明覆蓋了消息格式版本，則需要再進行一次滾動重啟以將其升級到最新版本。一旦所有（或大多數）使用者均已升級到0.11.0或更高版本，請在每個代理上將log.message.format.version更改為2.2，然后逐一重新啟動它們。請注意，不再維護的較舊的Scala客戶端不支持0.11中引入的消息格式，因此為避免轉換成本（或僅利用一次語義即可），必須使用較新的Java客戶端。

2.2.1中的顯着變化

• Kafka Streams 2.2.1需要0.11或更高的消息格式，並且不適用於較舊的消息格式。

2.2.0中的顯着變化

• 默認消費者組ID已從空字符串（""）更改為null。使用新的默認組ID的使用者將無法訂閱主題，也無法獲取或提交偏移量。不建議使用空字符串作為消費者組ID，但將支持該字符串，直到以后的主要版本為止。現在，依賴空字符串組ID的舊客戶端將必須顯式提供它作為其使用者配置的一部分。有關更多信息，請參見 KIP-289。
• 該bin/kafka-topics.sh命令行工具現在能夠直接連接到經紀商--bootstrap-server，而不是飼養員。舊--zookeeper 選項現在仍然可用。請閱讀KIP-377了解更多信息。
• Kafka Streams依賴於需要MacOS 10.13或更高版本的RocksDB的較新版本。

從0.8.x，0.9.x，0.10.0.x，0.10.1.x，0.10.2.x，0.11.0.x，1.0.x，1.1.x或2.0.0升級到2.1.0

請注意，2.1.x包含對用於存儲使用者偏移量的內部架構的更改。升級完成后，將無法降級到以前的版本。有關更多詳細信息，請參見下面的滾動升級說明。

對於滾動升級：

1. 在所有代理上更新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（例如0.8.2、0.9.0、0.10.0、0.10.1、0.10.2、0.11.0、1.0、1.1）。
   • log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（有關此配置的詳細信息，請參閱升級后對性能的潛在影響。）
   如果要從0.11.0.x，1.0.x，1.1.x或2.0.x升級，並且尚未覆蓋消息格式，則只需要覆蓋代理間協議版本。
   • inter.broker.protocol.version = CURRENT_KAFKA_VERSION（0.11.0，1.0，1.1，2.0）。
2. 一次升級一個代理：關閉代理，更新代碼，然后重新啟動。完成此操作后，代理將運行最新版本，並且您可以驗證集群的行為和性能是否符合預期。如果有任何問題，此時仍可以降級。
3. 驗證群集的行為和性能后，請通過編輯協議版本inter.broker.protocol.version並將其設置為2.1來提高協議版本 。
4. 逐一重新啟動代理，以使新協議版本生效。代理開始使用最新的協議版本后，將無法再將集群降級到較舊的版本。
5. 如果您已按照上述說明覆蓋了消息格式版本，則需要再進行一次滾動重啟以將其升級到最新版本。一旦所有（或大多數）使用者都升級到0.11.0或更高版本，則在每個代理上將log.message.format.version更改為2.1，然后逐一重新啟動它們。請注意，不再維護的較舊的Scala客戶端不支持0.11中引入的消息格式，因此為避免轉換成本（或僅利用一次語義即可），必須使用較新的Java客戶端。

其他升級說明：

1. 偏移到期語義在此版本中已稍有更改。根據新的語義，當組訂閱了相應的主題並且仍處於活動狀態（具有活動的使用者）時，組中分區的偏移量將不會被刪除。如果組變為空，則在默認的偏移保留期（或由代理設置的偏移時間）過去之后（除非該組再次變為活動狀態），將刪除所有偏移。自上次提交以來，默認的偏移保留期（或代理設置的偏移）將在其不使用Kafka組管理的獨立（簡單）使用者相關的偏移之后被刪除。
2. 現在，enable.auto.commit當未group.id提供時，控制台使用者屬性的默認值設置為false。這是為了避免污染消費者協調器緩存，因為自動生成的組不太可能被其他消費者使用。
3. 如我們 在KIP-91中所介紹的那樣，生產者retries配置的默認值已更改為Integer.MAX_VALUE，它設置了發送記錄和從代理接收確認之間的總時間上限。默認情況下，傳遞超時設置為2分鍾。delivery.timeout.ms
4. 默認情況下，MirrorMaker現在在配置生產者時會覆蓋delivery.timeout.ms到Integer.MAX_VALUE。如果您已覆蓋值retries以更快地失敗，則需要覆蓋delivery.timeout.ms。
5. 該ListGroupAPI現在希望作為一種推薦的替代方法，是Describe Group訪問用戶應該能夠列出的組。即使Describe Cluster仍支持舊訪問以實現向后兼容性，也不建議將其用於此API。
6. KIP-336棄用了ExtendedSerializer和ExtendedDeserializer接口，並傳播了Serializer和Deserializer的用法。KIP-82引入了ExtendedSerializer和ExtendedDeserializer ，以Java 7兼容的方式為序列化器和反序列化器提供記錄頭。現在我們合並了這些接口，因為從那時起不再支持Java 7。

2.1.0中的顯着變化

• Jetty已升級到9.4.12，默認情況下不包括TLS_RSA_ *密碼，因為它們不支持前向保密性，有關更多信息，請參見https://github.com/eclipse/jetty.project/issues/2807。
• 當unclean.leader.election.enable使用每個主題的配置替代動態更新配置時，控制器會自動啟用不干凈的領導者選舉。
• 在AdminClient增加了一個方法AdminClient#metrics()。現在，任何使用的應用程序AdminClient都可以通過查看從捕獲的指標來獲取更多信息和洞察力AdminClient。有關更多信息，請參見KIP-324
• Kafka現在支持來自KIP-110的 Zstandard壓縮。您必須升級代理以及客戶端才能使用它。2.1.0之前的使用者將無法閱讀使用Zstandard壓縮的主題，因此在升級所有下游使用者之前，您不應為主題啟用它。有關更多詳細信息，請參見KIP。

從0.8.x，0.9.x，0.10.0.x，0.10.1.x，0.10.2.x，0.11.0.x，1.0.x或1.1.x升級到2.0.0

Kafka 2.0.0引入了有線協議更改。通過遵循以下建議的滾動升級計划，可以保證升級期間不會停機。但是，請在升級前查看2.0.0中的顯着更改。

對於滾動升級：

1. 在所有代理上更新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（例如0.8.2、0.9.0、0.10.0、0.10.1、0.10.2、0.11.0、1.0、1.1）。
   • log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（有關此配置的詳細信息，請參閱升級后對性能的潛在影響。）
   如果要從0.11.0.x，1.0.x或1.1.x升級，並且尚未覆蓋消息格式，則只需要覆蓋中間經紀人協議格式。
   • inter.broker.protocol.version = CURRENT_KAFKA_VERSION（0.11.0，1.0，1.1）。
2. 一次升級一個代理：關閉代理，更新代碼，然后重新啟動。
3. 升級整個群集后，通過編輯inter.broker.protocol.version並將其設置為2.0來增加協議版本。
4. 逐一重新啟動代理，以使新協議版本生效。
5. 如果您已按照上述說明覆蓋了消息格式版本，則需要再進行一次滾動重啟以將其升級到最新版本。將所有（或大多數）使用方升級到0.11.0或更高版本后，請在每個代理上將log.message.format.version更改為2.0，然后逐一重新啟動它們。請注意，較早的Scala使用者不支持0.11中引入的新消息格式，因此，為了避免降低轉換的性能成本（或僅利用一次語義），必須使用較新的Java使用者。

其他升級說明：

1. 如果您願意接受停機時間，則只需關閉所有代理，更新代碼並重新啟動它們即可。默認情況下，它們將從新協議開始。
2. 升級代理后，可以隨時更改協議版本並重新啟動。不必緊隨其后。消息格式版本也是如此。
3. 如果您在Kafka Streams代碼中使用Java8方法引用，則可能需要更新代碼以解決方法的歧義。僅熱交換jar文件可能不起作用。
4. 在更新集群中的所有代理之前，不應將ACL添加到前綴資源（在KIP-290中添加）。

   注意：即使在群集完全升級之后，添加到群集的所有帶前綴的ACL也會被忽略，如果再次降級該群集。

2.0.0的顯着變化

• KIP-186將默認偏移保留時間從1天增加到7天。這使得它不太可能在丟失的應用程序中“丟失”偏移量。它還會增加活動的偏移量集，因此會增加代理上的內存使用量。請注意，控制台使用者當前默認情況下啟用偏移提交，並且可以是大量偏移的來源，此更改現在將保留7天而不是1天。您可以通過將Broker Config設置offsets.retention.minutes為1440 來保留現有行為。
• 對Java 7的支持已刪除，現在Java 8是所需的最低版本。
• 的默認值ssl.endpoint.identification.algorithm已更改為https，以執行主機名驗證（否則，可能會發生中間人攻擊）。設置ssl.endpoint.identification.algorithm為空字符串可恢復以前的行為。
• KAFKA-5674將max.connections.per.ip最小值的下限間隔擴展為零，因此允許基於IP的入站連接篩選。
• KIP-272 已將API版本標記添加到度量kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower|...}。現在，該指標變為kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower|...},version={0|1|2|3|...}。這將影響不會自動聚合的JMX監視工具。為了獲得特定請求類型的總數，該工具需要更新以跨不同版本進行匯總。
• KIP-225更改了指標“ records.lag”以將標簽用於主題和分區。名稱格式為“ {topic}-{partition} .records-lag”的原始版本已被刪除。
• 從0.11.0.0開始不推薦使用的Scala使用者已被刪除。從0.10.0.0開始，推薦使用Java使用者。請注意，即使將代理升級到2.0.0，Scala使用者1.1.0（及更低版本）也將繼續工作。
• 從0.10.0.0版本開始不推薦使用的Scala生產者已被刪除。從0.9.0.0版本開始，推薦使用Java生產者。請注意，Java生產者中默認分區程序的行為與Scala生產者中默認分區程序的行為不同。遷移的用戶應考慮配置保留以前行為的自定義分區程序。請注意，即使將代理升級到2.0.0，1.1.0（及更低版本）中的Scala生產者也將繼續工作。
• MirrorMaker和ConsoleConsumer不再支持Scala使用者，它們始終使用Java使用者。
• ConsoleProducer不再支持Scala生產者，它始終使用Java生產者。
• 刪除了許多依賴Scala客戶端的不推薦使用的工具：ReplayLogProducer，SimpleConsumerPerformance，SimpleConsumerShell，ExportZkOffsets，ImportZkOffsets，UpdateOffsetsInZK，VerifyConsumerRebalance。
• 不推薦使用的kafka.tools.ProducerPerformance已被刪除，請使用org.apache.kafka.tools.ProducerPerformance。
• upgrade.from添加了新的Kafka Streams配置參數，該參數允許從舊版本滾動退回升級。
• KIP-284通過將其默認值設置為，更改了Kafka Streams分區主題的保留時間Long.MAX_VALUE。
• ProcessorStateManagerKafka Streams中更新的API，用於將狀態存儲注冊到處理器拓撲。有關更多詳細信息，請閱讀Streams 升級指南。
• 在早期版本中，Connect的工作程序配置需要internal.key.converter和internal.value.converter屬性。在2.0中，這些不再是必需的，並且默認為JSON轉換器。您可以從Connect獨立和分布式工作程序配置中安全刪除以下屬性：
  internal.key.converter=org.apache.kafka.connect.json.JsonConverter internal.key.converter.schemas.enable=false internal.value.converter=org.apache.kafka.connect.json.JsonConverter internal.value.converter.schemas.enable=false
• KIP-266添加了新的使用者配置，default.api.timeout.ms 以指定用於KafkaConsumer可能阻塞的API 的默認超時。KIP還為此類阻塞API添加了重載，以支持指定用於每個API的特定超時，而不是使用設置的默認超時default.api.timeout.ms。特別是，poll(Duration)添加了一個新API ，該API不會阻止動態分區分配。舊的poll(long)API已被棄用，並將在以后的版本中刪除。重載還添加了其他KafkaConsumer的方法，如partitionsFor，listTopics，offsetsForTimes， beginningOffsets，endOffsets並close表示誠摯的一個Duration。
• 另外，作為KIP-266的一部分，默認值request.timeout.ms已更改為30秒。先前的值略高於5分鍾，以說明重新平衡所需的最長時間。現在，我們將重新平衡中的JoinGroup請求視為一種特殊情況，並使用從中得出 max.poll.interval.ms的請求超時值。所有其他請求類型都使用由定義的超時request.timeout.ms
• 內部方法kafka.admin.AdminClient.deleteRecordsBefore已刪除。鼓勵用戶遷移到org.apache.kafka.clients.admin.AdminClient.deleteRecords。
• AclCommand工具--producer便捷選項在給定主題上使用KIP-277細粒度的ACL。
• KIP-176刪除了--new-consumer所有基於消費者的工具的選項。此選項是多余的，因為如果定義了--bootstrap-server，則會自動使用新使用者。
• KIP-290增加了在前綴資源（例如，以“ foo”開頭的任何主題）上定義ACL的功能。
• KIP-283改進了Kafka代理上的消息下轉換處理，該代理通常是占用大量內存的操作。KIP增加了一種機制，該機制通過一次向下轉換分區數據的塊來降低操作的內存密集度，從而有助於提高內存消耗。通過此改進，FetchResponse協議行為發生了變化， 其中代理可以向響應的結尾發送帶有無效偏移量的超大消息批。消費者客戶端必須忽略此類超大消息，就像一樣KafkaConsumer。

  KIP-283還添加了新的主題和代理配置，message.downconversion.enable並log.message.downconversion.enable分別控制是否啟用了向下轉換。禁用后，代理將不執行任何下轉換，而是向UNSUPPORTED_VERSION 客戶端發送錯誤。

• 在啟動代理之前，可以使用kafka-configs.sh將動態代理配置選項存儲在ZooKeeper中。此選項可用於避免將清晰的密碼存儲在server.properties中，因為所有密碼配置都可以加密存儲在ZooKeeper中。
• 現在，如果連接嘗試失敗，則將重新解析ZooKeeper主機。但是，如果您的ZooKeeper主機名解析為多個地址，但其中一些無法訪問，則可能需要增加連接超時 zookeeper.connection.timeout.ms。

新協議版本

• KIP-279：OffsetsForLeaderEpochResponse v1引入了分區級leader_epoch字段。
• KIP-219：提高由於配額違反而受到限制的非集群操作請求和響應的協議版本。
• KIP-290：修改ACL創建，描述和刪除請求和響應的協議版本。

升級1.1 Kafka Streams應用程序

• 將Streams應用程序從1.1升級到2.0不需要代理升級。Kafka Streams 2.0應用程序可以連接到2.0、1.1、1.0、0.11.0、0.10.2和0.10.1代理（盡管無法連接到0.10.0代理）。
• 請注意，在2.0中，我們刪除了1.0之前不推薦使用的公共API。利用那些已棄用的API的用戶需要相應地更改代碼。有關更多詳細信息，請參見2.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.x或1.0.x升級到1.1.x

Kafka 1.1.0引入了有線協議更改。通過遵循以下建議的滾動升級計划，可以保證升級期間不會停機。但是，請在升級之前查看1.1.0中的顯着更改。

對於滾動升級：

1. 在所有代理上更新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（例如0.8.2、0.9.0、0.10.0、0.10.1、0.10.2、0.11.0、1.0）。
   • log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（有關此配置的詳細信息，請參閱升級后對性能的潛在影響。）
   如果要從0.11.0.x或1.0.x升級，並且尚未覆蓋消息格式，則只需要覆蓋中間經紀人協議格式。
   • inter.broker.protocol.version = CURRENT_KAFKA_VERSION（0.11.0或1.0）。
2. 一次升級一個代理：關閉代理，更新代碼，然后重新啟動。
3. 升級整個群集后，可通過編輯協議版本inter.broker.protocol.version並將其設置為1.1 來提高協議版本。
4. 逐一重新啟動代理，以使新協議版本生效。
5. 如果您已按照上述說明覆蓋了消息格式版本，則需要再進行一次滾動重啟以將其升級到最新版本。一旦所有（或大多數）使用者都升級到0.11.0或更高版本，請在每個代理上將log.message.format.version更改為1.1，然后逐一重新啟動它們。請注意，較早的Scala使用者不支持0.11中引入的新消息格式，因此，為了避免降低轉換的性能成本（或僅利用一次語義），必須使用較新的Java使用者。

其他升級說明：

1. 如果您願意接受停機時間，則只需關閉所有代理，更新代碼並重新啟動它們即可。默認情況下，它們將從新協議開始。
2. 升級代理后，可以隨時更改協議版本並重新啟動。不必緊隨其后。消息格式版本也是如此。
3. 如果您在Kafka Streams代碼中使用Java8方法引用，則可能需要更新代碼以解決方法的歧義。僅熱交換jar文件可能不起作用。

1.1.1的顯着變化

• upgrade.from添加了新的Kafka Streams配置參數，該參數允許從0.10.0.x版進行滾動跳動升級
• 有關此新配置的詳細信息，請參見Kafka Streams升級指南。

1.1.0的顯着變化

• Maven中的kafka工件不再依賴於log4j或slf4j-log4j12。與kafka-clients工件類似，用戶現在可以通過包括適當的slf4j模塊（slf4j-log4j12，logback等）來選擇日志記錄后端。發行版tarball仍然包括log4j和slf4j-log4j12。
• KIP-225更改了指標“ records.lag”以將標簽用於主題和分區。名稱格式為“ {topic}-{partition} .records-lag”的原始版本已棄用，並將在2.0.0中刪除。
• Kafka Streams對於代理通信錯誤更強大。Kafka Streams不會自我修復並重新連接到群集，而不是在發生致命異常時停止Kafka Streams客戶端。使用新版本，AdminClient您可以更好地控制Kafka Streams重試的頻率，並且可以配置 細粒度的超時（而不是像舊版本中那樣進行硬編碼重試）。
• Kafka Streams的重新平衡時間進一步減少，使Kafka Streams的響應速度更快。
• Kafka Connect現在在接收器和源連接器中都支持消息頭，並通過簡單的消息轉換對其進行操作。必須更改連接器以顯式使用它們。HeaderConverter引入了新的控件來控制標題的序列化（反序列化），默認情況下使用新的“ SimpleHeaderConverter”來使用值的字符串表示形式。
• 如果由於其他任何選項（例如解碼器）而顯式或隱式啟用了print-data-log，則kafka.tools.DumpLogSegments現在會自動設置深度迭代選項。

新協議版本

• KIP-226引入了DescribeConfigs請求/響應v1。
• KIP-227引入了獲取請求/響應v7。

升級1.0 Kafka Streams應用程序

• 將Streams應用程序從1.0升級到1.1不需要代理升級。Kafka Streams 1.1應用程序可以連接到1.0、0.11.0、0.10.2和0.10.1代理（盡管無法連接到0.10.0代理）。
• 有關更多詳細信息，請參見1.1.0中的Streams API更改。

從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

Kafka 1.0.0引入了有線協議更改。通過遵循以下建議的滾動升級計划，可以保證升級期間不會停機。但是，請在升級前查看1.0.0中的顯着更改。

對於滾動升級：

1. 在所有代理上更新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（例如0.8.2、0.9.0、0.10.0、0.10.1、0.10.2、0.11.0）。
   • log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（有關此配置的詳細信息，請參閱升級后對性能的潛在影響。）
   如果要從0.11.0.x升級，並且尚未覆蓋消息格式，則必須同時將消息格式版本和代理間協議版本設置為0.11.0。
   • inter.broker.protocol.version = 0.11.0
   • log.message.format.version = 0.11.0
2. 一次升級一個代理：關閉代理，更新代碼，然后重新啟動。
3. 升級整個群集后，可通過編輯協議版本inter.broker.protocol.version並將其設置為1.0來增加協議版本。
4. 逐一重新啟動代理，以使新協議版本生效。
5. 如果您已按照上述說明覆蓋了消息格式版本，則需要再進行一次滾動重啟以將其升級到最新版本。將所有（或大多數）使用方升級到0.11.0或更高版本后，請在每個代理上將log.message.format.version更改為1.0，然后逐一重新啟動它們。如果要從0.11.0升級，並且log.message.format.version設置為0.11.0，則可以更新配置並跳過滾動重啟。請注意，較早的Scala使用者不支持0.11中引入的新消息格式，因此，為了避免降低轉換的性能成本（或僅利用一次語義），必須使用較新的Java使用者。

其他升級說明：

1. 如果您願意接受停機時間，則只需關閉所有代理，更新代碼並重新啟動它們即可。默認情況下，它們將從新協議開始。
2. 升級代理后，可以隨時更改協議版本並重新啟動。不必緊隨其后。消息格式版本也是如此。

1.0.2的顯着變化

• upgrade.from添加了新的Kafka Streams配置參數，該參數允許從0.10.0.x版進行滾動跳動升級
• 有關此新配置的詳細信息，請參見Kafka Streams升級指南。

1.0.1的顯着變化

• 使用0.11.0.x恢復了AdminClient的Options類（例如CreateTopicsOptions，DeleteTopicsOptions等）的二進制兼容性。二進制（但不是源代碼）兼容性在1.0.0中被無意間破壞了。

1.0.0的顯着變化

• 由於功能穩定，現在默認情況下啟用主題刪除。希望保留先前行為的用戶應將Broker Config設置delete.topic.enable為false。請記住，主題刪除會刪除數據，並且該操作不可逆（即，沒有“取消刪除”操作）
• 對於支持時間戳搜索（如果找不到某個分區的偏移量）的主題，該分區現在包含在搜索結果中，且偏移量值為空。以前，該分區未包含在地圖中。進行此更改是為了使搜索行為與不支持時間戳搜索的主題一致。
• 如果inter.broker.protocol.version是1.0或更高版本，則即使存在脫機日志目錄，代理現在仍將保持聯機狀態以為實時日志目錄提供副本。由於硬件故障導致IOException，日志目錄可能會脫機。用戶需要監視每個代理的指標，offlineLogDirectoryCount以檢查是否存在脫機日志目錄。
• 添加了KafkaStorageException，它是可重試的異常。如果客戶端的FetchRequest或ProducerRequest的版本不支持KafkaStorageException，則KafkaStorageException將在響應中轉換為NotLeaderForPartitionException。
• 在默認的JVM設置中，-XX：+ 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將被棄用，並替換為提供這些屬性的度量。
• Kafka指標現在可能包含非數字值。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中的軟件包已公開，並已添加到javadocs中。以前位於此程序包中的內部類已移至其他位置。
• 當使用授權者並且用戶對主題沒有必需的權限時，無論代理上是否存在主題，代理都將向請求返回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，則將使用此請求。

升級0.11.0 Kafka Streams應用程序

• 將Streams應用程序從0.11.0升級到1.0不需要代理升級。Kafka Streams 1.0應用程序可以連接到0.11.0、0.10.2和0.10.1代理（盡管無法連接到0.10.0代理）。但是，Kafka Streams 1.0需要0.10或更高版本的消息格式，並且不適用於較舊的消息格式。
• 如果要監視流指標，則需要更改報告和監視代碼中的指標名稱，因為指標傳感器的層次結構已更改。
• 有一些公共的API，包括ProcessorContext#schedule()，Processor#punctuate()和KStreamBuilder，TopologyBuilder正在被新的API棄用。我們建議您進行相應的代碼更改，這應該很小，因為升級時新的API看起來非常相似。
• 有關更多詳細信息，請參見1.0.0中的Streams API更改。

升級0.10.2 Kafka Streams應用程序

• 將Streams應用程序從0.10.2升級到1.0不需要代理升級。Kafka Streams 1.0應用程序可以連接到1.0、0.11.0、0.10.2和0.10.1代理（盡管無法連接到0.10.0代理）。
• 如果要監視流指標，則需要更改報告和監視代碼中的指標名稱，因為指標傳感器的層次結構已更改。
• 有一些公共的API，包括ProcessorContext#schedule()，Processor#punctuate()和KStreamBuilder，TopologyBuilder正在被新的API棄用。我們建議您進行相應的代碼更改，這應該很小，因為升級時新的API看起來非常相似。
• 如果指定自定義key.serde，value.serde並timestamp.extractor在CONFIGS，推薦使用他們更換配置參數，因為這些CONFIGS已被棄用。
• 有關更多詳細信息，請參見0.11.0中的Streams API更改。

升級0.10.1 Kafka Streams應用程序

• 將您的Streams應用程序從0.10.1升級到1.0不需要代理升級。Kafka Streams 1.0應用程序可以連接到1.0、0.11.0、0.10.2和0.10.1代理（盡管無法連接到0.10.0代理）。
• 您需要重新編譯代碼。只是交換Kafka Streams庫jar文件將不起作用，並且會破壞您的應用程序。
• 如果要監視流指標，則需要更改報告和監視代碼中的指標名稱，因為指標傳感器的層次結構已更改。
• 有一些公共的API，包括ProcessorContext#schedule()，Processor#punctuate()和KStreamBuilder，TopologyBuilder正在被新的API棄用。我們建議您進行相應的代碼更改，這應該很小，因為升級時新的API看起來非常相似。
• 如果指定自定義key.serde，value.serde並timestamp.extractor在CONFIGS，推薦使用他們更換配置參數，因為這些CONFIGS已被棄用。
• 如果使用自定義（即用戶實現的）時間戳提取器，則由於TimestampExtractor接口已更改，因此需要更新此代碼。
• 如果注冊自定義指標，則由於StreamsMetric界面已更改，因此需要更新此代碼。
• 有關更多詳細信息，請參見1.0.0中的 Streams API更改，0.11.0中的Streams API更改和 0.10.2中的Streams API更改。

升級0.10.0 Kafka Streams應用程序

• 將您的Streams應用程序從0.10.0升級到1.0確實需要代理升級，因為Kafka Streams 1.0應用程序只能連接到0.1、0.11.0、0.10.2或0.10.1代理。
• 有幾個API的變化，這是不向后兼容（參見流API中1.0.0的變化， 在0.11.0流API的變化， 在0.10.2流API的變化，和 流API的變化在0.10.1了解更多詳情）。因此，您需要更新並重新編譯代碼。只是交換Kafka Streams庫jar文件將不起作用，並且會破壞您的應用程序。
• 從0.10.0.x升級到1.0.2要求兩次滾動反彈，upgrade.from="0.10.0"並為第一個升級階段設置了配置（請參閱KIP-268）。或者，也可以進行脫機升級。
  • 准備應用程序實例以進行滾動彈跳，並確保將config upgrade.from設置"0.10.0"為新版本0.11.0.3
  • 反彈應用程序的每個實例一次
  • 准備新部署的1.0.2應用程序實例以進行第二輪滾動彈跳；確保刪除配置的值upgrade.mode
  • 再次彈跳應用程序的每個實例以完成升級
• 從0.10.0.x升級到1.0.0或1.0.1需要脫機升級（不支持滾動退回升級）
  • 停止所有舊的（0.10.0.x）應用程序實例
  • 更新您的代碼，並用新代碼和新jar文件交換舊代碼和jar文件
  • 重新啟動所有新的（1.0.0或1.0.1）應用程序實例

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

Kafka 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在CONFIGS，推薦使用他們更換配置參數，因為這些CONFIGS已被棄用。
• 有關更多詳細信息，請參見0.11.0中的Streams API更改。

升級0.10.1 Kafka Streams應用程序

• 將您的Streams應用程序從0.10.1升級到0.11.0不需要代理升級。Kafka Streams 0.11.0應用程序可以連接到0.11.0、0.10.2和0.10.1代理（盡管無法連接到0.10.0代理）。
• 您需要重新編譯代碼。只是交換Kafka Streams庫jar文件將不起作用，並且會破壞您的應用程序。
• 如果指定自定義key.serde，value.serde並timestamp.extractor在CONFIGS，推薦使用他們更換配置參數，因為這些CONFIGS已被棄用。
• 如果使用自定義（即用戶實現的）時間戳提取器，則由於TimestampExtractor接口已更改，因此需要更新此代碼。
• 如果注冊自定義指標，則由於StreamsMetric界面已更改，因此需要更新此代碼。
• 有關更多詳細信息，請參見0.11.0中的Streams API更改和 0.10.2中的Streams API更改。

升級0.10.0 Kafka Streams應用程序

• 將Streams應用程序從0.10.0升級到0.11.0確實需要代理升級，因為Kafka Streams 0.11.0應用程序只能連接到0.11.0、0.10.2或0.10.1代理。
• 有幾個API的變化，這是不向后兼容（參見流API變化0.11.0， 在0.10.2流API的變化，並 在0.10.1流API的變化有詳細介紹）。因此，您需要更新並重新編譯代碼。只是交換Kafka Streams庫jar文件將不起作用，並且會破壞您的應用程序。
• 從0.10.0.x升級到0.11.0.3需要兩次滾動反彈，upgrade.from="0.10.0"並為第一個升級階段設置了配置（請參閱KIP-268）。或者，也可以進行脫機升級。
  • 准備應用程序實例以進行滾動彈跳，並確保將config upgrade.from設置"0.10.0"為新版本0.11.0.3
  • 反彈應用程序的每個實例一次
  • 准備新部署的0.11.0.3應用程序實例，以進行第二輪滾動彈跳；確保刪除配置的值upgrade.mode
  • 再次彈跳應用程序的每個實例以完成升級
• 從0.10.0.x升級到0.11.0.0、0.11.0.1或0.11.0.2需要脫機升級（不支持滾動退回升級）
  • 停止所有舊的（0.10.0.x）應用程序實例
  • 更新您的代碼，並用新代碼和新jar文件交換舊代碼和jar文件
  • 重新啟動所有新的（0.11.0.0，0.11.0.1或0.11.0.2）應用程序實例

0.11.0.3的顯着變化

• upgrade.from添加了新的Kafka Streams配置參數，該參數允許從0.10.0.x版進行滾動跳動升級
• 有關此新配置的詳細信息，請參見Kafka Streams升級指南。

0.11.0.0中的顯着變化

• 默認情況下，不干凈的領導者選舉現在是禁用的。新的默認設置優先考慮耐用性而不是可用性。希望保留先前行為的用戶應將Broker Config設置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，以提高壓縮率。有報告說，以較小的塊大小壓縮的數據比以較大的塊大小壓縮的數據大50％。對於敏捷的情況，具有5000個分區的生產者將需要額外315 MB的JVM堆。
• 同樣，使用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（這是一種不好的做法）。
• Streams API配置參數timestamp.extractor，key.serde和value.serde已被棄用，並分別由default.timestamp.extractor，和代替。 default.key.serdedefault.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字段。

關於完全語義的注釋

Kafka 0.11.0包含對生產者中冪等和事務處理功能的支持。冪等傳遞確保在單個生產者的生存期內，消息僅精確地傳遞到特定主題分區一次。事務傳遞使生產者可以將數據發送到多個分區，以便成功傳遞所有消息或不傳遞任何消息。這些功能共同使Kafka中的語義“恰好一次”。用戶指南中提供了有關這些功能的更多詳細信息，但是下面我們添加了一些有關在升級的群集中啟用它們的特定說明。請注意，不需要啟用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中新消息格式的說明

0.11.0消息格式包括幾個主要增強功能，以支持生產者更好的傳遞語義（請參閱KIP-98）和改進的復制容錯能力（請參閱KIP-101）。盡管新格式包含更多信息以使這些改進成為可能，但我們使批處理格式更加有效。只要每批的消息數大於2，您就可以期望總體開銷較低。但是，對於較小的批次，可能會對性能產生較小的影響。請參閱此處以了解我們對新消息格式的初步性能分析的結果。您還可以在KIP-98提案中找到有關消息格式的更多詳細信息 。

新消息格式的顯着差異之一是，即使未壓縮的消息也作為一個批次存儲在一起。這對代理配置有一些影響，代理配置max.message.bytes限制了單個批處理的大小。首先，如果較舊的客戶端使用舊格式將消息生成到主題分區，並且這些消息分別小於max.message.bytes，則在上轉換過程中將消息 合並為單個批處理后，代理仍然可以拒絕它們。通常，當單個郵件的總大小大於時，就會發生這種情況max.message.bytes。對於年長的消費者來說，閱讀從新格式向下轉換后的消息會有類似的效果：如果獲取大小未設置為至少等於 max.message.bytes，即使個別未壓縮的消息小於配置的提取大小，使用方也可能無法取得進展。對於0.10.1.0及更高版本，此行為不會影響Java客戶端，因為它使用了更新的提取協議，該協議確保即使超過了提取大小，也至少可以返回一條消息。要解決這些問題，您應確保1）生產者的批量大小不設置為大於max.message.bytes2，消費者的獲取大小至少設置為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.0 Kafka Streams應用程序

• 將您的Streams應用程序從0.10.0升級到0.10.2確實需要升級代理，因為Kafka Streams 0.10.2應用程序只能連接到0.10.2或0.10.1代理。
• 有一些API更改，它們不向后兼容（請參閱0.10.2中的Streams API更改以獲取更多詳細信息）。因此，您需要更新並重新編譯代碼。只是交換Kafka Streams庫jar文件將不起作用，並且會破壞您的應用程序。
• 從0.10.0.x升級到0.10.2.2需要兩次滾動反彈，upgrade.from="0.10.0"並為第一個升級階段設置了配置（請參閱KIP-268）。或者，也可以進行脫機升級。
  • 准備應用程序實例以進行滾動彈跳，並確保將config upgrade.from設置"0.10.0"為新版本0.10.2.2
  • 反彈應用程序的每個實例一次
  • 准備新部署的0.10.2.2應用程序實例以進行第二輪滾動彈跳；確保刪除配置的值upgrade.mode
  • 再次彈跳應用程序的每個實例以完成升級
• 從0.10.0.x升級到0.10.2.0或0.10.2.1需要離線升級（不支持滾動退回升級）
  • 停止所有舊的（0.10.0.x）應用程序實例
  • 更新您的代碼，並用新代碼和新jar文件交換舊代碼和jar文件
  • 重新啟動所有新的（0.10.2.0或0.10.2.1）應用程序實例

0.10.2.2中的顯着變化

• upgrade.from添加了新的配置參數，該參數允許從0.10.0.x版進行滾動退回升級

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以控制最大等待時間。
• 可以將新的Java使用者通過--whitelist選項將多個用逗號分隔的正則表達式傳遞給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 Kafka Streams Configs。

新協議版本

• KIP-88：如果將topics數組設置為，則OffsetFetchRequest v2支持檢索所有主題的偏移量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中的Streams API更改以獲取更多詳細信息）。因此，您需要更新並重新編譯代碼。只是交換Kafka Streams庫jar文件將不起作用，並且會破壞您的應用程序。
• 從0.10.0.x升級到0.10.1.2需要兩次滾動反彈，upgrade.from="0.10.0"並為第一個升級階段設置了配置（請參閱KIP-268）。或者，也可以進行脫機升級。
  • 准備應用程序實例以進行滾動彈跳，並確保將config upgrade.from設置"0.10.0"為新版本0.10.1.2
  • 反彈應用程序的每個實例一次
  • 准備新部署的0.10.1.2應用程序實例，以進行第二輪滾動彈跳；確保刪除配置的值upgrade.mode
  • 再次彈跳應用程序的每個實例以完成升級
• 從0.10.0.x升級到0.10.1.0或0.10.1.1需要離線升級（不支持滾動退回升級）
  • 停止所有舊的（0.10.0.x）應用程序實例
  • 更新您的代碼，並用新代碼和新jar文件交換舊代碼和jar文件
  • 重新啟動所有新的（0.10.1.0或0.10.1.1）應用程序實例

0.10.1.0的顯着變化

• 新的Java使用者不再處於beta中，我們建議所有新開發人員使用它。仍然支持舊的Scala使用者，但是它們將在下一個版本中棄用，並在以后的主要版本中將其刪除。
• 將--new-consumer/ --new.consumer開關不再需要使用的工具，像MirrorMaker和控制台與消費者新的消費; 只需通過Kafka經紀人即可連接，而不是ZooKeeper集成。此外，已不建議將Console Consumer與舊的Consumer一起使用，並且在將來的主要版本中將其刪除。
• 現在，可以通過集群ID唯一地標識Kafka集群。當代理升級到0.10.1.0時，它將自動生成。可以通過kafka.server：type = KafkaServer，name = ClusterId指標獲得集群ID，它是元數據響應的一部分。序列化程序，客戶端攔截器和度量標准報告程序可以通過實現ClusterResourceListener接口來接收群集ID。
• BrokerState“ RunningAsController”（值4）已被刪除。由於存在錯誤，代理在過渡之前僅會短暫處於此狀態，因此刪除的影響應最小。推薦的檢測給定代理是否為控制器的方法是通過kafka.controller：type = KafkaController，name = ActiveControllerCount指標。
• 新的Java使用者現在允許用戶按分區上的時間戳搜索偏移量。
• 新的Java Consumer現在支持從后台線程進行心跳。有一個新的配置 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高級消費者和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格式轉換為較早的格式，然后再將響應發送給較舊版本的使用者。但是，在這種情況下，代理不能使用零拷貝傳輸。Kafka社區有關性能影響的報告顯示，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以獲得更好的吞吐量。另外，用於壓縮具有活潑消息的生產者緩沖區小於代理使用的生產者緩沖區，這可能會對磁盤上​​消息的壓縮率產生負面影響。我們打算在以后的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，默認情況下使用它來支持消息格式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]])方法，因為它從未被調用過。
• Kafka不再打包0.7 KafkaMigrationTool。如果需要從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框架實現。使用生產/獲取協議v2或更高版本的客戶端應使用可互操作的LZ4f成幀。可互操作的LZ4庫列表可在http://www.lz4.org/獲得。

0.10.0.0的顯着變化

• 從Kafka 0.10.0.0開始，一個名為Kafka Streams的新客戶端庫可用於對存儲在Kafka主題中的數據進行流處理。由於上述消息格式的更改，此新客戶端庫僅適用於0.10.x和更高版本的代理。有關更多信息，請閱讀Streams文檔。
• receive.buffer.bytes現在，新使用者的配置參數的默認值為64K。
• 現在，新使用者可以公開配置參數，exclude.internal.topics以限制內部主題（例如使用者偏移量主題）不被意外包含在正則表達式預訂中。默認情況下，它是啟用的。
• 舊的Scala生產商已被棄用。用戶應盡快將其代碼遷移到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。
• 不再支持Scala 2.9。
• 現在默認將大於1000的代理ID保留為自動分配的代理ID。如果您的集群中現有的代理ID超過該閾值，請確保相應地增加reserved.broker.max.id代理配置屬性。
• 配置參數copy.lag.max.messages已刪除。在確定哪些副本同步時，分區負責人將不再考慮滯后消息的數量。
• 配置參數copy.lag.time.max.ms現在不僅指自從上次從副本獲取請求以來經過的時間，而且還指自副本上一次被捕獲以來的時間。仍在從領導者那里獲取消息但未趕上copy.lag.time.max.ms中最新消息的副本將被視為不同步。
• 壓縮的主題不再接受沒有密鑰的消息，如果嘗試這樣做，生產者將引發異常。在0.8.x中，沒有密鑰的消息將導致日志壓縮線程隨后抱怨並退出（並停止壓縮所有壓縮的主題）。
• MirrorMaker不再支持多個目標群集。結果，它將僅接受一個--consumer.config參數。要鏡像多個源集群，每個源集群至少需要一個MirrorMaker實例，每個實例都有自己的使用者配置。
• org.apache.kafka.clients.tools。*下打包的工具已移至org.apache.kafka.tools。*。所有包含的腳本仍將照常運行，僅直接導入這些類的自定義代碼將受到影響。
• 默認的Kafka JVM性能選項（KAFKA_JVM_PERFORMANCE_OPTS）已在kafka-run-class.sh中更改。
• 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的主題現在將默認壓縮，並且將通過log.cleaner.dedupe.buffer.size將128 MB的堆分配給清理程序。您可能要根據壓縮主題的使用情況來查看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，並且meta.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升級到更高版本需要專用的遷移工具。無需停機即可進行遷移。