1.4生态系统
在主发行版之外还有大量与Kafka集成的工具。 生态系统页面列出了其中的许多内容，包括流处理系统，Hadoop集成，监控和部署工具。
1.5从以前的版本升级
从0.8.x，0.9.x，0.10.0.x，0.10.1.x或0.10.2.x升级到0.11.0.0
kafka0.11.0.0引入了一个新的消息格式版本以及有线协议的变化。 通过遵循以下建议的滚动升级计划，您可以保证在升级过程中不会出现停机。 不过，请在升级之前查看0.11.0.0中的版本更改。
从版本0.10.2开始，Java客户端（生产者和消费者）已经可以与老的broker进行通信。 版本0.11.0客户端可以与版本0.10.0或更加新的broker进行通信。 但是，如果您的broker版本比0.10.0老旧，则必须先升级Kafka集群中的所有broker，然后再升级您的客户端。 版本0.11.0 broker支持0.8.x和更加新的客户端。
滚动升级
- 更新所有broker上的server.properties并添加以下属性。CURRENT_KAFKA_VERSION是指您要从哪个版本升级。CURRENT_MESSAGE_FORMAT_VERSION指的是当前正在使用的消息格式版本。如果您以前没有重写消息格式，那么应该将CURRENT_MESSAGE_FORMAT_VERSION设置为和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 （请参阅升级后的潜在性能影响，了解有关此配置的详细信息。）
- 一次升级一个broker：shut down the broker，更新代码并重新启动broker。
- 一旦整个群集升级，通过编辑inter.broker.protocol.version并将其设置为0.11.0颠覆协议版本，但是不要更改log.message.format.version。
- 重新启动代理，以使新的协议版本生效。
- 一旦所有（或大部分）使用者升级到0.11.0或更高版本，则将每个代理上的log.message.format.version更改为0.11.0，然后逐个重新启动它们。
其他升级说明：
- 如果你可以接受停机，你可以简单地把所有的经纪人关闭，更新代码并重新开始。 他们将默认启动新的协议。
- 颠覆协议版本并重新启动可以在代理升级后的任何时候完成。 它不一定要在升级之后立即进行。对于log.message.format.version一样。
- 在更新全局设置log.message.format.version之前，还可以使用主题管理工具（bin / kafka-topics.sh）在各个主题上启用0.11.0消息格式。
- 如果要从0.10.0之前的版本升级，则在切换到0.11.0之前，不必先将消息格式更新为0.10.0。
关于一次语义的注记
kafka0.11.0支持生产者的幂等和事务性能力。 幂等式发送确保消息在单个生产者的生命周期内仅向特定主题分区发送一次。 事务发送允许生产者发送数据到多个分区，使得所有的消息都被成功地传递，或者全部都是失败。 结合在一起，这些功能使kafka“恰好一次语义”。 有关这些功能的更多详细信息，请参阅用户指南，但下面我们说一些关于在升级群集中启用它们的特定注意事项。 请注意，启用EoS不是必需的，如果未使用，则不会影响broker的行为。
- 只有新的Java生产者和消费者支持一次语义。
- 这些功能主要取决于0.11.0消息格式。 尝试以较旧的格式使用它们将导致不受支持的版本错误。
- 事务状态存储在一个新的内部主题__transaction_state中。 直到首次尝试使用事务性请求API时才创建此主题。 类似于消费者偏移主题，有几个设置来控制主题的配置。 例如，transaction.state.log.min.isr控制这个主题的最小ISR。 请参阅用户指南中的配置部分以获取完整的选项列表。
- 对于安全集群，事务性API需要新的ACL，可以使用bin / kafka-acls.sh工具打开。
- Kafka的EoS引入了新的请求API，并修改了几个现有的API。 有关完整的详细信息，请参阅KIP-98
关于0.11.0中新消息格式的说明
为了支持生产者更好的交付语义（见KIP-98）和改进的复制容错能力（见KIP-101），0.11.0消息格式包括几个主要的增强。虽然新格式包含更多信息以使这些改进成为可能，但是我们已经使批处理格式更有效率。只要每批消息的数量大于2，就可以降低整体开销。然而，对于较小的批次，可能会有一个小的性能影响。请参阅这里了解我们对新消息格式的初始性能分析结果。您还可以在KIP-98提案中找到关于消息格式的更多细节。
新消息格式的显着差异之一是，使未压缩的消息一起存储为一个批次。这对broker配置max.message.bytes有一些影响，这会限制单个批处理的大小。首先，如果一个较老的客户端使用旧的格式向主题分区产生消息，并且个别消息小于max.message.bytes，则broker可能在消息的向上转换过程中合并为一个批次后仍然拒绝它们。通常，这可能发生在个别消息的聚合大小大于max.message.bytes的情况下。类似对于旧的消费者消费从新格式向下转换的消息也一样：如果获取大小没有被设置为至少与max.message.bytes一样大，即使单个未压缩的消息小于配置的提取大小，消费者也可能无法进行处理。此行为不影响Java客户端的0.10.1.0及更高版本，因为它使用更新的获取协议，该协议确保即使超过获取大小，也可以返回至少一条消息。为了解决这些问题，你应该确保
1）生产者的批量大小没有被设置为大于max.message.bytes，
2）消费者的获取大小至少被设置为max.message.bytes。
大多数关于升级到0.10.0消息格式对性能影响的讨论仍然与0.11.0升级有关。 这主要影响不使用TLS保护的群集，因为在这种情况下，“零复制”传输已经不可行。 为了避免消息向下转换成本，您应该确保客户应用程序升级到最新的0.11.0客户端。 值得注意的是，由于不支持新的消息格式，旧消费者在0.11.0.0已被弃用。 您必须升级才能使用新消费者消费新的消息格式，而不需要向下转换成本。 请注意，0.11.0的消费者支持0.10.0 broker向上兼容，因此可以在broker之前先升级客户端。
