49
人物
《KAFKA官方文檔》入門指南（五）
- ListOffsetRequest V1支持精確的基於時間戳的偏移搜索。
- MetadataResponse V2引入了一個新的參數： “CLUSTER_ID”。
- FetchRequest v3支持限製請求返回的大小（除了現有的每個分區的限製），它能夠返回比限製更大的消息和在請求中加入分區的順序具有重要意義。
- JoinGroup V1引入了一個新的字段： “rebalance_timeout”。
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.4或0.9.0.1客戶端沒有必要。
對於滾動升級：
- 更新所有代理服務器的server.properties文件，並添加以下屬性：
- inter.broker.protocol.version = CURRENT_KAFKA_VERSION（例如0.8.2或0.9.0.0）。
- log.message.format.version = CURRENT_KAFKA_VERSION（參見升級後的潛在性能的影響對於此配置做什麼的詳細信息。）
- 升級代理。這可以通過簡單地將其關機，更新代碼，並重新啟動實現。
- 一旦整個群集升級結束，通過編輯inter.broker.protocol.version並將其設置為0.10.0.0的協議版本。注意：您不應該修改log.message.format.version — 這個參數隻能在所有的消費者都已經升級到0.10.0.0之後再修改。
- 逐一重新啟動代理，新協議版本生效。
- 一旦所有的消費者都已經升級到0.10.0，逐一修改log.message.format.version至0.10.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客戶，沒有性能影響。
注：設置消息格式版本是一個證明，現有的所有支持的消息都在這個版本或低於該消息格式的版本。否則， 0.10.0.0之前的消費者可能不能正常工作。特別是消息格式設置為0.10.0之後，不應該再改回先前的格式，因為它可能使得0.10.0.0之前的消費者工作異常。
注：由於每個消息中引入了另外的時間戳，生產者發送的消息大小比較小的時候因為額外的負載開銷也許會看到吞吐量的下降。同樣，副本的複製會讓每個消息額外傳輸8個字節。如果你正在運行接近集群承載能力的網絡容量，你可能會壓垮網卡，由於超載而發生故障和性能問題。
注：如果您已對生產者啟用壓縮算法，您可能會注意到降低的生產者吞吐量和/或在某些情況下代理降低的壓縮比。當接收到壓縮的消息，0.10.0代理避免再次壓縮消息，其通常降低了等待時間，並提高了吞吐量。在某些情況下，這可能會減少生產者批量消息包的大小，這可能導致更糟糕的吞吐量。如果發生這種情況，用戶可以調整生產者的linger.ms和batch.size以獲得更好的吞吐量。此外，用於高效壓縮消息的生產者緩衝區比代理使用的緩衝區小，這可能對磁盤的壓縮消息比率有負麵的影響。我們打算在未來的Kafka版本中能夠配置這些參數。
- 從Kafka0.10.0.0開始，Kafka消息格式的版本被表示為Kafka版本。例如，消息格式0.9.0指通過Kafka0.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]])，因為它從來沒有被調用。
- 0.7 KafkaMigrationTool不再被打包進Kafka包。如果您需要從0.7遷移到0.10.0，請先遷移到0.8，然後再按照文檔的升級過程升級0.8到0.10.0。
- 新的消費者擁有標準化的API，接受java.util.Collection作為方法參數序列類型。現有的代碼可能需要更新才能與0.10.0客戶端庫一起工作。
- LZ4-compressed的消息處理被改變為使用可互操作的幀規範（LZ4f V1.5.1）。為了保持與舊客戶端的兼容性，這一變化僅適用於消息格式0.10.0及更高版本。使用V0 / V1（消息格式0.9.0）的客戶端應該繼續使用0.9.0幀規範實現執行產生/抓取LZ4壓縮消息。使用生產/獲取協議v2或更高版本客戶端應該使用互操作LZ4f幀規範。可互操作的LZ4庫的列表，請參考https://www.lz4.org/
- 從Kafka0.10.0.0開始，新的客戶端庫Kafka流可用於流處理存儲在Kafka主題的數據。這個新的客戶端庫隻適用於0.10.x及後麵版本的代理。欲了解更多信息，請閱讀流文件。
- 對新的消費者，配置參數receive.buffer.bytes的默認值現在是64k。
- 新的消費者現在公開暴露配置參數exclude.internal.topics去限製內部主題（諸如消費者偏移主題），不讓這些主題被偶然的包括在正則表達式的主題訂閱中。默認情況下，它處於啟用狀態。
- 老Scala生產者已被棄用。用戶要盡快遷移他們的代碼到Kafka客戶端JAR裏的Java生產者。
- 新的消費者API已經被標記為穩定。
升級0.8.0，0.8.1.X或0.8.2.X到0.9.0.0
0.9.0.0具有的潛在的重大更改（請在升級前檢查），還有以前的版本到現在的代理間協議的變化。這意味著升級的代理和客戶端可能不兼容舊版本。您在升級您的客戶端之前升級Kafka集群是很重要的。如果您正在使用MirrorMaker下遊集群應該先升級為好。
對於滾動升級：
- 更新所有代理上的server.properties文件，並添加以下屬性：inter.broker.protocol.version = 0.8.2.X
- 逐一升級的代理。可以通過簡單地將其關閉，更新代碼，並重新啟動它實現。
- 一旦整個群集升級成功，通過編輯inter.broker.protocol.version並將其設置為0.9.0.0的協議版本。
- 逐一重新啟動代理使新協議版本生效
注意：如果你願意接受宕機，你可以簡單地把所有的代理服務器關閉，更新代碼，然後重新啟動他們。他們將默認使用新的協議。
注：改變協議版本並重新啟動可以在代理服務器升級之後的任何時間做，沒有必要必須立刻就做。
- Java 1.6不再支持。
- Scala 2.9不再支持。
- 1000以上的代理ID現在默認保留，用來做自動分配的代理ID。如果您的集群已存在高於閾值的經紀人的ID確保相應地增加reserved.broker.max.id代理配置屬性。
- 配置參數replica.lag.max.messages被刪除。分區Leader將不再考慮滯後的消息數量來決定哪些副本是同步的，。
- 配置參數replica.lag.time.max.ms現在不僅指從副本提取請求所花費的時間，也標識副本最後一次同步到現在經過的時間。那些副本仍然從領導者獲取信息，但在replica.lag.time.max.ms時間內沒有從leader最新消息的副本將被認為是不同步的。
- 壓縮主題不再接受沒有主鍵消息和遇到這種情況生產者會拋出一個異常。在0.8.4，沒有主鍵的消息會導致日誌壓縮線程退出（並停止所有壓縮主題的處理）。
- MirrorMaker不再支持多種目標集群。因此，它隻能接受一個–consumer.config參數。要鏡像多個源集群，則需要每個源集群至少一個MirrorMaker實例，每個都有自己的消費者配置。
- 在包org.apache.kafka.clients.tools.*裏的工具已移至org.apache.kafka.tools.*包。所有的其中的腳本將仍然像往常一樣起作用，隻是直接導入這些類的自定義代碼將受到影響。
- 默認的KafkaJVM性能選項（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生產者，並且用戶必須指定“老生產者”使用舊版本的生產者。
- 默認情況下，所有命令行工具將打印所有消息記錄到stderr而不是stdout。
- 新的代理ID自動生成功能可以通過設置broker.id.generation.enable為false禁用。
- 配置參數log.cleaner.enable現在默認為true。這意味主題在配置 cleanup.policy=compact下將缺省壓縮，清潔器進程通過log.cleaner.dedupe.buffer.size缺省被分配128MB堆。您可以檢查你的配置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.2與0.8.1完全兼容。可以通過簡單地將其關閉，更新代碼，並重新啟動逐一升級代理。
0.8.1與0.8完全兼容。可以通過簡單地將其關閉，更新代碼，並重新啟動逐一升級代理。從0.7升級
0.7版本與新版本不兼容。API，Zookeeper的數據結構和協議，可以配置的增加副本（這是在0.7沒有的），都發生了重大變化。從0.7到更高版本的升級需要特殊的工具進行遷移。這種遷移可以無需宕機就可以完成。
注：在此文章中這兩個單詞被翻譯為右邊的對應詞語。
Records – 記錄(持久化的消息)
Broker –代理服務器
最後更新：2017-05-18 20:36:06