昨天，ApacheKafka3.0版本正式发布，这是一个涉及很多方面的大版本。在此版本中，ApacheKafka3.0引入了各种新功能、重大API更改以及对KRaft的改进：ApacheKafka的内置共识机制将取代ApacheZooKeeper?。虽然KRaft尚未被推荐用于生产（已知差距列表），但我们对KRaft元数据和API进行了许多改进。Exactly-once和分区重新分配支持值得强调，我们鼓励开发人员检查KRaft的新功能并在开发环境中试用。而且，从ApacheKafka3.0开始，生产者默认启用最强的交付保证（acks=all，enable.idempotence=true），这意味着用户现在默认获得顺序和持久性。此外，不要错过KafkaConnect作业重启增强功能、KStreams对基于时间戳的同步的改进以及MirrorMaker2更灵活的配置选项。GeneralChangeKIP-750:DeprecationofJava8supportinKafka在3.0中，ApacheKafka项目的所有组件都弃用了对Java8的支持。这将使用户有时间进行调整，直到下一个主要版本（4.0）支持Java8将被丢弃。KIP-751：弃用Kafka中的Scala2.12支持ApacheKafka3.0中也弃用了对Scala2.12的支持。与Java8一样，我们给用户时间来适应，因为计划在下一个主要版本(4.0)中删除对Scala2.12的支持。KafkaBrokers、Producer、Consumers和ManagementClientsKIP-630:KafkaRaftSnapshots我们在3.0中引入的一个主要特性是KRaft控制器和KRaftbroker能够生成、复制和加载快照。Kafka集群使用该主题来存储和复制有关集群的元数据信息，例如代理配置、主题分区分配、领导者等。随着这种状态的增长，KafkaRaftSnapshot提供了一种有效的方式来存储、加载和复制这种信息。KIP-746：修改KRaft元数据记录自第一个版本的KafkaRaft控制器以来的经验和持续开发表明，当Kafka配置为在没有ZooKeeper(ZK)的情况下运行时，需要修改一些元数据记录类型以供使用。KIP-730：KRaft模式下的ProducerID生成在3.0和KIP-730中，KafkaController现在完全接管了生成KafkaProducerID的责任。控制器在ZK和KRaft模式下都这样做。这使我们更接近桥接版本，允许用户从使用ZK的Kafka部署过渡到使用KRaft的新部署。KIP-679：生产者将默认启用最强的交付保证。从3.0开始，Kafka生产者默认为所有副本启用幂等性和交付确认。这使得默认情况下记录交付保证更强。KIP-735：增加默认消费者会话超时Kafka消费者配置属性的默认session.timeout.ms值已从10秒增加到45秒。这将使消费者在默认情况下对临时网络故障更有弹性，并避免在消费者似乎只是暂时离开组时进行持续的重新平衡。KIP-709：自从扩展OffsetFetch请求以接受多个组ID以请求Kafka消费者组的当前偏移量以来已经有一段时间了。但是为多个消费者组获取偏移量需要为每个组单独请求。在3.0和KIP-709中，fetch和AdminClientAPI被扩展以支持在单个请求/响应中同时读取来自多个消费者组的偏移量。KIP-699：更新FindCoordinator以一次解析多个Coordinator以支持可以以高效方式同时应用于多个消费者组的操作，这在很大程度上取决于客户端有效发现这些组的协调器的能力。这是通过KIP-699实现的，它增加了对通过单个请求发现多个组的协调器的支持。Kafka客户端已更新为在与支持此请求的新Kafka代理对话时使用此优化。KIP-724：删除对消息格式v0和v1的支持。自2017年6月随Kafka0.11.0引入以来，消息格式v2已成为四年的默认消息格式。因此，有了足够的水（或溪流）在桥下流淌，3.0主要版本为我们提供了一个很好的机会来弃用旧的消息格式（即v0和v1）。这些格式今天很少使用。在3.0中，如果用户将代理配置为使用消息格式v0或v1，则会收到警告。此选项将在Kafka4.0中删除（有关弃用v0和v1消息格式的详细信息和影响，请参阅KIP-724）。KIP-707：KafkaFuture的未来虽然KafkaFuture引入了类型以方便KafkaAdminClient的实现，但Java8之前的版本仍然被广泛使用，Kafka正式支持Java7。快进几年，现在Kafka运行在一个版本上支持CompletionStage和CompletableFuture类类型的Java。使用KIP-707，KafkaFuture添加了一个返回CompletionStage对象的方法，并以KafkaFuture向后兼容的方式增强了可用性。KIP-466：添加对列表序列化和反序列化的支持KIP-466为通用列表的序列化和反序列化添加了新的类和方法——该功能对Kafka客户端和它工作的KafkaStreams都非常有用。KIP-734：改进AdminClient.listOffsets以返回时间戳和具有最大时间戳的记录的偏移量。用户列出Kafka主题/分区的偏移量的能力已得到扩展。使用KIP-734，用户现在可以要求AdminClient返回主题/分区中具有最高时间戳的记录的偏移量和时间戳。（这不要与AdminClient返回的最新偏移量混淆，这是要写入主题/分区的下一条记录的偏移量。）这扩展了现有的ListOffsetsAPI以允许用户检测哪个通过询问哪个是最近写入的记录的偏移量及其到分区的时间戳来激活偏移量。kafkaConnectKIP-745：连接API以重启连接器和任务在KafkaConnect中，连接器在运行时表示为一组连接器类实例和一个或多个任务类实例，并且可通过连接器RESTAPI在连接器上使用大多数操作可以应用于整个组。从一开始，一个值得注意的重启例外是Connector和Task实例的端点。要重启整个连接器，用户必须分别调用重启连接器实例和任务实例。在3.0中，KIP-745使用户能够通过一次调用重新启动所有或仅失败的连接器和任务实例。此功能是附加功能，restartRESTAPI的先前行为保持不变。KIP-738：在之前的主要版本（ApacheKafka2.0）中弃用Connect的内部转换器属性后，删除它们，internal.key.converter和internal.value.converter作为Connectworker配置中的配置属性和前缀被删除。展望未来，内部连接主题将专门使用JsonConverter来存储没有嵌入式模式的记录。任何使用不同转换器的现有Connect集群必须将其内部主题移植到新格式（有关升级路径的详细信息，请参阅KIP-738）。KIP-722：默认启用连接器客户端覆盖从ApacheKafka2.3.0开始，可以配置连接器工作程序以允许连接器配置覆盖连接器使用的Kafka客户端属性。这是一个广泛使用的功能，现在有机会发布一个主要版本，能够覆盖默认启用的连接器客户端属性（connector.client.config.override.policy默认设置为All）。KIP-721：在ConnectionLog4j配置中启用连接器日志记录上下文2.3.0中引入但目前尚未默认启用的另一个功能是连接器日志记录上下文。这在3.0中发生了变化，连接器上下文默认将log4j添加到Connectworker的日志记录模式中。从以前的版本升级到3.0将通过在适当的地方添加连接器上下文来更改log4j导出的日志行的格式。KafkaStreamsKIP-695：KafkaStreams时间戳同步的进一步改进KIP-695增强了Streams任务如何选择获取记录的语义，并扩展了配置属性max.task.idle.ms的含义和可用值。此更改需要Kafka消费者API中的新方法currentLag，如果本地已知并且无需联系Kafka代理，则能够返回特定分区的消费者延迟。KIP-715：公开流中提交的偏移量从3.0开始，TaskMetadata接口中添加了三个新方法：committedOffsets、endOffsets和timeCurrentIdlingStarted。这些方法允许Streams应用程序跟踪其任务的进度和健康状况。KIP-740：清理公共APITaskIdKIP-740代表了对TaskId类的重大改革。一些方法和所有内部字段已被弃用，新的??subtopology()和partition()getter将替换旧的topicGroupId和分区字段（有关KIP-740的相关更改和修复，请参阅KIP-744）。KIP-744：迁移TaskMetadata，并使用内部实现接口ThreadMetadataKIP-744将KIP-740提出的更改更进一步，并将实现与许多类的公共API分开。为此，引入了新接口TaskMetadata、ThreadMetadata和StreamsMetadata，同时弃用了具有相同名称的现有类。KIP-666：向ReadOnlySessionStore交互式查询API添加基于Instant的方法，使用一组接受Instant数据类型参数的新方法扩展ReadOnlySessionStore和SessionStore接口。此更改将影响任何需要实现新方法的自定义只读交互式查询会话存储实现。KIP-622:ProcessorContext添加currentSystemTimeMs和currentStreamTimeMsProcessorContext在3.0中新增了两个方法currentSystemTimeMs和currentStreamTimeMs。新方法使用户能够分别查询缓存的系统时间和流时间，并在生产和测试代码中以统一的方式使用它们。KIP-743:Removeconfigvaluesfor0.10.0-2.4Streamsbuilt-inmetricsversionconfig在3.0中删除了对Streams中内置指标的旧指标结构的支持。KIP-743正在从0.10.0-2.4的配置属性中删除值built.in.metrics.version。这个最新的值是当前这个属性的唯一有效值（并且自2.5以来一直是默认值）。KIP-741：将默认SerDe更改为null会删除默认SerDe属性的先前默认值。Streams过去默认为ByteArraySerde。从3.0开始，没有默认值，用户需要根据需要在API中设置其他SerDes，或者在其流配置中设置默认的DEFAULT_KEY_SERDE_CLASS_CONFIG和DEFAULT_VALUE_SERDE_CLASS_CONFIG。以前的默认值几乎总是不适合实际应用程序，并且造成的混乱多于便利性。KIP-733：更改KafkaStreams默认复制因子配置随着主要版本的发布，Streams配置属性replication.factor的默认值将从1更改为-1。这将允许新的Streams应用程序使用Kafka代理中定义的默认复制因子，因此在它们移至生产环境时无需设置此配置值。请注意，新的默认设置需要KafkaBrokers2.5或更高版本。KIP-732：弃用eos-alpha并用eos-v2替换eos-beta3.0中弃用的另一个Streams配置值是exactly_once作为属性processing.guarantee的值。值exactly_once对应于ExactlyOnceSemantics(EOS)的原始实现，并且可以与连接到Kafka集群版本0.11.0或更高版本的任何Streams应用程序一起使用。EOS的第一个实现通过流式传输EOS的第二个实现替换了processing.guarante中的exactly_once_beta属性，它由值表示。展望未来，名称exactly_once_beta也已弃用并替换为新名称exactly_once_v2。在下一个主要版本（4.0）中，exactly_once和exactly_once_beta都将被删除，exactly_once_v2将成为EOS交付保证的唯一选项。KIP-725：优化WindowedSerializer和WindowedDeserializer配置属性default.windowed.key.serde.inner和default.windowed.value.serde.inner的配置已弃用，取而代之的是消费者客户端的windowed.inner.class.serde单个新属性使用。建议KafkaStreams用户通过将其传递给SerDe构造函数来配置其窗口化SerDe，然后在使用它的拓扑中的任何位置提供SerDe。KIP-633：弃用KafkaStreams中Streams中24小时默认的宽限期，允许窗口操作根据称为宽限期的配置属性在窗口外处理记录。以前，此配置是可选的且容易错过，导致默认为24??小时。这是Suppression运算符的用户经常感到困惑的根源，因为它会缓冲记录直到宽限期结束，从而增加了24小时的延迟。在3.0中，Windows类通过工厂方法得到增强，这些方法要求它们在构建时具有自定义宽限期或根本没有宽限期。默认宽限期为24小时的旧工厂方法已被弃用，相应的API与设置此配置的新工厂方法grace()不兼容。KIP-623:internal-topicsadd""optiontostreamapplicationresettool通过向kafka-streams-application-reset添加新的命令行参数，Streams应用程序重置工具的使用变得更加灵活：--internal-topics.新参数接受一个以逗号分隔的主题名称列表，这些名称对应于可以使用此应用程序工具安排删除的内部主题。将这个新参数与现有参数相结合，--dry-run允许用户在实际执行删除操作之前确认将删除哪些主题并在必要时指定其中的一个子集。MirrorMakerKIP-720：弃用MirrorMakerv1在3.0中，第一个版本的MirrorMaker已弃用。展望未来，新功能开发和重大改进将集中在MirrorMaker2(MM2)上。KIP-716：允许使用MirrorMaker2配置偏移量同步主题位置在3.0中，用户现在可以配置MirrorMaker2创建和存储用于转换消费者组偏移量的内部主题的位置。这将允许MirrorMaker2的用户将源Kafka集群维护为严格只读的集群，并使用不同的Kafka集群来存储偏移量记录（即目标Kafka集群，甚至是源和目标集群之外的第三个集群）。
