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

感谢英文原文链接:Apache Kafka

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

滚动升级：

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.提高协议版本。
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. 该ListGroupAPI现在希望作为推荐的替代方法Describe Group访问用户应该能够列出的组。Describe Cluster为了实现向后兼容性，仍然支持旧访问，不建议使用它API。
6. KIP-336弃用了ExtendedSerializer和ExtendedDeserializer接口，并传播Serializer和Deserializer的用法。KIP-82引入了ExtendedSerializer和ExtendedDeserializer，以Java 为序列化器和反序列化器提供记录头。现在我们已经合并了这些接口，因为从那时起我们就不再支持它们了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压缩。您必须升级代理和客户端才能使用它。.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。
• ProcessorStateManagerKafka 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.serdedefault.value.serde
• 对于Java使用者commitAsyncAPI 中的偏移提交失败，当的实例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.bytes2，消费者的获取大小至少设置为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使用者上的几种方法现在可能会抛出。请参阅KafkaConsumerJavadoc，以获得有关此更改的更深入的说明。
• 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文件将不起作用，并且会破坏您的应用程序。
• 从