1.4生態(tài)系統(tǒng)
在主發(fā)行版之外還有大量與Kafka集成的工具。 生態(tài)系統(tǒng)頁(yè)面列出了其中的許多內(nèi)容，包括流處理系統(tǒng)，Hadoop集成，監(jiān)控和部署工具。
1.5從以前的版本升級(jí)
從0.8.x，0.9.x，0.10.0.x，0.10.1.x或0.10.2.x升級(jí)到0.11.0.0
kafka0.11.0.0引入了一個(gè)新的消息格式版本以及有線協(xié)議的變化。 通過(guò)遵循以下建議的滾動(dòng)升級(jí)計(jì)劃，您可以保證在升級(jí)過(guò)程中不會(huì)出現(xiàn)停機(jī)。 不過(guò)，請(qǐng)?jiān)谏?jí)之前查看0.11.0.0中的版本更改。
從版本0.10.2開(kāi)始，Java客戶端（生產(chǎn)者和消費(fèi)者）已經(jīng)可以與老的broker進(jìn)行通信。 版本0.11.0客戶端可以與版本0.10.0或更加新的broker進(jìn)行通信。 但是，如果您的broker版本比0.10.0老舊，則必須先升級(jí)Kafka集群中的所有broker，然后再升級(jí)您的客戶端。 版本0.11.0 broker支持0.8.x和更加新的客戶端。
滾動(dòng)升級(jí)
- 更新所有broker上的server.properties并添加以下屬性。CURRENT_KAFKA_VERSION是指您要從哪個(gè)版本升級(jí)。CURRENT_MESSAGE_FORMAT_VERSION指的是當(dāng)前正在使用的消息格式版本。如果您以前沒(méi)有重寫(xiě)消息格式，那么應(yīng)該將CURRENT_MESSAGE_FORMAT_VERSION設(shè)置為和CURRENT_KAFKA_VERSION一樣。
- inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g. 0.8.2, 0.9.0, 0.10.0, 0.10.1 or 0.10.2).
- log.message.format.version=CURRENT_MESSAGE_FORMAT_VERSION （請(qǐng)參閱升級(jí)后的潛在性能影響，了解有關(guān)此配置的詳細(xì)信息。）
- 一次升級(jí)一個(gè)broker：shut down the broker，更新代碼并重新啟動(dòng)broker。
- 一旦整個(gè)群集升級(jí)，通過(guò)編輯inter.broker.protocol.version并將其設(shè)置為0.11.0顛覆協(xié)議版本，但是不要更改log.message.format.version。
- 重新啟動(dòng)代理，以使新的協(xié)議版本生效。
- 一旦所有（或大部分）使用者升級(jí)到0.11.0或更高版本，則將每個(gè)代理上的log.message.format.version更改為0.11.0，然后逐個(gè)重新啟動(dòng)它們。
其他升級(jí)說(shuō)明：
- 如果你可以接受停機(jī)，你可以簡(jiǎn)單地把所有的經(jīng)紀(jì)人關(guān)閉，更新代碼并重新開(kāi)始。 他們將默認(rèn)啟動(dòng)新的協(xié)議。
- 顛覆協(xié)議版本并重新啟動(dòng)可以在代理升級(jí)后的任何時(shí)候完成。 它不一定要在升級(jí)之后立即進(jìn)行。對(duì)于log.message.format.version一樣。
- 在更新全局設(shè)置log.message.format.version之前，還可以使用主題管理工具（bin / kafka-topics.sh）在各個(gè)主題上啟用0.11.0消息格式。
- 如果要從0.10.0之前的版本升級(jí)，則在切換到0.11.0之前，不必先將消息格式更新為0.10.0。
關(guān)于一次語(yǔ)義的注記
kafka0.11.0支持生產(chǎn)者的冪等和事務(wù)性能力。 冪等式發(fā)送確保消息在單個(gè)生產(chǎn)者的生命周期內(nèi)僅向特定主題分區(qū)發(fā)送一次。 事務(wù)發(fā)送允許生產(chǎn)者發(fā)送數(shù)據(jù)到多個(gè)分區(qū)，使得所有的消息都被成功地傳遞，或者全部都是失敗。 結(jié)合在一起，這些功能使kafka“恰好一次語(yǔ)義”。 有關(guān)這些功能的更多詳細(xì)信息，請(qǐng)參閱用戶指南，但下面我們說(shuō)一些關(guān)于在升級(jí)群集中啟用它們的特定注意事項(xiàng)。 請(qǐng)注意，啟用EoS不是必需的，如果未使用，則不會(huì)影響broker的行為。
- 只有新的Java生產(chǎn)者和消費(fèi)者支持一次語(yǔ)義。
- 這些功能主要取決于0.11.0消息格式。 嘗試以較舊的格式使用它們將導(dǎo)致不受支持的版本錯(cuò)誤。
- 事務(wù)狀態(tài)存儲(chǔ)在一個(gè)新的內(nèi)部主題__transaction_state中。 直到首次嘗試使用事務(wù)性請(qǐng)求API時(shí)才創(chuàng)建此主題。 類(lèi)似于消費(fèi)者偏移主題，有幾個(gè)設(shè)置來(lái)控制主題的配置。 例如，transaction.state.log.min.isr控制這個(gè)主題的最小ISR。 請(qǐng)參閱用戶指南中的配置部分以獲取完整的選項(xiàng)列表。
- 對(duì)于安全集群，事務(wù)性API需要新的ACL，可以使用bin / kafka-acls.sh工具打開(kāi)。
- Kafka的EoS引入了新的請(qǐng)求API，并修改了幾個(gè)現(xiàn)有的API。 有關(guān)完整的詳細(xì)信息，請(qǐng)參閱KIP-98
關(guān)于0.11.0中新消息格式的說(shuō)明
為了支持生產(chǎn)者更好的交付語(yǔ)義（見(jiàn)KIP-98）和改進(jìn)的復(fù)制容錯(cuò)能力（見(jiàn)KIP-101），0.11.0消息格式包括幾個(gè)主要的增強(qiáng)。雖然新格式包含更多信息以使這些改進(jìn)成為可能，但是我們已經(jīng)使批處理格式更有效率。只要每批消息的數(shù)量大于2，就可以降低整體開(kāi)銷(xiāo)。然而，對(duì)于較小的批次，可能會(huì)有一個(gè)小的性能影響。請(qǐng)參閱這里了解我們對(duì)新消息格式的初始性能分析結(jié)果。您還可以在KIP-98提案中找到關(guān)于消息格式的更多細(xì)節(jié)。
新消息格式的顯著差異之一是，使未壓縮的消息一起存儲(chǔ)為一個(gè)批次。這對(duì)broker配置max.message.bytes有一些影響，這會(huì)限制單個(gè)批處理的大小。首先，如果一個(gè)較老的客戶端使用舊的格式向主題分區(qū)產(chǎn)生消息，并且個(gè)別消息小于max.message.bytes，則broker可能在消息的向上轉(zhuǎn)換過(guò)程中合并為一個(gè)批次后仍然拒絕它們。通常，這可能發(fā)生在個(gè)別消息的聚合大小大于max.message.bytes的情況下。類(lèi)似對(duì)于舊的消費(fèi)者消費(fèi)從新格式向下轉(zhuǎn)換的消息也一樣：如果獲取大小沒(méi)有被設(shè)置為至少與max.message.bytes一樣大，即使單個(gè)未壓縮的消息小于配置的提取大小，消費(fèi)者也可能無(wú)法進(jìn)行處理。此行為不影響Java客戶端的0.10.1.0及更高版本，因?yàn)樗褂酶碌墨@取協(xié)議，該協(xié)議確保即使超過(guò)獲取大小，也可以返回至少一條消息。為了解決這些問(wèn)題，你應(yīng)該確保
1）生產(chǎn)者的批量大小沒(méi)有被設(shè)置為大于max.message.bytes，
2）消費(fèi)者的獲取大小至少被設(shè)置為max.message.bytes。
大多數(shù)關(guān)于升級(jí)到0.10.0消息格式對(duì)性能影響的討論仍然與0.11.0升級(jí)有關(guān)。 這主要影響不使用TLS保護(hù)的群集，因?yàn)樵谶@種情況下，“零復(fù)制”傳輸已經(jīng)不可行。 為了避免消息向下轉(zhuǎn)換成本，您應(yīng)該確保客戶應(yīng)用程序升級(jí)到最新的0.11.0客戶端。 值得注意的是，由于不支持新的消息格式，舊消費(fèi)者在0.11.0.0已被棄用。 您必須升級(jí)才能使用新消費(fèi)者消費(fèi)新的消息格式，而不需要向下轉(zhuǎn)換成本。 請(qǐng)注意，0.11.0的消費(fèi)者支持0.10.0 broker向上兼容，因此可以在broker之前先升級(jí)客戶端。
