Kafka 2.5.0發佈——棄用對Scala2.11的支持

近日Kafka發佈了最新版本 2.5.0，增長了不少新功能：

下載地址：https://kafka.apache.org/downloads#2.5.0

• 對TLS 1.3的支持（默認爲1.2）

• 引入用於 Kafka Streams 的 Co-groups

• 用於 Kafka Consumer 的增量 rebalance 機制

• 爲更好的監控操做增長了新的指標

• 升級Zookeeper至 3.5.7

• 取消了對Scala 2.1.1的支持

下面詳細說明本次更新:

1、新功能

一、Kafka Streams: Add Cogroup in the DSL

當多個流彙集在一塊兒以造成單個較大的對象時（例如，購物網站可能具備購物車流，心願單流和購買流。它們共同構成一個客戶），將其在Kafka Streams DSL中使用很是困難。

一般須要您將全部流分組並聚合到KTables，而後進行多個外部聯接調用，最後獲得具備所需對象的KTable。這將爲每一個流和一長串ValueJoiners建立一個狀態存儲，每一個新記錄都必須通過此鏈接才能到達最終對象。

建立使用單個狀態存儲的Cogroup 方法將：

• 減小從狀態存儲獲取的數量。對於多個聯接，當新值進入任何流時，都會發生連鎖反應，聯接處理器將繼續調用ValueGetters，直到咱們訪問了全部狀態存儲。

• 性能略有提升。如上所述，全部ValueGetters都被調用，還致使全部ValueJoiners被調用，從而強制從新計算全部其餘流的當前聯接值，從而影響性能。

二、Add support for TLS 1.3

Java 11添加了對TLS 1.3的支持。添加對Java 11的支持後，咱們應該對此提供支持。

三、再也不支持Scala 2.11

爲何再也不支持？

咱們目前爲3個Scala版本構建Kafka：2.十一、2.12和最近發佈的2.13。因爲咱們必須在每一個受支持的版本上編譯和運行測試，所以從開發和測試的角度來看，這是一筆不小的成本。

Scala 2.11.0於2014年4月發佈，對2.11.x的支持於2017年11月結束（到發佈Kafka 2.5時將超過2年）。Scala 2.12.0於2016年11月發佈，Scala 2.13.0於2019年6月發佈。基於此，如今該放棄對Scala 2.11的支持了，以便咱們使測試矩陣易於管理（最近的kafka-trunk-jdk8佔用了將近10個小時，它將使用3個Scala版本構建並運行單元測試和集成測試。此外，Scala 2.12和更高版本還改進了與Java 8功能接口的互操做性（Scala 2.12中首次引入）。更具體地說，Scala 2.12中的lambda能夠與Java 8代碼相同的方式與Java 8功能接口一塊兒使用。

在咱們的下載頁面中，咱們推薦自Kafka 2.1.0起使用Scala 2.12構建的Kafka二進制文件。咱們切換到Scala 2.12做爲Kafka 2.2.0中源tarball，構建和系統測試的默認Scala版本。

2、改進與修復

• 當輸入 topic 事務時，Kafka Streams lag 不爲 0
• Kafka-streams 可配置內部 topics message.timestamp.type=CreateTime
• 將 KStream#toTable 添加到 Streams DSL
• 將 Commit/List Offsets 選項添加到 AdminClient
• 將 VoidSerde 添加到 Serdes
• 改進 Sensor Retrieval

[KAFKA-3061] 修復Guava依賴問題

[KAFKA-4203] Java生產者默認的最大消息大小再也不與broker默認一致

[KAFKA-5868] kafka消費者reblance時間過長問題

詳細更新內容點此查看

3、其餘版本升級至2.5.0指南

若是要從2.1.x以前的版本升級，請參閱如下注釋，以瞭解用於存儲偏移量的架構的更改。將inter.broker.protocol.version更改成最新版本後，將沒法降級到2.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（例如0.10.0、0.11.0、1.0、2.0、2.2）。
• log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION
• 若是要從0.11.0.x或更高版本升級，而且還沒有覆蓋消息格式，則只須要覆蓋Broker間協議版本。
  • inter.broker.protocol.version = CURRENT_KAFKA_VERSION（0.11.0，1.0，1.1，2.0，2.1，2.2，2.3）。
• 一次升級一個Broker：關閉Broker，更新代碼，而後從新啓動。完成此操做後，Broker將運行最新版本，而且您能夠驗證集羣的行爲和性能是否符合預期。若是有任何問題，此時仍能夠降級。
• 驗證羣集的行爲和性能後，經過編輯inter.broker.protocol.version並將其設置爲2.5來提升協議版本 。
• 逐一從新啓動Broker，以使新協議版本生效。Broker開始使用最新協議版本後，將沒法再將羣集降級到較舊版本。
• 若是您已按照上述說明覆蓋了消息格式版本，則須要再次滾動重啓以將其升級到最新版本。一旦全部（或大多數）使用者均已升級到0.11.0或更高版本，則在每一個Broker上將log.message.format.version更改成2.5，而後逐一從新啓動它們。請注意，再也不維護的較舊的Scala客戶端不支持0.11中引入的消息格式，所以，爲避免轉換成本，必須使用較新的Java客戶端。

2.5.0主要的變化，可能產生的升級影響

• 當RebalanceProtocol#COOPERATIVE使用時，Consumer#poll仍然能夠返回數據，此外， Consumer#commitSync如今能夠拋出RebalanceInProgressException來通知用戶此類事件，CommitFailedException並容許用戶完成正在進行的Reblance，而後從新嘗試爲那些仍然擁有的分區提交偏移量。
• 爲了提升典型網絡環境中的彈性，默認值 zookeeper.session.timeout.ms已從6s增長到18s， replica.lag.time.max.ms從10s增長到30s。
• cogroup()添加了新的DSL運營商，用於一次將多個流聚合在一塊兒。
• 添加了新的KStream.toTable()API，可將輸入事件流轉換爲KTable。
• 添加了新的Serde類型Void以表示輸入主題中的空鍵或空值。
• 棄用UsePreviousTimeOnInvalidTimestamp並替換爲UsePartitionTimeOnInvalidTimeStamp。
• 經過添加掛起的偏移防禦機制和更強大的事務提交一致性檢查，改進了一次精確語義，這大大簡化了可伸縮的一次精確應用程序的實現。
• 棄用KafkaStreams.store(String, QueryableStoreType)並替換爲KafkaStreams.store(StoreQueryParameters)。
• 再也不支持Scala 2.11。
• 軟件包中的全部Scala類kafka.security.auth均已棄用。請注意，在2.4.0中已棄用kafka.security.auth.Authorizer 和kafka.security.auth.SimpleAclAuthorizer。
• 默認狀況下，TLSv1和TLSv1.1已被禁用，由於它們具備已知的安全漏洞。如今默認狀況下僅啓用TLSv1.2。您能夠經過在配置選項ssl.protocol和中明確啓用它們來繼續使用TLSv1和TLSv1.1 ssl.enabled.protocols。
• ZooKeeper已升級到3.5.7，而且若是3.4數據目錄中沒有快照文件，則ZooKeeper從3.4.X升級到3.5.7可能會失敗。這一般發生在測試升級中，其中ZooKeeper 3.5.7嘗試加載沒有建立快照文件的現有3.4數據目錄。有關問題請參考：https://issues.apache.org/jira/browse/ZOOKEEPER-3056
• ZooKeeper 3.5.7版支持有或沒有客戶端證書的TLS加密的到ZooKeeper的鏈接，而且可使用其餘Kafka配置來利用此功能。