【Kafka升级】-- 官方指导及注意事项

如果要从2.1.x之前的版本升级，请参阅以下注释，以了解用于存储使用者偏移量的架构的更改。将inter.broker.protocol.version更改为最新版本后，将无法降级到2.1之前的版本。

对于滚动升级：

1. 在所有代理上更新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.8.2、0.9.0、0.10.0、0.10.1、0.10.2、0.11.0、1.0、1.1）。
• log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（有关此配置的详细信息，请参阅​​升级后​​​对​​性能的潜在影响​​。）
• 如果要从0.11.0.x，1.0.x，1.1.x或2.0.x升级，并且尚未覆盖消息格式，则只需要覆盖代理间协议版本。

• inter.broker.protocol.version = CURRENT_KAFKA_VERSION（0.11.0，1.0，1.1，2.0）。

2. 一次升级一个代理：关闭代理，更新代码，然后重新启动。完成此操作后，代理将运行最新版本，并且您可以验证集群的行为和性能是否符合预期。如果有任何问题，此时仍可以降级。
3. 验证群集的行为和性能后，请通过编辑协议版本​​inter.broker.protocol.version​​并将其设置为2.2来提高协议版本 。
4. 逐一重新启动代理，以使新协议版本生效。代理开始使用最新的协议版本后，将无法再将集群降级到较旧的版本。
5. 如果您已按照上述说明覆盖了消息格式版本，则需要再进行一次滚动重启以将其升级到最新版本。一旦所有（或大多数）使用者均已升级到0.11.0或更高版本，请在每个代理上将log.message.format.version更改为2.2，然后逐一重新启动它们。请注意，不再维护的较旧的Scala客户端不支持0.11中引入的消息格式，因此为避免转换成本（或仅利用​​一次语义即可​​），必须使用较新的Java客户端。

​​2.2.1中的显着变化​​

• Kafka Streams 2.2.1需要0.11或更高的消息格式，并且不适用于较旧的消息格式。

​​2.2.0中的显着变化​​

• 默认消费者组ID已从空字符串（​​""​​​）更改为​​null​​​。使用新的默认组ID的使用者将无法订阅主题，也无法获取或提交偏移量。不建议使用空字符串作为消费者组ID，但将支持该字符串，直到以后的主要版本为止。现在，依赖空字符串组ID的旧客户端将必须显式提供它作为其使用者配置的一部分。有关更多信息，请参见 ​​KIP-289​​。
• 该​​bin/kafka-topics.sh​​​命令行工具现在能够直接连接到经纪商​​--bootstrap-server​​​，而不是饲养员。旧​​--zookeeper​​​ 选项现在仍然可用。请阅读​​KIP-377​​了解更多信息。
• Kafka Streams依赖于需要MacOS 10.13或更高版本的RocksDB的较新版本。

​​从0.8.x，0.9.x，0.10.0.x，0.10.1.x，0.10.2.x，0.11.0.x，1.0.x，1.1.x或2.0.0升级到2.1.0​​

请注意，2.1.x包含对用于存储使用者偏移量的内部架构的更改。升级完成后，将无法降级到以前的版本。有关更多详细信息，请参见下面的滚动升级说明。

对于滚动升级：

1. 在所有代理上更新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.8.2、0.9.0、0.10.0、0.10.1、0.10.2、0.11.0、1.0、1.1）。
• log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（有关此配置的详细信息，请参阅​​升级后​​​对​​性能的潜在影响​​。）
• 如果要从0.11.0.x，1.0.x，1.1.x或2.0.x升级，并且尚未覆盖消息格式，则只需要覆盖代理间协议版本。

• inter.broker.protocol.version = CURRENT_KAFKA_VERSION（0.11.0，1.0，1.1，2.0）。

2. 一次升级一个代理：关闭代理，更新代码，然后重新启动。完成此操作后，代理将运行最新版本，并且您可以验证集群的行为和性能是否符合预期。如果有任何问题，此时仍可以降级。
3. 验证群集的行为和性能后，请通过编辑协议版本​​inter.broker.protocol.version​​并将其设置为2.1来提高协议版本 。
4. 逐一重新启动代理，以使新协议版本生效。代理开始使用最新的协议版本后，将无法再将集群降级到较旧的版本。
5. 如果您已按照上述说明覆盖了消息格式版本，则需要再进行一次滚动重启以将其升级到最新版本。一旦所有（或大多数）使用者都升级到0.11.0或更高版本，则在每个代理上将log.message.format.version更改为2.1，然后逐一重新启动它们。请注意，不再维护的较旧的Scala客户端不支持0.11中引入的消息格式，因此为避免转换成本（或仅利用​​一次语义即可​​），必须使用较新的Java客户端。

其他升级说明：

1. 偏移到期语义在此版本中已稍有更改。根据新的语义，当组订阅了相应的主题并且仍处于活动状态（具有活动的使用者）时，组中分区的偏移量将不会被删除。如果组变为空，则在默认的偏移保留期（或由代理设置的偏移时间）过去之后（除非该组再次变为活动状态），将删除所有偏移。自上次提交以来，默认的偏移保留期（或代理设置的偏移）将在其不使用Kafka组管理的独立（简单）使用者相关的偏移之后被删除。
2. 现在，​​enable.auto.commit​​​当未​​group.id​​​提供时，控制台使用者属性的默认值设置为​​false​​。这是为了避免污染消费者协调器缓存，因为自动生成的组不太可能被其他消费者使用。
3. 如我们 在​​KIP-91中​​​所介绍的那样，生产者​​retries​​​配置的默认值已更改为​​Integer.MAX_VALUE​​​，它设置了发送记录和从代理接收确认之间的总时间上限。默认情况下，传递超时设置为2分钟。​​delivery.timeout.ms​​
4. 默认情况下，MirrorMaker现在在配置生产者时会覆盖​​delivery.timeout.ms​​​到​​Integer.MAX_VALUE​​​。如果您已覆盖值​​retries​​​以更快地失败，则需要覆盖​​delivery.timeout.ms​​。
5. 该​​ListGroup​​​API现在希望作为一种推荐的替代方法，是​​Describe Group​​​访问用户应该能够列出的组。即使​​Describe Cluster​​仍支持旧访问以实现向后兼容性，也不建议将其用于此API。
6. ​​KIP-336​​​弃用了ExtendedSerializer和ExtendedDeserializer接口，并传播了Serializer和Deserializer的用法。​​KIP-82​​引入了ExtendedSerializer和ExtendedDeserializer ，以Java 7兼容的方式为序列化器和反序列化器提供记录头。现在我们合并了这些接口，因为从那时起不再支持Java 7。

​​2.1.0中的显着变化​​

• Jetty已升级到9.4.12，默认情况下不包括TLS_RSA_ *密码，因为它们不支持前向保密性，有关更多信息，请参见https://github.com/eclipse/jetty.project/issues/2807。
• 当​​unclean.leader.election.enable​​使用每个主题的配置替代动态更新配置时，控制器会自动启用不干净的领导者选举。
• 在​​AdminClient​​​增加了一个方法​​AdminClient#metrics()​​​。现在，任何使用的应用程序​​AdminClient​​​都可以通过查看从捕获的指标来获取更多信息和洞察力​​AdminClient​​​。有关更多信息，请参见​​KIP-324​​
• Kafka现在支持来自​​KIP-110的​​ Zstandard压缩。您必须升级代理以及客户端才能使用它。2.1.0之前的使用者将无法阅读使用Zstandard压缩的主题，因此在升级所有下游使用者之前，您不应为主题启用它。有关更多详细信息，请参见KIP。

​​从0.8.x，0.9.x，0.10.0.x，0.10.1.x，0.10.2.x，0.11.0.x，1.0.x或1.1.x升级到2.0.0​​

Kafka 2.0.0引入了有线协议更改。通过遵循以下建议的滚动升级计划，可以保证升级期间不会停机。但是，请在升级前查看​​2.0.0中​​​的​​显着更改​​。

对于滚动升级：

1. 在所有代理上更新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.8.2、0.9.0、0.10.0、0.10.1、0.10.2、0.11.0、1.0、1.1）。
• log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（有关此配置的详细信息，请参阅​​升级后​​​对​​性能的潜在影响​​。）
• 如果要从0.11.0.x，1.0.x或1.1.x升级，并且尚未覆盖消息格式，则只需要覆盖中间经纪人协议格式。

• inter.broker.protocol.version = CURRENT_KAFKA_VERSION（0.11.0，1.0，1.1）。

2. 一次升级一个代理：关闭代理，更新代码，然后重新启动。
3. 升级整个群集后，通过编辑​​inter.broker.protocol.version​​并将其设置为2.0来增加协议版本。
4. 逐一重新启动代理，以使新协议版本生效。
5. 如果您已按照上述说明覆盖了消息格式版本，则需要再进行一次滚动重启以将其升级到最新版本。将所有（或大多数）使用方升级到0.11.0或更高版本后，请在每个代理上将log.message.format.version更改为2.0，然后逐一重新启动它们。请注意，较早的Scala使用者不支持0.11中引入的新消息格式，因此，为了避免降低转换的性能成本（或仅利用​​一次语义​​），必须使用较新的Java使用者。

其他升级说明：

1. 如果您愿意接受停机时间，则只需关闭所有代理，更新代码并重新启动它们即可。默认情况下，它们将从新协议开始。
2. 升级代理后，可以随时更改协议版本并重新启动。不必紧随其后。消息格式版本也是如此。
3. 如果您在Kafka Streams代码中使用Java8方法引用，则可能需要更新代码以解决方法的歧义。仅热交换jar文件可能不起作用。
4. 在更新集群中的所有代理之前，不应将ACL添加到前缀资源（在​​KIP-290中​​添加）。 注意：即使在群集完全升级之后，添加到群集的所有带前缀的ACL也会被忽略，如果再次降级该群集。

​​2.0.0的显着变化​​

• ​​KIP-186​​​将默认偏移保留时间从1天增加到7天。这使得它不太可能在丢失的应用程序中“丢失”偏移量。它还会增加活动的偏移量集，因此会增加代理上的内存使用量。请注意，控制台使用者当前默认情况下启用偏移提交，并且可以是大量偏移的来源，此更改现在将保留7天而不是1天。您可以通过将Broker Config设置​​offsets.retention.minutes​​为1440 来保留现有行为。
• 对Java 7的支持已删除，现在Java 8是所需的最低版本。
• 的默认值​​ssl.endpoint.identification.algorithm​​​已更改为​​https​​​，以执行主机名验证（否则，可能会发生中间人攻击）。设置​​ssl.endpoint.identification.algorithm​​为空字符串可恢复以前的行为。
• ​​KAFKA-5674​​​将​​max.connections.per.ip​​最小值的下限间隔扩展为零，因此允许基于IP的入站连接筛选。
• ​​KIP-272​​​ 已将API版本标记添加到度量​​kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower|...}​​​。现在，该指标变为​​kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower|...},version={0|1|2|3|...}​​。这将影响不会自动聚合的JMX监视工具。为了获得特定请求类型的总数，该工具需要更新以跨不同版本进行汇总。
• ​​KIP-225​​更改了指标“ records.lag”以将标签用于主题和分区。名称格式为“ {topic}-{partition} .records-lag”的原始版本已被删除。
• 从0.11.0.0开始不推荐使用的Scala使用者已被删除。从0.10.0.0开始，推荐使用Java使用者。请注意，即使将代理升级到2.0.0，Scala使用者1.1.0（及更低版本）也将继续工作。
• 从0.10.0.0版本开始不推荐使用的Scala生产者已被删除。从0.9.0.0版本开始，推荐使用Java生产者。请注意，Java生产者中默认分区程序的行为与Scala生产者中默认分区程序的行为不同。迁移的用户应考虑配置保留以前行为的自定义分区程序。请注意，即使将代理升级到2.0.0，1.1.0（及更低版本）中的Scala生产者也将继续工作。
• MirrorMaker和ConsoleConsumer不再支持Scala使用者，它们始终使用Java使用者。
• ConsoleProducer不再支持Scala生产者，它始终使用Java生产者。
• 删除了许多依赖Scala客户端的不推荐使用的工具：ReplayLogProducer，SimpleConsumerPerformance，SimpleConsumerShell，ExportZkOffsets，ImportZkOffsets，UpdateOffsetsInZK，VerifyConsumerRebalance。
• 不推荐使用的kafka.tools.ProducerPerformance已被删除，请使用org.apache.kafka.tools.ProducerPerformance。
• ​​upgrade.from​​添加了新的Kafka Streams配置参数，该参数允许从旧版本滚动退回升级。
• ​​KIP-284​​​通过将其默认值设置为，更改了Kafka Streams分区主题的保留时间​​Long.MAX_VALUE​​。
• ​​ProcessorStateManager​​​Kafka Streams中更新的API，用于将状态存储注册到处理器拓扑。有关更多详细信息，请阅读Streams ​​升级指南​​。
• 在早期版本中，Connect的工作程序配置需要​​internal.key.converter​​​和​​internal.value.converter​​​属性。在2.0中，这些​​不再是必需的，​​​并且默认为JSON转换器。您可以从Connect独立和分布式工作程序配置中安全删除以下属性：
  ​​​internal.key.converter=org.apache.kafka.connect.json.JsonConverter​​​ ​​internal.key.converter.schemas.enable=false​​​ ​​internal.value.converter=org.apache.kafka.connect.json.JsonConverter​​​ ​​internal.value.converter.schemas.enable=false​​
• ​​KIP-266​​​添加了新的使用者配置，​​default.api.timeout.ms​​​ 以指定用于​​KafkaConsumer​​​可能阻塞的API 的默认超时。KIP还为此类阻塞API添加了重载，以支持指定用于每个API的特定超时，而不是使用设置的默认超时​​default.api.timeout.ms​​​。特别是，​​poll(Duration)​​​添加了一个新API ，该API不会阻止动态分区分配。旧的​​poll(long)​​​API已被弃用，并将在以后的版本中删除。重载还添加了其他​​KafkaConsumer​​​的方法，如​​partitionsFor​​​，​​listTopics​​​，​​offsetsForTimes​​​， ​​beginningOffsets​​​，​​endOffsets​​​并​​close​​​表示诚挚的一个​​Duration​​。
• 另外，作为KIP-266的一部分，默认值​​request.timeout.ms​​​已更改为30秒。先前的值略高于5分钟，以说明重新平衡所需的最长时间。现在，我们将重新平衡中的JoinGroup请求视为一种特殊情况，并使用从中得出 ​​max.poll.interval.ms​​​的请求超时值。所有其他请求类型都使用由定义的超时​​request.timeout.ms​​
• 内部方法​​kafka.admin.AdminClient.deleteRecordsBefore​​​已删除。鼓励用户迁移到​​org.apache.kafka.clients.admin.AdminClient.deleteRecords​​。
• AclCommand工具​​--producer​​​便捷选项在给定主题上使用​​KIP-277​​细粒度的ACL。
• ​​KIP-176​​​删除了​​--new-consumer​​所有基于消费者的工具的选项。此选项是多余的，因为如果定义了--bootstrap-server，则会自动使用新使用者。
• ​​KIP-290​​增加了在前缀资源（例如，以“ foo”开头的任何主题）上定义ACL的功能。
• ​​KIP-283​​​改进了Kafka代理上的消息下转换处理，该代理通常是占用大量内存的操作。KIP增加了一种机制，该机制通过一次向下转换分区数据的块来降低操作的内存密集度，从而有助于提高内存消耗。通过此改进，​​FetchResponse​​​协议行为发生了变化， 其中代理可以向响应的结尾发送带有无效偏移量的超大消息批。消费者客户端必须忽略此类超大消息，就像一样​​KafkaConsumer​​​。 KIP-283还添加了新的主题和代理配置，​​message.downconversion.enable​​并​​log.message.downconversion.enable​​分别控制是否启用了向下转换。禁用后，代理将不执行任何下转换，而是向​​UNSUPPORTED_VERSION​​ 客户端发送错误。
• 在启动代理之前，可以使用kafka-configs.sh将动态代理配置选项存储在ZooKeeper中。此选项可用于避免将清晰的密码存储在server.properties中，因为所有密码配置都可以加密存储在ZooKeeper中。
• 现在，如果连接尝试失败，则将重新解析ZooKeeper主机。但是，如果您的ZooKeeper主机名解析为多个地址，但其中一些无法访问，则可能需要增加连接超时 ​​zookeeper.connection.timeout.ms​​。

​​新协议版本​​

• ​​KIP-279​​​：OffsetsForLeaderEpochResponse v1引入了分区级​​leader_epoch​​字段。
• ​​KIP-219​​：提高由于配额违反而受到限制的非集群操作请求和响应的协议版本。
• ​​KIP-290​​：修改ACL创建，描述和删除请求和响应的协议版本。

​​升级1.1 Kafka Streams应用程序​​

• 将Streams应用程序从1.1升级到2.0不需要代理升级。Kafka Streams 2.0应用程序可以连接到2.0、1.1、1.0、0.11.0、0.10.2和0.10.1代理（尽管无法连接到0.10.0代理）。
• 请注意，在2.0中，我们删除了1.0之前不推荐使用的公共API。利用那些已弃用的API的用户需要相应地更改代码。有关更多详细信息，请参见​​2.0.0中的Streams API更改​​。

​​从0.8.x，0.9.x，0.10.0.x，0.10.1.x，0.10.2.x，0.11.0.x或1.0.x升级到1.1.x​​

Kafka 1.1.0引入了有线协议更改。通过遵循以下建议的滚动升级计划，可以保证升级期间不会停机。但是，请在升级之前查看​​1.1.0中​​​的​​显着更改​​。

对于滚动升级：

1. 在所有代理上更新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.8.2、0.9.0、0.10.0、0.10.1、0.10.2、0.11.0、1.0）。
• log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（有关此配置的详细信息，请参阅​​升级后​​​对​​性能的潜在影响​​。）
• 如果要从0.11.0.x或1.0.x升级，并且尚未覆盖消息格式，则只需要覆盖中间经纪人协议格式。

• inter.broker.protocol.version = CURRENT_KAFKA_VERSION（0.11.0或1.0）。

2. 一次升级一个代理：关闭代理，更新代码，然后重新启动。
3. 升级整个群集后，可通过编辑协议版本​​inter.broker.protocol.version​​并将其设置为1.1 来提高协议版本。
4. 逐一重新启动代理，以使新协议版本生效。
5. 如果您已按照上述说明覆盖了消息格式版本，则需要再进行一次滚动重启以将其升级到最新版本。一旦所有（或大多数）使用者都升级到0.11.0或更高版本，请在每个代理上将log.message.format.version更改为1.1，然后逐一重新启动它们。请注意，较早的Scala使用者不支持0.11中引入的新消息格式，因此，为了避免降低转换的性能成本（或仅利用​​一次语义​​），必须使用较新的Java使用者。

其他升级说明：

1. 如果您愿意接受停机时间，则只需关闭所有代理，更新代码并重新启动它们即可。默认情况下，它们将从新协议开始。
2. 升级代理后，可以随时更改协议版本并重新启动。不必紧随其后。消息格式版本也是如此。
3. 如果您在Kafka Streams代码中使用Java8方法引用，则可能需要更新代码以解决方法的歧义。仅热交换jar文件可能不起作用。

​​1.1.1的显着变化​​

• ​​upgrade.from​​添加了新的Kafka Streams配置参数，该参数允许从0.10.0.x版进行滚动跳动升级
• 有关此新配置的详细信息，请参见​​Kafka Streams升级指南​​。

​​1.1.0的显着变化​​

• Maven中的kafka工件不再依赖于log4j或slf4j-log4j12。与kafka-clients工件类似，用户现在可以通过包括适当的slf4j模块（slf4j-log4j12，logback等）来选择日志记录后端。发行版tarball仍然包括log4j和slf4j-log4j12。
• ​​KIP-225​​更改了指标“ records.lag”以将标签用于主题和分区。名称格式为“ {topic}-{partition} .records-lag”的原始版本已弃用，并将在2.0.0中删除。
• Kafka Streams对于代理通信错误更强大。Kafka Streams不会自我修复并重新连接到群集，而不是在发生致命异常时停止Kafka Streams客户端。使用新版本，​​AdminClient​​​您可以更好地控制Kafka Streams重试的频率，并且可以​​配置​​ 细粒度的超时（而不是像旧版本中那样进行硬编码重试）。
• Kafka Streams的重新平衡时间进一步减少，使Kafka Streams的响应速度更快。
• Kafka Connect现在在接收器和源连接器中都支持消息头，并通过简单的消息转换对其进行操作。必须更改连接器以显式使用它们。​​HeaderConverter​​引入了新的控件来控制标题的序列化（反序列化），默认情况下使用新的“ SimpleHeaderConverter”来使用值的字符串表示形式。
• 如果由于其他任何选项（例如解码器）而显式或隐式启用了print-data-log，则kafka.tools.DumpLogSegments现在会自动设置深度迭代选项。

​​新协议版本​​

• ​​KIP-226​​引入了DescribeConfigs请求/响应v1。
• ​​KIP-227​​引入了获取请求/响应v7。

​​升级1.0 Kafka Streams应用程序​​

• 将Streams应用程序从1.0升级到1.1不需要代理升级。Kafka Streams 1.1应用程序可以连接到1.0、0.11.0、0.10.2和0.10.1代理（尽管无法连接到0.10.0代理）。
• 有关更多详细信息，请参见​​1.1.0中的Streams API更改​​。

​​从0.8.x，0.9.x，0.10.0.x，0.10.1.x，0.10.2.x或0.11.0.x升级到1.0.0​​

Kafka 1.0.0引入了有线协议更改。通过遵循以下建议的滚动升级计划，可以保证升级期间不会停机。但是，请在升级前查看​​1.0.0中​​​的​​显着更改​​。

对于滚动升级：

1. 在所有代理上更新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.8.2、0.9.0、0.10.0、0.10.1、0.10.2、0.11.0）。
• log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（有关此配置的详细信息，请参阅​​升级后​​​对​​性能的潜在影响​​。）
• 如果要从0.11.0.x升级，并且尚未覆盖消息格式，则必须同时将消息格式版本和代理间协议版本设置为0.11.0。

• inter.broker.protocol.version = 0.11.0
• log.message.format.version = 0.11.0

2. 一次升级一个代理：关闭代理，更新代码，然后重新启动。
3. 升级整个群集后，可通过编辑协议版本​​inter.broker.protocol.version​​并将其设置为1.0来增加协议版本。
4. 逐一重新启动代理，以使新协议版本生效。
5. 如果您已按照上述说明覆盖了消息格式版本，则需要再进行一次滚动重启以将其升级到最新版本。将所有（或大多数）使用方升级到0.11.0或更高版本后，请在每个代理上将log.message.format.version更改为1.0，然后逐一重新启动它们。如果要从0.11.0升级，并且log.message.format.version设置为0.11.0，则可以更新配置并跳过滚动重启。请注意，较早的Scala使用者不支持0.11中引入的新消息格式，因此，为了避免降低转换的性能成本（或仅利用​​一次语义​​），必须使用较新的Java使用者。

其他升级说明：

1. 如果您愿意接受停机时间，则只需关闭所有代理，更新代码并重新启动它们即可。默认情况下，它们将从新协议开始。
2. 升级代理后，可以随时更改协议版本并重新启动。不必紧随其后。消息格式版本也是如此。

​​1.0.2的显着变化​​

• ​​upgrade.from​​添加了新的Kafka Streams配置参数，该参数允许从0.10.0.x版进行滚动跳动升级
• 有关此新配置的详细信息，请参见​​Kafka Streams升级指南​​。

​​1.0.1的显着变化​​

• 使用0.11.0.x恢复了AdminClient的Options类（例如CreateTopicsOptions，DeleteTopicsOptions等）的二进制兼容性。二进制（但不是源代码）兼容性在1.0.0中被无意间破坏了。

​​1.0.0的显着变化​​

• 由于功能稳定，现在默认情况下启用主题删除。希望保留先前行为的用户应将Broker Config设置​​delete.topic.enable​​​为​​false​​。请记住，主题删除会删除数据，并且该操作不可逆（即，没有“取消删除”操作）
• 对于支持时间戳搜索（如果找不到某个分区的偏移量）的主题，该分区现在包含在搜索结果中，且偏移量值为空。以前，该分区未包含在地图中。进行此更改是为了使搜索行为与不支持时间戳搜索的主题一致。
• 如果​​inter.broker.protocol.version​​​是1.0或更高版本，则即使存在脱机日志目录，代理现在仍将保持联机状态以为实时日志目录提供副本。由于硬件故障导致IOException，日志目录可能会脱机。用户需要监视每个代理的指标，​​offlineLogDirectoryCount​​以检查是否存在脱机日志目录。
• 添加了KafkaStorageException，它是可重试的异常。如果客户端的FetchRequest或ProducerRequest的版本不支持KafkaStorageException，则KafkaStorageException将在响应中转换为NotLeaderForPartitionException。
• 在默认的JVM设置中，-XX：+ DisableExplicitGC被-XX：+ ExplicitGCInvokesConcurrent替换。在某些情况下，这有助于避免在通过直接缓冲区分配本机内存的过程中出现内存不足异常。
• 重写的​​handleError​​​方法实现已经从下列过时类去除​​kafka.api​​​包：​​FetchRequest​​​，​​GroupCoordinatorRequest​​​，​​OffsetCommitRequest​​​， ​​OffsetFetchRequest​​​，​​OffsetRequest​​​，​​ProducerRequest​​​，和​​TopicMetadataRequest​​。它仅打算在代理上使用，但不再使用，并且尚未维护实现。保留了存根实现以实现二进制兼容性。
• Java客户端和工具现在可以接受任何字符串作为客户端ID。
• 不推荐使用的工具​​kafka-consumer-offset-checker.sh​​​已被删除。使用​​kafka-consumer-groups.sh​​得到消费群的详细信息。
• 现在，SimpleAclAuthorizer默认将访问拒绝记录到授权者日志中。
• 身份验证失败现在作为的子类之一报告给客户端​​AuthenticationException​​。如果客户端连接身份验证失败，将不执行任何重试。
• 定制​​SaslServer​​​实现可能会抛出​​SaslAuthenticationException​​错误消息以返回到客户端，以指示身份验证失败的原因。实现者应注意不要在异常消息中不要包含任何对安全性至关重要的信息，这些信息不应泄露给未经身份验证的客户端。
• ​​app-info​​向JMX注册以提供版本和提交ID 的mbean将被弃用，并替换为提供这些属性的度量。
• Kafka指标现在可能包含非数字值。​​org.apache.kafka.common.Metric#value()​​​已被弃用，​​0.0​​​在这种情况下将返回，以最大程度地减少破坏读取每个客户指标值的用户的可能性（通过​​MetricsReporter​​​实现或通过调用​​metrics()​​​方法）。 ​​org.apache.kafka.common.Metric#metricValue()​​可用于检索数字和非数字指标值。
• 现在，每个Kafka速率指标都有一个带后缀的对应累积计数指标，​​-total​​​ 以简化下游处理。例如，​​records-consumed-rate​​​有一个名为的对应指标​​records-consumed-total​​。
• 仅当系统属性​​kafka_mx4jenable​​​设置为时，才会启用Mx4j ​​true​​​。由于存在逻辑反转错误，因此先前默认情况下启用了该功能，如果将​​kafka_mx4jenable​​​其设置为，则会将其禁用​​true​​。
• ​​org.apache.kafka.common.security.auth​​客户端jar中的软件包已公开，并已添加到javadocs中。以前位于此程序包中的内部类已移至其他位置。
• 当使用授权者并且用户对主题没有必需的权限时，无论代理上是否存在主题，代理都将向请求返回TOPIC_AUTHORIZATION_FAILED错误。如果用户具有必需的权限，但该主题不存在，则将返回UNKNOWN_TOPIC_OR_PARTITION错误代码。
• config / consumer.properties文件已更新为使用新的使用者配置属性。

​​新协议版本​​

• ​​KIP-112​​​：LeaderAndIsrRequest v1引入了分区级​​is_new​​字段。
• ​​KIP-112​​​：UpdateMetadataRequest v4引入了分区级​​offline_replicas​​字段。
• ​​KIP-112​​​：MetadataResponse v5引入了分区级​​offline_replicas​​字段。
• ​​KIP-112​​：ProduceResponse v4引入了KafkaStorageException的错误代码。
• ​​KIP-112​​：FetchResponse v6引入了KafkaStorageException的错误代码。
• ​​KIP-152​​：已添加SaslAuthenticate请求，以启用对身份验证失败的报告。如果SaslHandshake请求版本大于0，则将使用此请求。

​​升级0.11.0 Kafka Streams应用程序​​

• 将Streams应用程序从0.11.0升级到1.0不需要代理升级。Kafka Streams 1.0应用程序可以连接到0.11.0、0.10.2和0.10.1代理（尽管无法连接到0.10.0代理）。但是，Kafka Streams 1.0需要0.10或更高版本的消息格式，并且不适用于较旧的消息格式。
• 如果要监视流指标，则需要更改报告和监视代码中的指标名称，因为指标传感器的层次结构已更改。
• 有一些公共的API，包括​​ProcessorContext#schedule()​​​，​​Processor#punctuate()​​​和​​KStreamBuilder​​​，​​TopologyBuilder​​正在被新的API弃用。我们建议您进行相应的代码更改，这应该很小，因为升级时新的API看起来非常相似。
• 有关更多详细信息，请参见​​1.0.0中的Streams API更改​​。

​​升级0.10.2 Kafka Streams应用程序​​

• 将Streams应用程序从0.10.2升级到1.0不需要代理升级。Kafka Streams 1.0应用程序可以连接到1.0、0.11.0、0.10.2和0.10.1代理（尽管无法连接到0.10.0代理）。
• 如果要监视流指标，则需要更改报告和监视代码中的指标名称，因为指标传感器的层次结构已更改。
• 有一些公共的API，包括​​ProcessorContext#schedule()​​​，​​Processor#punctuate()​​​和​​KStreamBuilder​​​，​​TopologyBuilder​​正在被新的API弃用。我们建议您进行相应的代码更改，这应该很小，因为升级时新的API看起来非常相似。
• 如果指定自定义​​key.serde​​​，​​value.serde​​​并​​timestamp.extractor​​在CONFIGS，推荐使用他们更换配置参数，因为这些CONFIGS已被弃用。
• 有关更多详细信息，请参见​​0.11.0中的Streams API更改​​。

​​升级0.10.1 Kafka Streams应用程序​​

• 将您的Streams应用程序从0.10.1升级到1.0不需要代理升级。Kafka Streams 1.0应用程序可以连接到1.0、0.11.0、0.10.2和0.10.1代理（尽管无法连接到0.10.0代理）。
• 您需要重新编译代码。只是交换Kafka Streams库jar文件将不起作用，并且会破坏您的应用程序。
• 如果要监视流指标，则需要更改报告和监视代码中的指标名称，因为指标传感器的层次结构已更改。
• 有一些公共的API，包括​​ProcessorContext#schedule()​​​，​​Processor#punctuate()​​​和​​KStreamBuilder​​​，​​TopologyBuilder​​正在被新的API弃用。我们建议您进行相应的代码更改，这应该很小，因为升级时新的API看起来非常相似。
• 如果指定自定义​​key.serde​​​，​​value.serde​​​并​​timestamp.extractor​​在CONFIGS，推荐使用他们更换配置参数，因为这些CONFIGS已被弃用。
• 如果使用自定义（即用户实现的）时间戳提取器，则由于​​TimestampExtractor​​接口已更改，因此需要更新此代码。
• 如果注册自定义指标，则由于​​StreamsMetric​​界面已更改，因此需要更新此代码。
• 有关更多详细信息，请参见​​1.0.0​​​中的 ​​Streams API更改，0.11.0中的​​​​Streams API更改​​​和 ​​0.10.2中的​​​​Streams API更改​​。

​​升级0.10.0 Kafka Streams应用程序​​

• 将您的Streams应用程序从0.10.0升级到1.0确实需要​​代理升级，​​因为Kafka Streams 1.0应用程序只能连接到0.1、0.11.0、0.10.2或0.10.1代理。
• 有几个API的变化，这是不向后兼容（参见​​流API中1.0.0的变化​​​， ​​在0.11.0流API的变化​​​， ​​在0.10.2流API的变化​​​，和 ​​流API的变化在0.10.1​​了解更多详情）。因此，您需要更新并重新编译代码。只是交换Kafka Streams库jar文件将不起作用，并且会破坏您的应用程序。
• 从0.10.0.x升级到1.0.2要求两次滚动反弹，​​upgrade.from="0.10.0"​​​并为第一个升级阶段设置了配置（请参阅​​KIP-268​​）。或者，也可以进行脱机升级。

• 准备应用程序实例以进行滚动弹跳，并确保将config ​​upgrade.from​​​设置​​"0.10.0"​​为新版本0.11.0.3
• 反弹应用程序的每个实例一次
• 准备新部署的1.0.2应用程序实例以进行第二轮滚动弹跳；确保删除配置的值​​upgrade.mode​​
• 再次弹跳应用程序的每个实例以完成升级

• 从0.10.0.x升级到1.0.0或1.0.1需要脱机升级（不支持滚动退回升级）

• 停止所有旧的（0.10.0.x）应用程序实例
• 更新您的代码，并用新代码和新jar文件交换旧代码和jar文件
• 重新启动所有新的（1.0.0或1.0.1）应用程序实例

​​从0.8.x，0.9.x，0.10.0.x，0.10.1.x或0.10.2.x升级到0.11.0.0​​

Kafka 0.11.0.0引入了新的消息格式版本以及有线协议更改。通过遵循以下建议的滚动升级计划，可以保证升级期间不会停机。但是，请在升级之前查看​​0.11.0.0中​​​的​​显着更改​​。

从版本0.10.2开始，Java客户端（生产者和消费者）已经具有与较早的代理进行通信的能力。版本0.11.0的客户可以与版本0.10.0或更高版本的代理通信。但是，如果您的代理早于0.10.0，则必须先升级Kafka群集中的所有代理，然后再升级客户端。版本0.11.0代理支持0.8.x和更高版本的客户端。

对于滚动升级：

1. 在所有代理上更新server.properties并添加以下属性。CURRENT_KAFKA_VERSION指的是您要升级的版本。CURRENT_MESSAGE_FORMAT_VERSION指当前正在使用的当前消息格式版本。如果您之前没有覆盖消息格式，则应将CURRENT_MESSAGE_FORMAT_VERSION设置为与CURRENT_KAFKA_VERSION相匹配。

• inter.broker.protocol.version = CURRENT_KAFKA_VERSION（例如0.8.2、0.9.0、0.10.0、0.10.1或0.10.2）。
• log.message.format.version = CURRENT_MESSAGE_FORMAT_VERSION（有关此配置的详细信息，请参阅​​升级后​​​对​​性能的潜在影响​​。）

2. 一次升级一个代理：关闭代理，更新代码，然后重新启动。
3. 升级整个群集后，请通过编辑协议版本​​inter.broker.protocol.version​​​并将其设置为0.11.0来提高协议版本，但不要更改​​log.message.format.version​​。
4. 逐一重新启动代理，以使新协议版本生效。
5. 一旦所有（或大多数）使用者都升级到0.11.0或更高版本，则在每个代理上将log.message.format.version更改为0.11.0并逐个重新启动它们。请注意，较早的Scala使用方不支持新的消息格式，因此，为避免性能降级（或仅利用​​一次语义​​），必须使用新的Java使用方。

其他升级说明：

1. 如果您愿意接受停机时间，则只需关闭所有代理，更新代码并重新启动它们即可。默认情况下，它们将从新协议开始。
2. 升级代理后，可以随时更改协议版本并重新启动。不必紧随其后。消息格式版本也是如此。
3. ​​bin/kafka-topics.sh​​​在更新全局设置之前，还可以使用主题管理工具（）对单个主题启用0.11.0消息格式​​log.message.format.version​​。
4. 如果要从0.10.0之前的版本升级，则在切换到0.11.0之前不必先将消息格式更新为0.10.0。

​​升级0.10.2 Kafka Streams应用程序​​

• 将Streams应用程序从0.10.2升级到0.11.0不需要代理升级。Kafka Streams 0.11.0应用程序可以连接到0.11.0、0.10.2和0.10.1代理（尽管无法连接到0.10.0代理）。
• 如果指定自定义​​key.serde​​​，​​value.serde​​​并​​timestamp.extractor​​在CONFIGS，推荐使用他们更换配置参数，因为这些CONFIGS已被弃用。
• 有关更多详细信息，请参见​​0.11.0中的Streams API更改​​。

​​升级0.10.1 Kafka Streams应用程序​​

• 将您的Streams应用程序从0.10.1升级到0.11.0不需要代理升级。Kafka Streams 0.11.0应用程序可以连接到0.11.0、0.10.2和0.10.1代理（尽管无法连接到0.10.0代理）。
• 您需要重新编译代码。只是交换Kafka Streams库jar文件将不起作用，并且会破坏您的应用程序。
• 如果指定自定义​​key.serde​​​，​​value.serde​​​并​​timestamp.extractor​​在CONFIGS，推荐使用他们更换配置参数，因为这些CONFIGS已被弃用。
• 如果使用自定义（即用户实现的）时间戳提取器，则由于​​TimestampExtractor​​接口已更改，因此需要更新此代码。
• 如果注册自定义指标，则由于​​StreamsMetric​​界面已更改，因此需要更新此代码。
• 有关更多详细信息，请参见​​0.11.0中的​​​​Streams API更改​​​和 ​​0.10.2中的​​​​Streams API更改​​。

​​升级0.10.0 Kafka Streams应用程序​​

• 将Streams应用程序从0.10.0升级到0.11.0确实需要​​代理升级，​​因为Kafka Streams 0.11.0应用程序只能连接到0.11.0、0.10.2或0.10.1代理。
• 有几个API的变化，这是不向后兼容（参见​​流API变化0.11.0​​​， ​​在0.10.2流API的变化​​​，并 ​​在0.10.1流API的变化​​有详细介绍）。因此，您需要更新并重新编译代码。只是交换Kafka Streams库jar文件将不起作用，并且会破坏您的应用程序。
• 从0.10.0.x升级到0.11.0.3需要两次滚动反弹，​​upgrade.from="0.10.0"​​​并为第一个升级阶段设置了配置（请参阅​​KIP-268​​）。或者，也可以进行脱机升级。

• 准备应用程序实例以进行滚动弹跳，并确保将config ​​upgrade.from​​​设置​​"0.10.0"​​为新版本0.11.0.3
• 反弹应用程序的每个实例一次
• 准备新部署的0.11.0.3应用程序实例，以进行第二轮滚动弹跳；确保删除配置的值​​upgrade.mode​​
• 再次弹跳应用程序的每个实例以完成升级

• 从0.10.0.x升级到0.11.0.0、0.11.0.1或0.11.0.2需要脱机升级（不支持滚动退回升级）

• 停止所有旧的（0.10.0.x）应用程序实例
• 更新您的代码，并用新代码和新jar文件交换旧代码和jar文件
• 重新启动所有新的（0.11.0.0，0.11.0.1或0.11.0.2）应用程序实例

​​0.11.0.3的显着变化​​

• ​​upgrade.from​​添加了新的Kafka Streams配置参数，该参数允许从0.10.0.x版进行滚动跳动升级
• 有关此新配置的详细信息，请参见​​Kafka Streams升级指南​​。

​​0.11.0.0中的显着变化​​

• 默认情况下，不干净的领导者选举现在是禁用的。新的默认设置优先考虑耐用性而不是可用性。希望保留先前行为的用户应将Broker Config设置​​unclean.leader.election.enable​​​为​​true​​。
• 生产者配置​​block.on.buffer.full​​​，​​metadata.fetch.timeout.ms​​​并​​timeout.ms​​已被删除。它们最初在Kafka 0.9.0.0中已弃用。
• 该​​offsets.topic.replication.factor​​券商的配置现在在强制汽车主题产生。内部自动主题创建将失败，并显示GROUP_COORDINATOR_NOT_AVAILABLE错误，直到群集大小满足此复制因子要求为止。
• 在使用快照压缩数据时，生产者和代理将使用压缩方案的默认块大小（2 x 32 KB）而不是1 KB，以提高压缩率。有报告说，以较小的块大小压缩的数据比以较大的块大小压缩的数据大50％。对于敏捷的情况，具有5000个分区的生产者将需要额外315 MB的JVM堆。
• 同样，使用gzip压缩数据时，生产者和代理将使用8 KB而不是1 KB作为缓冲区大小。gzip的默认值过低（512字节）。
• ​​max.message.bytes​​​现在，代理配置适用于一批消息的总大小。以前，该设置应用于批处理的压缩邮件，或分别应用于未压缩的邮件。消息批处理可能仅包含一条消息，因此在大多数情况下，批处理格式的开销只会减少对单个消息大小的限制。但是，消息格式转换有一些细微的含义（请参阅​​下面​​的详细信息）。还要注意，虽然以前代理将确保在每个获取请求中至少返回一条消息（无论总和分区级别的获取大小如何），但现在同一行为适用于一个消息批。
• 默认情况下，GC日志轮转处于启用状态，有关详细信息，请参见KAFKA-3754。
• 已删除了不推荐使用的RecordMetadata，MetricName和Cluster类的构造函数。
• 通过新的Headers接口添加了用户标头支持，从而提供了对用户标头的读写访问权限。
• ProducerRecord和ConsumerRecord通过​​Headers headers()​​方法调用公开了新的Headers API 。
• 引入ExtendedSerializer和ExtendedDeserializer接口以支持标头的序列化和反序列化。如果配置的序列化器和解串器不是上述类，则标题将被忽略。
• ​​group.initial.rebalance.delay.ms​​​引入了一个新的配置。此配置指定​​GroupCoordinator​​​延迟初始消费者重新平衡的时间（以毫秒为单位）。​​group.initial.rebalance.delay.ms​​​新成员加入论坛后，重新平衡的值将进一步延迟，最多为​​max.poll.interval.ms​​。缺省值为3秒。在开发和测试过程中，可能希望将其设置为0，以便不延迟测试执行时间。
• ​​org.apache.kafka.common.Cluster#partitionsForTopic​​​，​​partitionsForNode​​​并且在所需主题的元数据不存在的情况下，​​availablePartitionsForTopic​​​方法将返回一个空列表，而不是​​null​​（这是一种不好的做法）。
• Streams API配置参数​​timestamp.extractor​​​，​​key.serde​​​和​​value.serde​​​已被弃用，并分别由​​default.timestamp.extractor​​​，和代替。 ​​default.key.serde​​​​default.value.serde​​
• 对于Java使用者​​commitAsync​​​API 中的偏移提交失败，当的实例​​RetriableCommitFailedException​​​传递到提交回调时，我们不再暴露根本原因。有关 更多详细信息，请参见 ​​KAFKA-5052​​。

​​新协议版本​​

• ​​KIP-107​​​：FetchRequest v5引入了分区级​​log_start_offset​​字段。
• ​​KIP-107​​​：FetchResponse v5引入了分区级​​log_start_offset​​字段。
• ​​KIP-82​​​：ProduceRequest v3 ​​header​​​在消息协议中引入了一个数组，包含​​key​​​字段和​​value​​字段。
• ​​KIP-82​​​：FetchResponse v5引入​​header​​​了消息协议中的一个数组，包含​​key​​​字段和​​value​​字段。

​​关于完全语义的注释​​

Kafka 0.11.0包含对生产者中幂等和事务处理功能的支持。幂等传递确保在单个生产者的生存期内，消息仅精确地传递到特定主题分区一次。事务传递使生产者可以将数据发送到多个分区，以便成功传递所有消息或不传递任何消息。这些功能共同使Kafka中的语义“恰好一次”。用户指南中提供了有关这些功能的更多详细信息，但是下面我们添加了一些有关在升级的群集中启用它们的特定说明。请注意，不需要启用EoS，并且在未使用时不会影响代理的行为。

1. 只有新的Java生产者和使用者完全支持一次语义。
2. 这些功能主要取决于​​0.11.0消息格式​​。尝试以较旧的格式使用它们会导致不受支持的版本错误。
3. 事务状态存储在新的内部主题中​​__transaction_state​​​。在首次尝试使用事务请求API之前，不会创建此主题。与使用者补偿主题类似，有几种设置可以控制主题的配置。例如，​​transaction.state.log.min.isr​​控制此主题的最低ISR。有关选项的完整列表，请参见用户指南中的“配置”部分。
4. 对于安全群集，事务性API需要新的ACL，可以使用来打开这些ACL ​​bin/kafka-acls.sh​​。工具。
5. Kafka中的EoS引入了新的请求API并修改了几个现有的API。 完整信息请参见 ​​KIP-98​​

​​有关0.11.0中新消息格式的说明​​

0.11.0消息格式包括几个主要增强功能，以支持生产者更好的传递语义（请参阅​​KIP-98​​​）和改进的复制容错能力（请参阅​​KIP-101​​​）。尽管新格式包含更多信息以使这些改进成为可能，但我们使批处理格式更加有效。只要每批的消息数大于2，您就可以期望总体开销较低。但是，对于较小的批次，可能会对性能产生较小的影响。请参阅​​此处​​​以了解我们对新消息格式的初步性能分析的结果。您还可以在​​KIP-98​​提案中找到有关消息格式的更多详细信息 。

新消息格式的显着差异之一是，即使未压缩的消息也作为一个批次存储在一起。这对代理配置有一些影响，代理配置​​max.message.bytes​​​限制了单个批处理的大小。首先，如果较旧的客户端使用旧格式将消息生成到主题分区，并且这些消息分别小于​​max.message.bytes​​​，则在上转换过程中将消息 合并为单个批处理后，代理仍然可以拒绝它们。通常，当单个邮件的总大小大于时，就会发生这种情况​​max.message.bytes​​​。对于年长的消费者来说，阅读从新格式向下转换后的消息会有类似的效果：如果获取大小未设置为至少等于 ​​max.message.bytes​​​，即使个别未压缩的消息小于配置的提取大小，使用方也可能无法取得进展。对于0.10.1.0及更高版本，此行为不会影响Java客户端，因为它使用了更新的提取协议，该协议确保即使超过了提取大小，也至少可以返回一条消息。要解决这些问题，您应确保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代理的向上向后兼容性，因此可以在代理之前先升级客户端。

​​从0.8.x，0.9.x，0.10.0.x或0.10.1.x升级到0.10.2.0​​

0.10.2.0具有有线协议更改。通过遵循以下建议的滚动升级计划，可以保证升级期间不会停机。但是，请在升级之前查看​​0.10.2.0中​​​的​​显着更改​​。

从版本0.10.2开始，Java客户端（生产者和消费者）已经具有与较早的代理进行通信的能力。版本0.10.2的客户可以与版本0.10.0或更高版本的代理通信。但是，如果您的代理早于0.10.0，则必须先升级Kafka群集中的所有代理，然后再升级客户端。版本0.10.2代理支持0.8.x和更高版本的客户端。

对于滚动升级：

1. 在所有代理上更新server.properties文件，并添加以下属性：

• inter.broker.protocol.version = CURRENT_KAFKA_VERSION（例如0.8.2、0.9.0、0.10.0或0.10.1）。
• log.message.format.version = CURRENT_KAFKA_VERSION（有关此配置的详细信息，请参阅​​升级后​​​对​​性能的潜在影响​​。）

2. 一次升级一个代理：关闭代理，更新代码，然后重新启动。
3. 升级整个集群后，通过编辑inter.broker.protocol.version并将其设置为0.10.2来提高协议版本。
4. 如果您以前的消息格式为0.10.0，请将log.message.format.version更改为0.10.2（这是空操作，因为消息格式对于0.10.0、0.10.1和0.10.2相同）。如果您以前的消息格式版本低于0.10.0，请不要更改log.message.format.version-仅在所有使用者都升级到0.10.0.0或更高版本后，此参数才应更改。
5. 逐一重新启动代理，以使新协议版本生效。
6. 如果此时log.message.format.version仍低于0.10.0，请等待所有使用者升级到0.10.0或更高版本，然后在每个代理上将log.message.format.version更改为0.10.2，然后一一重启。

注意：如果您愿意接受停机时间，则只需关闭所有代理，更新代码并启动所有代理。默认情况下，它们将从新协议开始。

注意：升级代理后，可以随时更改协议版本并重新启动。不必紧随其后。

​​升级0.10.1 Kafka Streams应用程序​​

• 将Streams应用程序从0.10.1升级到0.10.2不需要代理升级。Kafka Streams 0.10.2应用程序可以连接到0.10.2和0.10.1代理（尽管无法连接到0.10.0代理）。
• 您需要重新编译代码。只是交换Kafka Streams库jar文件将不起作用，并且会破坏您的应用程序。
• 如果使用自定义（即用户实现的）时间戳提取器，则由于​​TimestampExtractor​​接口已更改，因此需要更新此代码。
• 如果注册自定义指标，则由于​​StreamsMetric​​界面已更改，因此需要更新此代码。
• 有关更多详细信息，请参见​​0.10.2中的Streams API更改​​。

​​升级0.10.0 Kafka Streams应用程序​​

• 将您的Streams应用程序从0.10.0升级到0.10.2确实需要​​升级代理，​​因为Kafka Streams 0.10.2应用程序只能连接到0.10.2或0.10.1代理。
• 有一些API更改，它们不向后兼容（请参阅​​0.10.2中的Streams API更改以​​获取更多详细信息）。因此，您需要更新并重新编译代码。只是交换Kafka Streams库jar文件将不起作用，并且会破坏您的应用程序。
• 从0.10.0.x升级到0.10.2.2需要两次滚动反弹，​​upgrade.from="0.10.0"​​​并为第一个升级阶段设置了配置（请参阅​​KIP-268​​）。或者，也可以进行脱机升级。

• 准备应用程序实例以进行滚动弹跳，并确保将config ​​upgrade.from​​​设置​​"0.10.0"​​为新版本0.10.2.2
• 反弹应用程序的每个实例一次
• 准备新部署的0.10.2.2应用程序实例以进行第二轮滚动弹跳；确保删除配置的值​​upgrade.mode​​
• 再次弹跳应用程序的每个实例以完成升级

• 从0.10.0.x升级到0.10.2.0或0.10.2.1需要离线升级（不支持滚动退回升级）

• 停止所有旧的（0.10.0.x）应用程序实例
• 更新您的代码，并用新代码和新jar文件交换旧代码和jar文件
• 重新启动所有新的（0.10.2.0或0.10.2.1）应用程序实例

​​0.10.2.2中的显着变化​​

• ​​upgrade.from​​添加了新的配置参数，该参数允许从0.10.0.x版进行滚动退回升级

​​0.10.2.1的显着变化​​

• 更改了StreamsConfig类的两个配置的默认值，以提高Kafka Streams应用程序的弹性。内部Kafka Streams生产者​​retries​​​默认值从0更改为10。内部Kafka Streams生产者​​max.poll.interval.ms​​​ 默认值从300000更改为​​Integer.MAX_VALUE​​。

​​0.10.2.0的显着变化​​

• Java客户端（生产者和消费者）已经具有与较早的代理进行通信的能力。版本0.10.2的客户可以与版本0.10.0或更高版本的代理通信。请注意，使用较旧的代理时，某些功能不可用或受限制。
• ​​InterruptException​​​如果调用线程中断，则Java使用者上的几种方法现在可能会抛出。请参阅​​KafkaConsumer​​Javadoc，以获得有关此更改的更深入的说明。
• Java使用者现在可以正常关闭了。默认情况下，使用者最多等待30秒才能完成待处理的请求。已添加新的带有超时的关闭API，​​KafkaConsumer​​以控制最大等待时间。
• 可以将新的Java使用者通过--whitelist选项将多个用逗号分隔的正则表达式传递给MirrorMaker。当使用旧的Scala使用者时，这使行为与MirrorMaker一致。
• 将Streams应用程序从0.10.1升级到0.10.2不需要代理升级。Kafka Streams 0.10.2应用程序可以连接到0.10.2和0.10.1代理（尽管无法连接到0.10.0代理）。
• Zookeeper依赖项已从Streams API中删除。Streams API现在使用Kafka协议来管理内部主题，而不是直接修改Zookeeper。这消除了直接访问Zookeeper的特权需求，并且不应再在Streams应用程序中设置“ StreamsConfig.ZOOKEEPER_CONFIG”。如果Kafka群集受到保护，则Streams应用程序必须具有所需的安全权限才能创建新主题。
• StreamsConfig类中添加了几个新字段，包括“ security.protocol”，“ connections.max.idle.ms”，“ retry.backoff.ms”，“ reconnect.backoff.ms”和“ request.timeout.ms”。用户应注意默认值，并在需要时进行设置。有关更多详细信息，请参阅​​3.5 Kafka Streams Configs​​。

​​新协议版本​​

• ​​KIP-88​​​：如果将​​topics​​​数组设置为，则OffsetFetchRequest v2支持检索所有主题的偏移量​​null​​。
• ​​KIP-88​​​：OffsetFetchResponse v2引入了一个顶级​​error_code​​字段。
• ​​KIP-103​​​：UpdateMetadataRequest v3 ​​listener_name​​​向该​​end_points​​数组的元素引入了一个字段。
• ​​KIP-108​​​：CreateTopicsRequest v1引入了一个​​validate_only​​字段。
• ​​KIP-108​​​：CreateTopicsResponse v1 ​​error_message​​​向该​​topic_errors​​数组的元素引入了一个字段。

​​从0.8.x，0.9.x或0.10.0.X升级到0.10.1.0​​

0.10.1.0具有有线协议更改。通过遵循以下建议的滚动升级计划，可以保证升级期间不会停机。但是，请注意升级前​​0.10.1.0中​​​的​​潜在突破更改​​​。
注意：由于引入了新协议，因此在升级客户端之前先升级Kafka群集很重要（即0.10.1.x客户端仅支持0.10.1.x或更高版本的代理，而0.10.1.x代理也支持较旧的客户端） 。

对于滚动升级：

1. 在所有代理上更新server.properties文件，并添加以下属性：

• inter.broker.protocol.version = CURRENT_KAFKA_VERSION（例如0.8.2.0、0.9.0.0或0.10.0.0）。
• log.message.format.version = CURRENT_KAFKA_VERSION（有关此配置的详细信息，请参阅​​升级后​​​对​​性能的潜在影响​​。）

2. 一次升级一个代理：关闭代理，更新代码，然后重新启动。
3. 升级整个集群后，通过编辑inter.broker.protocol.version并将其设置为0.10.1.0来提高协议版本。
4. 如果以前的消息格式为0.10.0，则将log.message.format.version更改为0.10.1（这是空操作，因为消息格式对于0.10.0和0.10.1都是相同的）。如果您以前的消息格式版本低于0.10.0，请不要更改log.message.format.version-仅在所有使用者都升级到0.10.0.0或更高版本后，此参数才应更改。
5. 逐一重新启动代理，以使新协议版本生效。
6. 如果此时log.message.format.version仍低于0.10.0，请等待所有使用者升级到0.10.0或更高版本，然后在每个代理上将log.message.format.version更改为0.10.1，然后一一重启。

注意：如果您愿意接受停机时间，则只需关闭所有代理，更新代码并启动所有代理。默认情况下，它们将从新协议开始。

注意：升级代理后，可以随时更改协议版本并重新启动。不必紧随其后。

​​潜在的突破性变化0.10.1.0​​

• 日志保留时间不再基于日志段的最后修改时间。相反，它将基于日志段中消息的最大时间戳。
• 日志滚动时间不再取决于日志段创建时间。现在，它现在基于消息中的时间戳。进一步来说。如果段中第一条消息的时间戳为T，则当新消息的时间戳大于或等于T + log.roll.ms时，将推出日志。
• 由于为每个段添加了时间索引文件，因此0.10.0的打开文件处理程序将增加约33％。
• 时间索引和偏移索引共享相同的索引大小配置。由于每个时间索引条目都是偏移索引条目大小的1.5倍。用户可能需要增加log.index.size.max.bytes以避免潜在的频繁日志滚动。
• 由于索引文件数量的增加，在某些具有大量日志段（例如> 15K）的代理上，代理启动期间的日志加载过程可能会更长。根据我们的实验，将num.recovery.threads.per.data.dir设置为1可以减少日志加载时间。

​​升级0.10.0 Kafka Streams应用程序​​

• 将您的Streams应用程序从0.10.0升级到0.10.1确实需要​​代理升级，​​因为Kafka Streams 0.10.1应用程序只能连接到0.10.1代理。
• 有几个API更改，它们不向后兼容（请参见​​0.10.1中的Streams API更改以​​获取更多详细信息）。因此，您需要更新并重新编译代码。只是交换Kafka Streams库jar文件将不起作用，并且会破坏您的应用程序。
• 从0.10.0.x升级到0.10.1.2需要两次滚动反弹，​​upgrade.from="0.10.0"​​​并为第一个升级阶段设置了配置（请参阅​​KIP-268​​）。或者，也可以进行脱机升级。

• 准备应用程序实例以进行滚动弹跳，并确保将config ​​upgrade.from​​​设置​​"0.10.0"​​为新版本0.10.1.2
• 反弹应用程序的每个实例一次
• 准备新部署的0.10.1.2应用程序实例，以进行第二轮滚动弹跳；确保删除配置的值​​upgrade.mode​​
• 再次弹跳应用程序的每个实例以完成升级

• 从0.10.0.x升级到0.10.1.0或0.10.1.1需要离线升级（不支持滚动退回升级）

• 停止所有旧的（0.10.0.x）应用程序实例
• 更新您的代码，并用新代码和新jar文件交换旧代码和jar文件
• 重新启动所有新的（0.10.1.0或0.10.1.1）应用程序实例

​​0.10.1.0的显着变化​​

• 新的Java使用者不再处于beta中，我们建议所有新开发人员使用它。仍然支持旧的Scala使用者，但是它们将在下一个版本中弃用，并在以后的主要版本中将其删除。
• 将​​--new-consumer​​​/ ​​--new.consumer​​开关不再需要使用的工具，像MirrorMaker和控制台与消费者新的消费; 只需通过Kafka经纪人即可连接，而不是ZooKeeper集成。此外，已不建议将Console Consumer与旧的Consumer一起使用，并且在将来的主要版本中将其删除。
• 现在，可以通过集群ID唯一地标识Kafka集群。当代理升级到0.10.1.0时，它将自动生成。可以通过kafka.server：type = KafkaServer，name = ClusterId指标获得集群ID，它是元数据响应的一部分。序列化程序，客户端拦截器和度量标准报告程序可以通过实现ClusterResourceListener接口来接收群集ID。
• BrokerState“ RunningAsController”（值4）已被删除。由于存在错误，代理在过渡之前仅会短暂处于此状态，因此删除的影响应最小。推荐的检测给定代理是否为控制器的方法是通过kafka.controller：type = KafkaController，name = ActiveControllerCount指标。
• 新的Java使用者现在允许用户按分区上的时间戳搜索偏移量。
• 新的Java Consumer现在支持从后台线程进行心跳。有一个新的配置 ​​max.poll.interval.ms​​​可控制使用者主动离开组之前轮询调用之间的最长时间（默认为5分钟）。配置的值 ​​request.timeout.ms​​​必须始终大于，​​max.poll.interval.ms​​​因为这是在使用者重新平衡时JoinGroup请求可以在服务器上阻止的最长时间，因此我们将其默认值更改为刚好超过5分钟。最后，默认值​​session.timeout.ms​​​已调整为10秒，默认值​​max.poll.records​​已更改为500。
• 当使用授权器并且用户没有主题的“ 描述”授权时，代理将不再向请求返回TOPIC_AUTHORIZATION_FAILED错误，因为这会泄漏主题名称。相反，将返回UNKNOWN_TOPIC_OR_PARTITION错误代码。在使用生产者和使用者时，这可能会导致意外的超时或延迟，因为Kafka客户端通常会根据未知的主题错误自动重试。如果您怀疑可能会发生这种情况，则应查阅客户端日志。
• 默认情况下，访存响应具有大小限制（使用方50 MB，复制10 MB）。现有的每个分区限制也适用（使用方和复制1 MB）。请注意，这些限制都不是绝对最大值，如下所述。
• 如果发现消息大于响应/分区大小限制，则使用者和副本服务器可以取得进展。更具体地说，如果提取的第一个非空分区中的第一条消息大于一个或两个限制，则仍将返回该消息。
• 重载的构造函数已添加到其中，​​kafka.api.FetchRequest​​​并​​kafka.javaapi.FetchRequest​​允许调用者指定分区的顺序（因为顺序在v3中很重要）。在发送请求之前，已弃用了先前存在的构造函数，并对分区进行了改组，以避免出现饥饿问题。

​​新协议版本​​

• ListOffsetRequest v1支持基于时间戳的精确偏移搜索。
• MetadataResponse v2引入了一个新字段：“ cluster_id”。
• FetchRequest v3支持限制响应大小（除了现有的每个分区限制外），如果需要进步，它会返回大于限制的消息，并且请求中的分区顺序现在很重要。
• JoinGroup v1引入了一个新字段：“ rebalance_timeout”。

​​从0.8.x或0.9.x升级到0.10.0.0​​

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.X或0.9.0.1客户端，此步骤不是必需的。

对于滚动升级：

1. 在所有代理上更新server.properties文件，并添加以下属性：

• inter.broker.protocol.version = CURRENT_KAFKA_VERSION（例如0.8.2或0.9.0.0）。
• log.message.format.version = CURRENT_KAFKA_VERSION（有关此配置的详细信息，请参阅​​升级后​​​对​​性能的潜在影响​​。）

2. 升级经纪人。可以通过简单地将其关闭，更新代码并重新启动它来一次完成代理。
3. 升级整个集群后，通过编辑inter.broker.protocol.version并将其设置为0.10.0.0来提高协议版本。注意：您还不应该触摸log.message.format.version-仅当所有使用者升级到0.10.0.0后，此参数才应更改
4. 逐一重新启动代理，以使新协议版本生效。
5. 将所有使用者升级到0.10.0之后，将每个代理上的log.message.format.version更改为0.10.0，然后逐一重新启动它们。

注意：如果您愿意接受停机时间，则只需关闭所有代理，更新代码并启动所有代理。默认情况下，它们将从新协议开始。

注意：升级代理后，可以随时更改协议版本并重新启动。不必紧随其后。

​​升级到0.10.0.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时，将message.format.version更改为0.8.2或0.9.0。这样，代理仍然可以使用零拷贝传输将数据发送给旧使用者。使用者升级后，可以在代理上将消息格式更改为0.10.0，并享受新的消息格式，包括新的时间戳和改进的压缩。支持该转换以确保兼容性，并且可以用于支持一些尚未更新到较新客户端的应用程序，但是即使在配置过大的群集上也无法支持所有消费者流量。因此，至关重要的是，在升级代理但大多数客户端没有升级时，尽可能避免消息转换。将代理升级到0.10.0.0时，将message.format.version更改为0.8.2或0.9.0。这样，代理仍然可以使用零拷贝传输将数据发送给旧使用者。使用者升级后，可以在代理上将消息格式更改为0.10.0，并享受新的消息格式，包括新的时间戳和改进的压缩。支持该转换以确保兼容性，并且可以用于支持一些尚未更新到较新客户端的应用程序，但是即使在配置过大的群集上也无法支持所有消费者流量。因此，至关重要的是，在升级代理但大多数客户端没有升级时，尽可能避免消息转换。经纪人仍可以使用零拷贝传输将数据发送给旧使用者。使用者升级后，可以在代理上将消息格式更改为0.10.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版本中使其可配置。

​​0.10.0.0中的潜在突破性变化​​

• 从Kafka 0.10.0.0开始，Kafka中的消息格式版本表示为Kafka版本。例如，消息格式0.9.0是指Kafka 0.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]])​​方法，因为它从未被调用过。
• Kafka不再打包0.7 KafkaMigrationTool。如果需要从0.7迁移到0.10.0，请先迁移到0.8，然后按照记录的升级过程从0.8升级到0.10.0。
• 新使用者已经对其API进行了标准化，以接受​​java.util.Collection​​作为方法参数的序列类型。可能必须更新现有代码才能与0.10.0客户端库一起使用。
• LZ4压缩的消息处理已更改为使用可互用的框架规范（LZ4f v1.5.1）。为了保持与旧客户端的兼容性，此更改仅适用于消息格式0.10.0及更高版本。使用v0 / v1（消息格式0.9.0）产生/获取LZ4压缩消息的客户端应继续使用0.9.0框架实现。使用生产/获取协议v2或更高版本的客户端应使用可互操作的LZ4f成帧。可互操作的LZ4库列表可在http://www.lz4.org/获得。

​​0.10.0.0的显着变化​​

• 从Kafka 0.10.0.0开始，一个名为Kafka Streams的新客户端库可用于对存储在Kafka主题中的数据进行流处理。由于上述消息格式的更改，此新客户端库仅适用于0.10.x和更高版本的代理。有关更多信息，请阅读​​Streams文档​​。
• ​​receive.buffer.bytes​​现在，新使用者的配置参数的默认值为64K。
• 现在，新使用者可以公开配置参数，​​exclude.internal.topics​​以限制内部主题（例如使用者偏移量主题）不被意外包含在正则表达式预订中。默认情况下，它是启用的。
• 旧的Scala生产商已被弃用。用户应尽快将其代码迁移到kafka-clients JAR中包含的Java生产者中。
• 新的使用者API已标记为稳定。

​​从0.8.0、0.8.1.X或0.8.2.X升级到0.9.0.0​​

0.9.0.0具有​​潜在的重大更改​​（请在升级之前进行检查），并且中间版本协议与以前的版本相比有所更改。这意味着升级的代理和客户端可能与旧版本不兼容。在升级客户端之前，先升级Kafka群集很重要。如果您使用的是MirrorMaker，则下游集群也应首先升级。

对于滚动升级：

1. 更新所有代理上的server.properties文件并添加以下属性：inter.broker.protocol.version = 0.8.2.X
2. 升级经纪人。可以通过简单地将其关闭，更新代码并重新启动它来一次完成代理。
3. 升级整个集群后，通过编辑inter.broker.protocol.version并将其设置为0.9.0.0来提高协议版本。
4. 逐一重新启动代理，以使新协议版本生效

注意：如果您愿意接受停机时间，则只需关闭所有代理，更新代码并启动所有代理。默认情况下，它们将从新协议开始。

注意：升级代理后，可以随时更改协议版本并重新启动。不必紧随其后。

​​0.9.0.0中的潜在突破性变化​​

• 不再支持Java 1.6。
• 不再支持Scala 2.9。
• 现在默认将大于1000的代理ID保留为自动分配的代理ID。如果您的集群中现有的代理ID超过该阈值，请确保相应地增加reserved.broker.max.id代理配置属性。
• 配置参数copy.lag.max.messages已删除。在确定哪些副本同步时，分区负责人将不再考虑滞后消息的数量。
• 配置参数copy.lag.time.max.ms现在不仅指自从上次从副本获取请求以来经过的时间，而且还指自副本上一次被捕获以来的时间。仍在从领导者那里获取消息但未赶上copy.lag.time.max.ms中最新消息的副本将被视为不同步。
• 压缩的主题不再接受没有密钥的消息，如果尝试这样做，生产者将引发异常。在0.8.x中，没有密钥的消息将导致日志压缩线程随后抱怨并退出（并停止压缩所有压缩的主题）。
• MirrorMaker不再支持多个目标群集。结果，它将仅接受一个--consumer.config参数。要镜像多个源集群，每个源集群至少需要一个MirrorMaker实例，每个实例都有自己的使用者配置。
• org.apache.kafka.clients.tools。*下打包的工具已移至org.apache.kafka.tools。*。所有包含的脚本仍将照常运行，仅直接导入这些类的自定义代码将受到影响。
• 默认的Kafka JVM性能选项（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生产者，并且用户必须指定“ old-producer”才能使用旧生产者。
• 默认情况下，所有命令行工具会将所有日志记录消息打印到stderr而不是stdout。

​​0.9.0.1的显着变化​​

• 可以通过将broker.id.generation.enable设置为false来禁用新的代理ID生成功能。
• 默认情况下，配置参数log.cleaner.enable现在为true。这意味着带有cleanup.policy = compact的主题现在将默认压缩，并且将通过log.cleaner.dedupe.buffer.size将128 MB的堆分配给清理程序。您可能要根据压缩主题的使用情况来查看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，并且meta.fetch.timeout.ms将不被接受

​​从0.8.1升级到0.8.2​​

0.8.2与0.8.1完全兼容。只需将其关闭，更新代码并重新启动，即可一次完成一个代理的升级。

​​从0.8.0升级到0.8.1​​

0.8.1与0.8完全兼容。只需将其关闭，更新代码并重新启动，即可一次完成一个代理的升级。

​​从0.7升级​​

版本0.7与较新版本不兼容。为了增加复制，对API，ZooKeeper数据结构，协议和配置进行了重大更改（缺少0.7）。从0.7升级到更高版本需要​​专用​​​的迁移​​工具​​。无需停机即可进行迁移。