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

1.发布时间

KIP Freeze时间：2023年3月22日

Feature Freeze时间：2023年4月12日

Code Freeze时间：2023年4月26日

代码封板后，最少需要保持2周的稳定期。

2.版本需求

Kafka3.5.0对以下19个特性进行了开发。

2.1.KIP-881: 机架感知的kafka consumer分区分配

Kafka集群通常分布在多个可用区（AZ）中，特别是在云部署中。KIP-36中引入的Kafka中的机架感知副本分布支持将可用区域配置为broker的机架。每个分区的副本分布在不同的可用性区域中，以确保区域中断时不会影响分区的可用性。KIP-392增加了对consumer从最近的replica中获取的支持。此功能使consumer能够在可能的情况下从同一可用区域内的leader或follower那里获取数据，以从本地性中受益。

机架感知的Kafka部署根据每个broker的机架（可能是AZ标识符）为其配置broker.Rack。代理还可以配置replica.selector.class，以确定用于从中读取数据的首选replica。默认副本选择器使用leader作为读取的首选副本，但内置的RackAwareReplicationSelector可以配置为将replica的机架与consumer的机架相匹配。使用此功能的消费者可以通过配置client.rack从本地性中受益，并避免昂贵的跨AZ流量。机架ID在获取请求中传播给broker，这使机架感知副本选择器能够选择与consumer位于同一机架上的副本，并将此信息提供给消费者，以便在后续的获取请求中使用。此功能在每个机架都包含所有分区的副本的情况下效果良好。例如，对于具有三个AZ和复制因子3的Kafka部署，机架感知副本放置将三个副本放置在3个AZ上。因此，每个AZ都有每个分区的副本。这使得3个AZ中的任何一个的消费者都可以从他们的本地副本中消费。如果副本的数量低于AZ或机架的数量，可能是因为AZ的数量高于复制因子，则某些分区可能在某些AZ上没有副本。在这些AZ上运行的消费者将不得不从另一个AZ的领导者那里获取数据。在这种情况下，消费者的机架感知分区分配将提高局部性。

KIP-848描述了下一代消费者组协议，该协议修复了现有协议的几个问题。该提案已经在协议中包含了机架信息，使得在KIP提出的服务器端分区分配器和客户端分区分配器中引入机架感知分区分配变得容易。由于KIP-848是对消费者实现的重大重写，现有的消费者实现可能会在相当长的一段时间内被广泛使用。由于支持机架感知分区分配的协议更改是一个很小的更改，因此在现有的消费者实现中支持这一功能也是很好的，这样它就可以更快地被采用。

2.2.KIP-903: 带有陈旧broker ephch的副本不应该被允许加入ISR

这个想法源于云环境中重启broker带来的问题。假设broker重新启动，一些日志尚未从页面缓存中flush到磁盘。发生这种情况时，此broker上的数据将丢失。一般来说，这是没问题的，因为controller将从所有ISR中删除此broker。然后，损失是有限的，broker可以稍后赶上。然而，如果在此期间，其中一个分区的leader也崩溃了，这样的代理可能会成为分区领导者，并使数据丢失成为现实。

以下是引用的此类场景的示例https://issues.apache.org/jira/browse/KAFKA-14139

加入我们一个分区有两个副本：A和B，一开始A是leader，而且B不在ISR中。

（1）Broker B追赶上Broker A的数据后，A尝试发送AlterPartition请求到Controller，请求将B加入到ISR。

（2）AlterPartition请求到来之前，B就遭遇了硬件故障而停机

（3）当前Controller就会将Broker B进行隔离，这个分区将不会被改变，因为B已经不在ISR中了。

（4）假如B完成启动，但是磁盘被替换，所有之前的状态都已丢失。

（5）新的Controller首先会注册Broker B

（6）最后，来自A的AlterPartition请求到达Controller，把B重新加入到ISR，即使此时B副本已经是一个空日志目录。

Controller和leader需要ISR的额外信息，以防止这种数据丢失场景。

这种潜在的数据丢失发生在ZK和KRaft模式的kafka集群中，因为我们正在推进Kraft模式，所以当前提议仅会修复kraft模式下的数据丢失。

2.3.KIP-875: offsets成为Kafka Connect的一等公民

从Kafka Connect Java API诞生之日起，它就支持offsets，用于跟踪source和sink connector的进度。所有的任务都可以在启动时使用offsets来定位开始读取的位置，以便从上一次消费的位置继续进行消费，而不是从头（数据重复）或者从最新（数据丢失）开始消费。

但是kafka connect还没有在集群管理视图中提供官方的接口来管理这些connector的offset。下面就是一些有用的场景

（1）开发环境快速迭代中进行connector offset的重置，这样就不需要每次重新命名connector。

（2）查看集群上source connector内存中的偏移量，以便从意外删除source connector topic的场景中恢复，现在可通过配置实现，这是一个重要的功能。

（3）监控每个正在运行connector的进度

（4）跳过哪些导致connector出问题且无法轻松定位并解决的记录

Kafka Connect多年来也不断发展，支持了一些使offsets管理变得复杂的用例，这里就不做赘述。

当前新增几个Kafka Connect REST API

KIP-399: Extend ProductionExceptionHandler to cover serialization exceptions

KIP-581: Value of optional null field which has default value

KIP-641 An new java interface to replace 'kafka.common.MessageReader'

KIP-710: Full support for distributed mode in dedicated MirrorMaker 2.0 clusters

KIP-847: Add ProducerIdCount metrics

KIP-884: Add config to configure KafkaClientSupplier in Kafka Streams

KIP-887: Add ConfigProvider to make use of environment variables

KIP-889: Versioned State Stores

KIP-893: The Kafka protocol should support nullable structs

KIP-894: Use incrementalAlterConfig for syncing topic configurations

KIP-900: KRaft kafka-storage.sh API additions to support SCRAM for Kafka Brokers

KIP-904: Kafka Streams - Guarantee subtractor is called before adder if key has not changed

KIP-907: Add Boolean Serde to public interface

KIP-911: Add source tag to Mirror source metric

KIP-914: DSL Processor Semantics for Versioned Stores

KIP-915: Txn and Group Coordinator Downgrade Foundation