1.4生態(tài)系統(tǒng)
在主發(fā)行版之外還有大量與Kafka集成的工具。 生態(tài)系統(tǒng)頁面列出了其中的許多內(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é)議的變化腥椒。 通過遵循以下建議的滾動(dòng)升級(jí)計(jì)劃，您可以保證在升級(jí)過程中不會(huì)出現(xiàn)停機(jī)候衍。 不過笼蛛，請(qǐng)?jiān)谏?jí)之前查看0.11.0.0中的版本更改。
從版本0.10.2開始蛉鹿，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)前正在使用的消息格式版本舔亭。如果您以前沒有重寫消息格式，那么應(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í)葬燎，通過編輯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í)說明：
- 如果你可以接受停機(jī)郊丛，你可以簡(jiǎn)單地把所有的經(jīng)紀(jì)人關(guān)閉，更新代碼并重新開始瞧筛。 他們將默認(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)于一次語義的注記
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“恰好一次語義”灭袁。 有關(guān)這些功能的更多詳細(xì)信息，請(qǐng)參閱用戶指南窗看，但下面我們說一些關(guān)于在升級(jí)群集中啟用它們的特定注意事項(xiàng)茸歧。 請(qǐng)注意，啟用EoS不是必需的显沈，如果未使用软瞎，則不會(huì)影響broker的行為。
- 只有新的Java生產(chǎn)者和消費(fèi)者支持一次語義拉讯。
- 這些功能主要取決于0.11.0消息格式涤浇。 嘗試以較舊的格式使用它們將導(dǎo)致不受支持的版本錯(cuò)誤。
- 事務(wù)狀態(tài)存儲(chǔ)在一個(gè)新的內(nèi)部主題__transaction_state中魔慷。 直到首次嘗試使用事務(wù)性請(qǐng)求API時(shí)才創(chuàng)建此主題只锭。 類似于消費(fèi)者偏移主題，有幾個(gè)設(shè)置來控制主題的配置院尔。 例如蜻展，transaction.state.log.min.isr控制這個(gè)主題的最小ISR喉誊。 請(qǐng)參閱用戶指南中的配置部分以獲取完整的選項(xiàng)列表。
- 對(duì)于安全集群纵顾，事務(wù)性API需要新的ACL伍茄，可以使用bin / kafka-acls.sh工具打開。
- Kafka的EoS引入了新的請(qǐng)求API施逾，并修改了幾個(gè)現(xiàn)有的API敷矫。 有關(guān)完整的詳細(xì)信息，請(qǐng)參閱KIP-98
關(guān)于0.11.0中新消息格式的說明
為了支持生產(chǎn)者更好的交付語義（見KIP-98）和改進(jìn)的復(fù)制容錯(cuò)能力（見KIP-101）汉额，0.11.0消息格式包括幾個(gè)主要的增強(qiáng)曹仗。雖然新格式包含更多信息以使這些改進(jìn)成為可能，但是我們已經(jīng)使批處理格式更有效率闷愤。只要每批消息的數(shù)量大于2整葡，就可以降低整體開銷。然而讥脐，對(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)換過程中合并為一個(gè)批次后仍然拒絕它們颅湘。通常话侧，這可能發(fā)生在個(gè)別消息的聚合大小大于max.message.bytes的情況下。類似對(duì)于舊的消費(fèi)者消費(fèi)從新格式向下轉(zhuǎn)換的消息也一樣：如果獲取大小沒有被設(shè)置為至少與max.message.bytes一樣大闯参，即使單個(gè)未壓縮的消息小于配置的提取大小瞻鹏，消費(fèi)者也可能無法進(jìn)行處理。此行為不影響Java客戶端的0.10.1.0及更高版本鹿寨，因?yàn)樗褂酶碌墨@取協(xié)議新博，該協(xié)議確保即使超過獲取大小，也可以返回至少一條消息脚草。為了解決這些問題赫悄，你應(yīng)該確保
1）生產(chǎn)者的批量大小沒有被設(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í)客戶端觅玻。
