关于springboot:弃用Java-8Apache-Kafka发布30正式版

6次阅读

共计 6208 个字符，预计需要花费 16 分钟才能阅读完成。

昨天，Apache Kafka 3.0 版本正式公布，这是一个波及多方面的大版本。在这个版本中，Apache Kafka 3.0 引入了各种新性能、突破性的 API 更改以及对 KRaft 的改良：Apache Kafka 的内置共识机制将取代 Apache ZooKeeper™。

尽管 KRaft 尚未被举荐用于生产（已知差距列表），但咱们对 KRaft 元数据和 API 进行了许多改良。Exactly-once 和分区重新分配反对值得强调，咱们激励开发者查看 KRaft 的新性能并在开发环境中试用它。

并且，从 Apache Kafka 3.0 开始，生产者默认启用最强的交付保障 (acks=all, enable.idempotence=true)，这意味着用户当初默认取得排序和持久性。此外，不要错过 Kafka Connect 工作重启加强、KStreams 基于工夫戳同步的改良以及 MirrorMaker2 更灵便的配置选项。

KIP-750：弃用 Kafka 中对 Java 8 的反对

在 3.0 中，Apache Kafka 我的项目的所有组件都已弃用对 Java 8 的反对。这将使用户有工夫在下一个次要版本 (4.0) 之前进行调整，届时 Java 8 反对将被勾销。

KIP-751：弃用 Kafka 中对 Scala 2.12 的反对

对 Scala 2.12 的反对在 Apache Kafka 3.0 中也已弃用。与 Java 8 一样，咱们给用户工夫来适应，因为打算在下一个次要版本 (4.0) 中删除对 Scala 2.12 的反对。

KIP-630：Kafka Raft 快照

咱们在 3.0 中引入的一个次要性能是 KRaft 控制器和 KRaft 代理可能为名为 __cluster_metadata 的元数据主题分区生成、复制和加载快照。Kafka 集群应用此主题来存储和复制无关集群的元数据信息，如代理配置、主题分区调配、领导等。随着此状态的增长，Kafka Raft Snapshot 提供了一种无效的形式来存储、加载和复制此信息.

KIP-746：批改 KRaft 元数据记录

自第一版 Kafka Raft 控制器以来的教训和继续开发表明，须要批改一些元数据记录类型，当 Kafka 被配置为在没有 ZooKeeper (ZK) 的状况下运行时应用这些记录类型。

KIP-730：KRaft 模式下的生产者 ID 生成

在 3.0 和 KIP-730 中，Kafka 控制器当初齐全接管了生成 Kafka 生产者 ID 的责任。控制器在 ZK 和 KRaft 模式下都这样做。这让咱们更靠近桥接版本，这将容许用户从应用 ZK 的 Kafka 部署过渡到应用 KRaft 的新部署。

KIP-679：Producer 将默认启用最强的交付保障

从 3.0 开始，Kafka 生产者默认开启幂等性和所有正本的交付确认。这使得默认状况下记录交付保障更强。

KIP-735：减少默认消费者会话超时

Kafka Consumer 的配置属性的默认值 session.timeout.ms 从 10 秒减少到 45 秒。这将容许消费者在默认状况下更好地适应临时的网络故障，并在消费者仿佛只是临时来到组时防止间断从新均衡。

KIP-709：扩大 OffsetFetch 申请以承受多个组 ID

申请 Kafka 消费者组的以后偏移量曾经有一段时间了。然而获取多个消费者组的偏移量须要对每个组进行独自的申请。在 3.0 和 KIP-709 中，fetch 和 AdminClient API 被扩大为反对在单个申请 / 响应中同时读取多个消费者组的偏移量。

KIP-699：更新 FindCoordinator 以一次解析多个 Coordinator

反对能够以无效形式同时利用于多个消费者组的操作在很大水平上取决于客户端无效发现这些组的协调者的能力。这通过 KIP-699 成为可能，它减少了对通过一个申请发现多个组的协调器的反对。Kafka 客户端已更新为在与反对此申请的新 Kafka 代理交谈时应用此优化。

KIP-724：删除对音讯格局 v0 和 v1 的反对

自 2017 年 6 月随 Kafka 0.11.0 推出四年以来，音讯格局 v2 始终是默认音讯格局。因而，在桥下流过足够多的水（或溪流）后，3.0 的次要版本为咱们提供了弃用旧音讯格局（即 v0 和 v1）的好机会。这些格局明天很少应用。在 3.0 中，如果用户将代理配置为应用音讯格局 v0 或 v1，他们将收到正告。此选项将在 Kafka 4.0 中删除（无关详细信息和弃用 v0 和 v1 音讯格局的影响，请参阅 KIP-724）。

KIP-707：KafkaFuture 的将来
当 KafkaFuture 引入该类型以促成 Kafka AdminClient 的实现时，Java 8 之前的版本仍在宽泛应用，并且 Kafka 正式反对 Java 7。快进几年后，当初 Kafka 运行在反对 CompletionStage 和 CompletableFuture 类类型的 Java 版本上。应用 KIP-707，KafkaFuture 增加了一种返回 CompletionStage 对象的办法，并以 KafkaFuture 向后兼容的形式加强了可用性。
KIP-466：增加对 List 序列化和反序列化的反对

KIP-466 为泛型列表的序列化和反序列化增加了新的类和办法——这一个性对 Kafka 客户端和 Kafka Streams 都十分有用。

KIP-734：改良 AdminClient.listOffsets 以返回工夫戳和具备最大工夫戳的记录的偏移量

用户列出 Kafka 主题 / 分区偏移量的性能已失去扩大。应用 KIP-734，用户当初能够要求 AdminClient 返回主题 / 分区中具备最高工夫戳的记录的偏移量和工夫戳。（这是不是与什么的 AdminClient 收益曾经为最新的偏移，这是下一个记录的偏移，在主题 / 分区写入混同。）这个扩大现有 ListOffsets API 容许用户探测生动活泼的通过询问哪个是最近写入的记录的偏移量以及它的工夫戳是什么来分区。

KIP-745：连贯 API 以重新启动连接器和工作

在 Kafka Connect 中，连接器在运行时示意为一组 Connector 类实例和一个或多个 Task 类实例，并且通过 Connect REST API 可用的连接器上的大多数操作都能够利用于整个组。从一开始，一个值得注意的例外 restart 是 Connector 和 Task 实例的端点。要重新启动整个连接器，用户必须独自调用以重新启动连接器实例和工作实例。在 3.0 中，KIP-745 使用户可能通过一次调用重新启动所有或仅失败的连接器 Connector 和 Task 实例。此性能是附加性能，restartREST API 的先前行为放弃不变。

KIP-738：删除 Connect 的外部转换器属性

在之前的主版本 (Apache Kafka 2.0) 中弃用它们之后，internal.key.converter 并 internal.value.converter 在 Connect 工作器的配置中作为配置属性和前缀被删除。展望未来，外部 Connect 主题将专门应用 JsonConverter 来存储没有嵌入模式的记录。任何应用不同转换器的现有 Connect 集群都必须将其外部主题移植到新格局（无关降级门路的详细信息，请参阅 KIP-738）。

KIP-722：默认启用连接器客户端笼罩

从 Apache Kafka 2.3.0 开始，能够配置连接器工作器以容许连接器配置笼罩连接器应用的 Kafka 客户端属性。这是一个宽泛应用的性能，当初有机会公布一个次要版本，默认启用笼罩连接器客户端属性的性能（默认 connector.client.config.override.policy 设置为 All）。

KIP-721：在连贯 Log4j 配置中启用连接器日志上下文

另一个在 2.3.0 中引入但到目前为止尚未默认启用的性能是连接器日志上下文。这在 3.0 中产生了变动，连接器上下文默认增加 log4j 到 Connect 工作器的日志模式中。从以前的版本升级到 3.0 将 log4j 通过在适当的状况下增加连接器上下文来更改导出的日志行的格局。

KIP-695：进一步改良 Kafka Streams 工夫戳同步

KIP-695 加强了 Streams 工作如何抉择获取记录的语义，并扩大了配置属性的含意和可用值 max.task.idle.ms。此更改须要 Kafka 消费者 API 中的一种新办法，currentLag 如果本地已知且无需分割 Kafka Broker，则可能返回特定分区的消费者滞后。

KIP-715：在流中公开提交的偏移量

3.0 开始，三个新的办法增加到 TaskMetadata 接口：committedOffsets，endOffsets，和 timeCurrentIdlingStarted。这些办法能够容许 Streams 应用程序跟踪其工作的进度和运行状况。

KIP-740：清理公共 API TaskId

KIP-740 代表了 TaskId 该类的重大变革。有几种办法和所有外部字段已被弃用，新的 subtopology()和 partition()干将替换旧 topicGroupId 和 partition 字段（参见 KIP-744 的相干变动和修改 KIP-740）。

KIP-744：迁徙 TaskMetadata，并 ThreadMetadata 与外部实现的接口

KIP-744 将 KIP-740 提出的更改更进一步，并将实现与许多类的公共 API 离开。为了实现这一点，引入了新的接口 TaskMetadata、ThreadMetadata 和 StreamsMetadata，而弃用了具备雷同名称的现有类。

KIP-666：增加 Instant 基于办法到 ReadOnlySessionStore

交互式查问 API 扩大了 ReadOnlySessionStore 和 SessionStore 接口中的一组新办法，这些办法承受 Instant 数据类型的参数。此更改将影响须要实现新办法的任何自定义只读交互式查问会话存储实现。

KIP-622：增加 currentSystemTimeMs 和 currentStreamTimeMs 到 ProcessorContext

该 ProcessorContext 减少在 3.0 两个新的办法，currentSystemTimeMs 和 currentStreamTimeMs。新办法使用户可能别离查问缓存的零碎工夫和流工夫，并且能够在生产和测试代码中以对立的形式应用它们。

KIP-743：删除 0.10.0-2.4Streams 内置指标版本配置的配置值

3.0 中勾销了对 Streams 中内置指标的旧指标构造的反对。KIP-743 正在 0.10.0-2.4 从配置属性中删除该值 built.in.metrics.version。这 latest 是目前此属性的惟一有效值（自 2.5 以来始终是默认值）。

KIP-741：将默认 SerDe 更改为 null

删除了默认 SerDe 属性的先前默认值。流过去默认为 ByteArraySerde. 用 3.0 开始，没有缺省，和用户须要任一组其的 SerDes 依据须要在 API 中或通过设置默认 DEFAULT_KEY_SERDE_CLASS_CONFIG 和 DEFAULT_VALUE_SERDE_CLASS_CONFIG 在它们的流配置。先前的默认值简直总是不适用于理论应用程序，并且造成的凌乱多于不便。

KIP-733：更改 Kafka Streams 默认复制因子配置

有了次要版本的机会，Streams 配置属性的默认值 replication.factor 会从 1 更改为 -1。这将容许新的 Streams 应用程序应用在 Kafka 代理中定义的默认复制因子，因而在它们转移到生产时不须要设置此配置值。请留神，新的默认值须要 Kafka Brokers 2.5 或更高版本。

KIP-732：弃用 eos-alpha 并用 eos-v2 替换 eos-beta

在 3.0 中不举荐应用的另一个 Streams 配置值是 exactly_once 作为属性的值 processing.guarantee。该值 exactly_once 对应于 Exactly Once Semantics (EOS) 的原始实现，可用于连贯到 Kafka 集群版本 0.11.0 或更高版本的任何 Streams 应用程序。此 EOS 的第一实现曾经通过流第二施行 EOS 的，这是由值示意取代 exactly_once_beta 在 processing.guarantee 性质。展望未来，该名称 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 供消费者客户端应用的单个新属性。倡议 Kafka Streams 用户通过将其传递到 SerDe 构造函数来配置他们的窗口化 SerDe，而后在拓扑中应用它的任何中央提供 SerDe。

KIP-633：弃用 Streams 中宽限期的 24 小时默认值

在 Kafka Streams 中，容许窗口操作依据称为宽限期的配置属性解决窗口外的记录。以前，这个配置是可选的，很容易错过，导致默认为 24 小时。这是 Suppression 运营商用户常常感到困惑的起因，因为它会缓冲记录直到宽限期完结，因而会减少 24 小时的提早。在 3.0 中，Windows 类通过工厂办法失去加强，这些工厂办法要求它们应用自定义宽限期或基本没有宽限期来结构。已弃用默认宽限期为 24 小时的旧工厂办法，以及与 grace()已设置此配置的新工厂办法不兼容的相应 API。

KIP-623：internal-topics 为流应用程序重置工具增加“”选项

通过 kafka-streams-application-reset 增加新的命令行参数，应用程序重置工具的 Streams 应用变得更加灵便：–internal-topics. 新参数承受逗号分隔的主题名称列表，这些名称对应于能够应用此应用程序工具安顿删除的外部主题。将此新参数与现有参数相结合，–dry-run 容许用户在理论执行删除操作之前确认将删除哪些主题并在必要时指定它们的子集。

KIP-720：弃用 MirrorMaker v1

在 3.0 中，不举荐应用 MirrorMaker 的第一个版本。展望未来，新性能的开发和重大改良将集中在 MirrorMaker 2 (MM2) 上。

KIP-716：容许应用 MirrorMaker2 配置偏移同步主题的地位

在 3.0 中，用户当初能够配置 MirrorMaker2 创立和存储用于转换消费者组偏移量的外部主题的地位。这将容许 MirrorMaker2 的用户将源 Kafka 集群保护为严格只读的集群，并应用不同的 Kafka 集群来存储偏移记录（即指标 Kafka 集群，甚至是源和指标集群之外的第三个集群）。

原文链接：https://blogs.apache.org/kafka/entry/what-s-new-in-apache6

正文完