Kafka各个版本差异汇总

最新推荐文章于 2025-04-06 19:47:11 发布

weixin_34138056

最新推荐文章于 2025-04-06 19:47:11 发布

阅读量6.7k

点赞数

文章标签：大数据 java scala

本文汇总了Kafka从0.8.x到2.0.0的升级过程，详述了每个版本的重大变更、新协议版本以及滚动升级步骤。主要变更包括：线程协议、消息格式、Kafka Streams应用程序的升级兼容性和性能优化。在升级过程中，需关注协议版本、消息格式版本的设置，以及可能影响性能的消息转换。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

　　　　　　　　　　　　　　　　　　　　　　Kafka各个版本差异汇总

从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中的重大更改。

对于滚动升级：

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

其他升级说明：

如果您愿意接受停机时间，您可以简单地关闭所有代理，更新代码并重新启动它们。默认情况下，它们将以新协议开始。
在升级代理后，可以随时进行协议版本的碰撞并重新启动。它不一定要立即。同样适用于消息格式版本。
如果您在Kafka Streams代码中使用Java8方法引用，则可能需要更新代码以解决方法歧义。仅交换jar文件可能不起作用。
不应将ACL添加到前缀资源（在KIP-290中添加），直到集群中的所有代理都已更新。
注意：如果群集再次降级，则即使在群集完全升级后，也会忽略添加到群集的任何带前缀的ACL。

2.0.0中的显着变化

KIP-186将默认偏移保留时间从1天增加到7天。这使得在不经常提交的应用程序中“丢失”偏移的可能性降低。它还会增加活动的偏移量，因此可以增加代理上的内存使用量。请注意，控制台使用者当前默认启用偏移提交，并且可以是大量偏移的来源，此更改现在将保留7天而不是1.您可以通过将代理配置设置offsets.retention.minutes为1440 来保留现有行为。
已经删除了对Java 7的支持，Java 8现在是所需的最低版本。
默认值ssl.endpoint.identification.algorithm已更改为https，执行主机名验证（否则可能是中间人攻击）。设置ssl.endpoint.identification.algorithm为空字符串以恢复以前的行为。
KAFKA-5674将较低的间隔扩展max.connections.per.ip minimum为零，因此允许对入站连接进行基于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，1.1.0（及更早版本）中的Scala使用者也将继续工作。
自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的worker配置需要internal.key.converter和internal.value.converter属性。在2.0中，不再需要这些，并且默认为JSON转换器。您可以安全地从Connect独立和分布式工作器配置中删除这些属性：
internal.key.converter=org.apache.kafka.connect.json.JsonConverter internal.key.converter.schemas.enable=falseinternal.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，它不会阻止动态分区分配。旧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增加了在前缀资源上定义ACL的功能，例如以'foo'开头的任何主题。
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：Bump up协议版本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中的重大更改。

对于滚动升级：

更新所有代理上的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）。
一次升级一个代理：关闭代理，更新代码并重新启动它。
升级整个群集后，通过编辑inter.broker.protocol.version并将其设置为1.1来破坏协议版本。
逐个重新启动代理以使新协议版本生效。
如果您已按照上面的说明覆盖了消息格式版本，则需要再执行一次滚动重新启动以将其升级到其最新版本。将所有（或大多数）使用者升级到0.11.0或更高版本后，在每个代理上将log.message.format.version更改为1.1并逐个重新启动它们。请注意，旧的Scala使用者不支持0.11中引入的新消息格式，因此为了避免下转换的性能成本（或者只利用一次语义），必须使用较新的Java使用者。