自我们发布 Debezium 3.1.0.Final 以来仅三周，很高兴地报告第一个维护版本已发布，即 3.1.1.Final。此版本包含一些关键的性能改进和各种错误修复。
在本篇文章中，我们将深入探讨 Debezium 多个关键模块的性能改进，讨论任何新功能，并解释任何可能影响您升级过程的变更。一如既往，我们建议您阅读发布说明，以了解所有已修复的 bug、更新流程等。
重大变更
任何新软件发布通常都会带来一些重大变更。本次发布也不例外，因此在升级到 Debezium 3.1.1.Final 之前，让我们先来讨论一下您应该了解的主要变更。
Debezium for Oracle
使用 JKS 安全 mTLS 连接
当使用 Debezium for Oracle 连接器通过 Java Keystores (JKS) 建立安全 mTLS 连接时，需要进行特殊配置。我们已将此信息添加到了Oracle 连接器文档中（DBZ-8788）。
新功能和改进
以下是 Debezium 3.1.1.Final 中所有值得注意的新功能和改进。如需完整列表，请务必阅读发布说明以获取更多详细信息。
Debezium Core
日志记录性能回归
在 Debezium 3.1 中，我们引入了一项变更，用于集中记录敏感信息。不幸的是，此变更导致了性能回归，导致多种代码路径的性能下降。
此变更已被撤销，并替换为一项新的实现，该实现保留了集中式日志记录的意图，同时恢复了之前的性能（DBZ-8879）。
通过 JMX 重置某些流指标
在空闲活动期间，Debezium 连接器将继续报告 LagBehindSource JMX 指标作为最后计算的值，因为该值仅在新更改收到时更新。对于某些环境而言，如果不了解空闲或低活动窗口，这会不太理想或不直观。
Debezium 3.1.1.Final 引入了一个新选项，可以通过 JConsole 或其他 JMX 集成触发，通过调用新的函数 resetLagBehindSource 来重置当前的 LagBehindSource 指标（DBZ-8885）。
改进了后处理配置验证期间的异常
当提供 post.processor 配置时，如果命名的后处理器存在配置不匹配或缺失的情况，Debezium 会抛出 NullPointerException。在这种情况下，Debezium 抛出自定义异常并提供更具描述性的失败原因总是更受推荐的。
Debezium 3.1.1.Final 现在对这些配置执行了更好的验证，现在将报告一个有效的错误，说明后处理配置无效或缺少必需的值（DBZ-8901）。
Debezium AI
提高了 FieldToEmbedding SMT 的韧性
在几个用例中，FieldToEmbedding 转换器的行为并未达到预期。例如，在处理删除记录时，转换器会因 NullPointerException 而失败（DBZ-8907），而在其他用例中，当源字段名是嵌入式名称的子字符串时，转换器会崩溃（DBZ-8910）。
这些问题已得到纠正，FieldToEmbedding 转换器现在应该更具韧性。
Debezium for Oracle
在特定场景下降低了 CPU 利用率
在 Debezium 3.1 中，我们根据DBZ-8665引入了一项变更，旨在恢复 Debezium 2.7.0.Final 处理约束冲突或回滚保存点操作时的性能。虽然此变更成功降低了 Debezium 3.0 至 3.0.7 处理此类事件引起的延迟，但我们发现即使是 Debezium 2.7 的性能也总体不尽如人意。
我们已实现对事务缓冲解决方案的全面重构，以更有效地处理约束冲突和回滚保存点（DBZ-8860）。
在使用基于堆的缓冲时，我们将处理此类事件所需的时间缩短了近 90%，同时将堆外缓冲的时间复杂度降低了 97-99%。除了降低时间复杂度外，我们在处理这些事件时还降低了整体 CPU 使用率，以符合预期。
提高了 online_catalog 挖掘策略的性能
在添加 hybrid 挖掘策略之前，Debezium Oracle LogMiner 实现包含一个特定条件，用于包含 LogMiner 无法解析表名的表的事件。这种情况发生在对象 ID 和重做条目中的版本与在线数据字典不匹配时，这在执行特定 DDL 操作后会发生。
包含这些更改，特别是当用户执行批量操作且 LogMiner 无法解析表名时，会增加延迟、连接器开销，仅用于连接器记录未知表。鉴于仅仅为了记录而导致的性能下降，我们选择在后续的数据获取中省略包含这些事件（DBZ-8926）。
提高了 hybrid 挖掘策略的性能
我们还发现了另一个性能瓶颈，这次是在使用 hybrid 挖掘策略处理批量事件时，LogMiner 在对象 ID/版本不匹配时无法解析表名。hybrid 策略旨在处理这种情况并回退到 Debezium 的关系模型来解析表名；然而，尽管使用了缓存，但对于批量操作的缓存查找的成本开销却非常高。
为了降低成本并提高未知表上批量操作的吞吐量性能，我们对查找进行了重构，从而显著提高了吞吐量，使得批量操作能够更高效地处理，并降低了整体 CPU 利用率（DBZ-8925）。
总结
非常感谢社区中所有辛勤工作的贡献者为这个版本付出的努力
Alvar Viana, Andrea Peruffo, Anisha Mohanty, Ashok, Bhagyashree Goyal, Oskar Bonde, Chris Cranford, Giovanni Panice, Haris Osmanagić, Jakub Cechacek, James Johnston, Jiri Pechanec, Katerina Galieva, Katsumi Miyajima, Krzysztof Grzechnik, Mario Fiore Vitale, Markus Kull, Minjae Lee, Nathan Smit, Rajendra Dangwal, Robert Roldan, Roman Kudryashov, Thomas Thornton, Vadzim Ramanenka, Victor Castaño, Vojtech Juranek, Vojtěch Juránek, Yuriy Vikulov, Zakariae Ben Allal, Zhongqiang Gong, kesompochy, حمود سمبول
关于 Debezium
Debezium 是一个开源的分布式平台，可以将现有数据库转变为事件流，使应用程序能够几乎即时地看到并响应数据库中已提交的每个行级更改。Debezium 构建在 Kafka 之上，并提供了 Kafka Connect 兼容的连接器，用于监控特定的数据库管理系统。Debezium 将数据更改的历史记录在 Kafka 日志中，这样您的应用程序可以随时停止和重新启动，并可以轻松地消费在未运行时错过的所有事件，确保所有事件都被正确且完整地处理。Debezium 在 Apache 许可证 2.0 下是 开源 的。
