Apache Kafka 3.8 新特性解读

2024 年 7.29 日 Apache Kafka 3.8 正式发布 [1]。该版本包含了诸多新特性与多达 456 个来自 JIRA 的改进与修复 [2]。AutoMQ 作为云原生的 Apache Kafka 替代产品，可以保证对 Apache Kafka 的 100% 完全兼容，因此也会尽快合并 Kafka 上游社区 3.8 的最新改动。这篇文章对 Apache Kafka 3.8 的主要新特性做一个简单总结和解读。

GraavlVM[4] 是一款由 Oracle 推出的高性能、低资源消耗、快速启动的 JDK。利用 AOT 编译生成 Native Image 使得 Java 拥有更快的启动速度和更低的内存消耗，从而更好的适应云原生时代。

KIP 974[7] 为 Apache Kafka 提供了一个使用 KRaft 模式，基于 GraalVM 的 Native Docker Image。采用该 Native Image，可以将 Broker 的启动时间缩小到 140ms 以内 (原来差不多需要 3s)。更快的 Broker 启动速度可以使得开发者需要运行大批量的 Broker 测试的场景时更有效率。

Tips: 该特性只是当前服务于测试，不要在生产环境下使用。

KIP-1028 引入了 JVM-Based 的 Docker Official Image(DOI)。Docker hub 本身也包含由 Apache 开源社区维护的镜像例如 apache/kafka:3.8.0。但是由 Apache Kafka 社区维护并且通过 Docker 官方发布的 DOI 因为其构建流程更加严格透明，因此具有更好的安全性。此外由于是 Docker 官方镜像，在 Docker Hub 上也更加容易被用户检索到和使用。

这是一个比较重要的特性。过去 Kafka 消费者的重平衡协议主要问题是：

• 依赖胖客户端：必须依赖客户端日志来排查重平衡问题，在云时代比较麻烦。新协议会把客户端的复杂性全部转移到 group coordinator。

• 依赖消费者组维度的同步屏障：单个行为不当的消费者可能会破坏或扰乱整个组，因为每当消费者加入、离开或失败时，都需要对整个组进行重新平衡。此外，在消费者等待重新平衡完成时，无法提交偏移量。新协议不再依赖全局同步屏障，如果消费者的分配没有改变，则消费者不会受到重新平衡的影响。

• 过于复杂有历史包袱: 原来做了很多改进优化使得重平衡协议变得很复杂。此外还把组协议用于成员之间的一般状态传播，职能的扩散引发了新的复杂度以及歧义。新协议会解决这些历史问题。

3.8 以前是 log4j 和 log4j2 共存，一些情况下导致日志无法正确输出。3.8 将彻底弃用 log4j-appender 并将所有省略的模块（即工具、trogdor 和 shell）升级到 log4j2，以从类路径中完全删除 log4j 工件并避免上述问题。3.8 在 Kafka 层面已经不依赖 log4j 了，但是用户还是可以使用 log4j，但是会有 warning，按照社区计划，预计是 4.0 把 log4j 从项目真正的删除。

log4j-appender is deprecated and will be removed in a future release. For migration, please refer to the latest documentation.

开启压缩会影响生产者发送消息的效率。3.8 以前 Apache Kafka 没有提供压缩级别的配置，这使得用户无法自定义调整压缩率和性能之间的权衡。3.8 以后用户可以针对不同的压缩编码方式设置不同的压缩级别。

配置压缩级别方式如下：

 compression.type=gzipcompression.gzip.level=4                # NEW: Compression level to be used.

不同压缩算法对应可选的压缩级别

安全性的改进。过去 Kafka 对于访问的文件和目录是无限制的，现在可以做一些限制使得其更加安全：

 config.providers=directory
config.providers.directory.class=org.apache.kafka.connect.configs.DirectoryConfigProvider
config.providers.directory.param.allowed.paths=/var/run,var/configs

拓展 KIP-334，针对 RecordDeserializationException 这个异常额外增加 record 的内容和元信息，使得下游接收这个报错后可以更加容易去实现类似死信队列这样的能力。

给 KafkaMetric 类提供一个新的方法用于判断 value provider 是否是 measurable 的。相比原来的 measurable 的好处是，不需要依赖异常来确认是否为 mesurable，并且也避免了去访问私有字段。

 /** * The method determines if the metric value provider is of type Measurable. * * @return true if the metric value provider is of type Measurable, false otherwise. */public boolean isMeasurable();

是针对 Kafka Streams 的一个优化。通过引入一些新的 metric，方便开发者可以排查 Iterator 的泄露。

Task Assignor 是 KStream 里面负责给节点分配任务的组件 [5]。3.8 添加一组新的可配置接口，用于将自定义行为插入 Streams Partition Assignor 来使用自定义的 Task Assignor 从而带来更好的灵活性。

State Stores 在 KStream 里面用来保存流应用的状态数据 [5]。State Stores 底层也是通过一个 topic 来实现的。过去这个 topic 不能在不同的 stream task 之间被共享，现在则可以被共享来减少数据冗余改善性能。

过去通过 tasks.max 来限制 Kafka connect 生成的任务是无效的，在 3.8 以后可以通过该参数做强置限制。属于修复了一个历史遗留的 BUG。

剥离几百万行代码，复制核心算法去美国？TikTok 最新回应来了

拒绝背锅！39 岁失业后，我写出了一个超一万亿使用量的数据库

才 12 万并发用户在线就直接崩溃？马斯克直播成“大型翻车现场”，专家：“网络攻击”说法站不住脚

下载量超 5000 万的知名应用，开发团队“全军覆没”，从此发版人唯剩老板一个