Kafka3.9.0版本的内容可参考https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.9.0

1.发布时间

KIP Freeze时间：2024年7月3日

Feature Freeze时间：2024年7月24日

Code Freeze时间：2024年8月7日

至少两周的稳定性测试后，期待在2024年8月14日之后发布。

2.版本需求

主要包含以下重要的特性。

2.1.KIP-1025: 选择性将clientId和clientSecret以URL编码形式加入到授权请求header中

根据RFC-6749规范，客户端通过OIDC获取token的时候，clientId和clientSecret必须以URL编码的形式加在授权请求header中。AuthenticateCallbackHandler的实现并没有把clientId和clientSecret加在header中，这会导致一些客户端的认证请求失败。

实际上，并不是所有的OIDC机制都需要满足这个要求。此外，clientId和clientSecret也并不包含一些需要URL编码的特殊字符，这估计就是当前ISSUE并没有被report的原因。

我在这里提议提供一个新的配置，用于是否允许客户端将ClientId和clientSecret以URL编码的形式加入到授权请求header中。

2.2.KIP-1023: Follower fetch from tiered offset

2.3.KIP-1007: Introduce Remote Storage Not Ready Exception

2.4.KIP-1005: Expose EarliestLocalOffset and TieredOffset

2.5.KIP-996: Pre-Vote

2.6.KIP-994: Minor Enhancements to ListTransactions and DescribeTransactions APIs

2.7.KIP-977: 分区级别吞吐量指标

目前，MessagesInPerSec是一个topic级别的吞吐量指标，这个指标不包含分区信息。MessagesInPerSec指标为衡量topic地吞吐量提供了重要信息，在topic的分区和限额管理充当一个杠杆的角色。

但是，如果一个topic的流量是不均衡的，总体的吞吐量指标并不能反馈出局部的不平衡。这在一些关键的topic中可能会成为大问题，比如某些热点的消息会进入特定的分区，导致这部分分区所在的broker或磁盘超负荷。在这个案例中，有以下几个难点：

（1）topic 分区的扩容并不能解决broker端的扩展性问题，因为消息还是会发送到热点分区。

（2）我们也没有机会去识别这些不均衡的分区，并相应地进行producer再均衡或告警。

（3）目前大多数案例中，一个kafka分区绑定到一个consumer实例，考虑到不均衡的topic，那么consumer可能负载过重，我们也没有机会预先发现和解决这个问题。

2.8.KIP-966: Eligible Leader Replicas

2.9.KIP-956 Tiered Storage Quotas

2.10.KIP-950: Tiered Storage Disablement

2.11.KIP-853: KRaft Controller Membership Changes