Kafka3.7.0发布信息可参考https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0

1.发布时间

KIP Freeze时间：2023年11月22日

Feature Freeze时间：2023年12月6日

Code Freeze时间：2023年12月20日

2.版本需求

Kafka3.7.0中实现了以下需求特性。

2.1.KIP-405: Kafka数据分级存储

Kafka3.6.0中完成了主体功能，Kafka3.7.0完成剩余的功能。

2.2.KIP-580: kafka客户端指数型等待时间增长

元数据拉取是我们在kafka中遇到的最普遍的问题之一。比如，某个broker挂了，所有的客户端都会同时拉取元数据，但是这些元数据的聚合一般需要一些时间。在一个高负载的集群中，元数据多了后也会加剧这个问题，使得元数据的聚合更慢了。原因就在于我们有一个静态的间隔重试机制。但是当间隔很小时，我们可以每秒发送几十个请求到broker，如果连接问题还没有解决，才会导致上面所说的问题。为了减轻这个压力，kafka客户端使用指数型时间间隔增长策略时比较有效的，和KIP-144中介绍的配置类似，在与broker重连的重试中，相邻重试次数之间的时间间隔呈指数增长。

2.3.KIP-714: Client metrics and observability

2.4.KIP-848: 下一代consumer rebalance机制

距离上一次进行consumer rebalance机制的优化已经有8年时间了，虽然new consumer相对于zookeeper的consumer有大的改进，但在操作上还是有大的痛点，下面就是一些理由：

（1）当前协议以来厚重的客户端，厚重的客户端会带来以下不便：

• 过去几年，rebalance机制产生过许多的bug，而大部分bug都是需要在客户端进行修复。在云计算中，这是令人非常烦恼的，为了解决生产上的问题，我们及其依赖客户端的适配。不幸的是，这种适配进度在kafka社区是非常缓慢的。

• 如果不通过客户端的日志，几乎不可能分析到bug的根因。在云计算中，因为系统的troubleshoot而需要取请求客户端的日志，这是令人烦恼的事情。

• 客户端明确提出要把这些所谓的嵌入式协议放到rebalance协议中。这就要求核心协议需要被用于不同的目的，例如可以用于consumer和connect模块，这会让透视broker端的状态变得困难，因为broker中有一些bytes信息。这些潜入式协议的兼容也是一大挑战。

• 客户端触发rebalance协议主要是通过监控元数据来实现的。这在过去带来了一系列问题，因为一个给定group的客户端可能在同一时间点对元数据的视图是不一致的。

（2）rebalance协议以来group范围内的同步屏障，这就意味着一个简单的不规范的consumer就会扰乱或毁掉整个group，因为每当consumer加入、离开或失败时，都需要整个group的rebalance。这也限制了它的扩展性，因为rebalance的成本随着group中成员的增加而增加，即使协同的rebalance协议依赖这些屏障。特别要指出地，协同协议的缺陷之一是，当consumer在等待rebalance完成时，无法提交offset。在rebalance过程中，即使consumer不停地fetch，它仍然倾向于困在屏障后面。

（3）多年来，rebalance协议变得过于复杂。我们从一个相当简单的协议开始，多年来进行了多次扩展。例如，KIP-249增加了kafka consumer增量式rebalance协议。KIP-345引入了静态成员协议，以减少消费者rebalance次数。我们所做的所有增量修改都增加了rebalance协议的复杂性。

（4）group协议已用于成员间通用状态传递。特别是kafka stream这样的超级用户来说。虽然状态传递本身不是问题，但协议只在rebalance期间进行传递，因此我们引入了虚假或伪rebalance，其唯一目标是将新状态传递给group的leader或group内所有的消费者。对于客户端和broker端的用户来说，通过指标或日志来演绎rebalance过程也变得更加困难。

KIP-858: Handle JBOD broker disk failure in KRaft

KIP-890: Transactions Server-Side Defense

KIP-896: Remove old client protocol API versions in Kafka 4.0 - metrics/request log changes to identify deprecated apis

KIP-919: Allow AdminClient to Talk Directly with the KRaft Controller Quorum and add Controller Registration

KIP-925: Rack aware task assignment in Kafka Streams

KIP-951 - Leader discovery optimizations for the client

KIP-954: expand default DSL store configuration to custom types

KIP-959: Add BooleanConverter to Kafka Connect

KIP-960: Single-key single-timestamp IQv2 for state stores

IP-962: Relax non-null key requirement in Kafka Streams

KIP-963: Additional metrics in Tiered Storage

KIP-968: Support single-key_multi-timestamp Interactive Queries (IQv2) for Versioned State Stores

KIP-970: Deprecate and remove Connect's redundant task configurations endpoint

KIP-975: Docker Image for Apache Kafka

KIP-976: Cluster-wide dynamic log adjustment for Kafka Connect

KIP-978: Allow dynamic reloading of certificates with different DN / SANs

KIP-979: Allow independently stop KRaft processes

KIP-980: Allow creating connectors in a stopped state

KIP-985: Add reverseRange and reverseAll query over kv-store in IQv2

KIP-988: Streams Standby Update Listener

KIP-992: Proposal to introduce IQv2 Query Types: TimestampedKeyQuery and TimestampedRangeQuery

KIP-1000: List Client Metrics Configuration Resources

KIP-1001: Add CurrentControllerId Metric