从数据库变更到大规模实时操作：Oracle GoldenGate与Java

数据库变更可以通过 Oracle GoldenGate 实时流式传输。随后，Java 应用程序可以消费这些变更，以验证事件、基于事件执行操作或将事件路由，而无需轮询数据库。

目标

实时监听数据库中的事务，对事务内的所有操作进行处理，并在近实时 SLA 下保持事务边界。

组件详情

1. 源数据库

这是源数据库，Java 服务从中实时监听事务变更。它可以是 GoldenGate 服务支持的任何数据库（例如 MySQL/Oracle）。

2. OCI 源端 GoldenGate 服务部署

• 输入：数据库重做日志
• 输出：TRAIL 文件

GoldenGate 服务有两个主要组件：Extract 和 Replicat。Extract 以重做日志和归档日志的形式读取源数据库中的变更。它会累积每个事务的 DML 操作，直到识别到 COMMIT 或 ROLLBACK。如果遇到 COMMIT，就将该事务存储到 TRAIL 文件中；如果遇到 ROLLBACK，则丢弃这些变更。此部署的输出是一个 TRAIL 文件，其中包含源数据库中发生的所有事务的有序列表。

3. OCI 目标端 GoldenGate 大数据部署

• 输入：由传统 GG 部署生成的 TRAIL 文件
• 输出：事务内操作的有序流

这是另一种可用于事务管理的部署类型。我们也可以改用 DATA STREAMS 功能，但它使用 AsyncAPI 发布/订阅接口；而大数据部署是用于向 Kafka 投递 CDC 数据的托管集成运行时。

4. 流式服务

• 输入：由传统 GG 部署生成的 TRAIL 文件
• 输出：事务内操作的有序流

理想情况下，Kafka 能够匹配 GoldenGate 的规模以及下游的可扩展性需求。Kafka 提供了在分区接收数据的同时添加分区的选项。此功能对于处理源数据库上的流量突发或批量 SQL 作业特别有用。

5. Java 服务的 Kubernetes 部署

• 输入：Kafka 消息，在此场景中为单个操作
• 输出：应用逻辑

一个 Java 应用程序实例，可根据 Kafka 分区积压情况进行横向扩展。

[LOADING...]

用例

1. Java 服务希望按事务发生的顺序监听预先定义的一组表的完整事务。
2. 它不希望监听所有源表的变更。
3. 它也不希望获取变更行的所有列，而只希望监听给定表列表中的特定列集合。

组件设置

详细的设置指南在此可作为通用指导，但我会重点介绍实现上述用例所需的具体更改。

1. 源数据库

这里我们希望监听源数据库的重做日志。要在源数据库上启用补充日志记录，请使用以下命令。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA

在我们的用例中，我们还要确保始终只获取 Java 服务感兴趣的表列，而不是所有列。要启用表级补充日志，请使用以下命令。

ALTER TABLE HR.EMPLOYEE ADD SUPPLEMENTAL LOG GROUP emp_group_loc (EMPLOYEE_ID, EMP_NAME, EMP_DEPARTMENT_ID);

2. OCI 源端 GG 部署

在此步骤中，OCI 源端 GG 部署被配置为监听源数据库的重做日志。根据我们的用例，重要步骤是在 Extract 的参数文件中仅配置所需的表。表列表基本上可确保只有发生在这些表上的事务会被 GG 识别，并收集到 TRAIL 文件中。你可以使用这篇文章来设置 Extract。

Extract 的参数文件示例：

table HR.EMPLOYEE;

除 Extract 外，还需要在同一源端部署中创建分发路径。该分发路径可确保目标大数据部署能够轻松访问 TRAIL 文件记录。创建分发路径的详细信息可在该文章的任务 3 中找到。

3. OCI 目标端 GoldenGate 大数据部署

在此部署中，会创建一个名为“replicat”的进程；replicat 从上述第 2 步创建的分发路径读取事务数据，然后发布这些事务。Replicat 使用两个配置文件工作。

参数文件

与 Extract 类似，Replicat 也有一个参数文件。该文件包含源数据库中的操作如何映射到目标模式和表的映射信息。由于我们不是在数据库中复制事务，因此会将参数文件中映射了目标表的 JSON 写入 Kafka 主题。

完整设置指南示例：请使用此指南。

MAP HR.EMPLOYEE, TARGET *.*;

属性文件

决定源事务如何写入目标的三个重要参数如下：

1. TopicMappingTemplate —— 告诉 replicat 目标位置，即源事务将写入何处。
2. opMode —— 源事务的写入方式：完整事务或一次一个操作。
3. keyMappingTemplate —— 此参数是 replicat Kafka 生产者使用的哈希键。

有关属性文件中可用的所有参数，请参阅此指南中的“11.2.10.1.3.2.2 Kafka 处理器配置”部分。

4. 流式服务和 Java 消费者服务

由于 GG 基于事务 ID 进行哈希，因此可以保证一个事务中的所有操作始终位于同一分区。Java 服务需要一个供所有 Pod 使用的消费者组。在启动时，所有 Pod 都会向 Kafka broker 注册其客户端 ID 并预留一个分区。此机制可确保单个 Pod 始终监听一个分区，直到因某个 Pod 宕机或其他原因发生再均衡。此设置可确保 Java 服务中的 Kafka 消费者能够轮询并收集事务，同时为同一服务内的下游应用逻辑保持操作边界和顺序。将 Java 服务中的轮询逻辑与处理逻辑分离，有助于避免各种超时场景。我们将在后续文章中深入探讨此机制。

总结

通过此设置，我们可以保证 Java 服务按顺序访问源数据库中的事务，并且一次只在一个事务内运行。此工作流适用于需要事件机制的各行业，例如欺诈检测和金融应用、电信和实时计费、零售和实时库存管理，以及 AI 和语义搜索流水线。

DZone 贡献者表达的观点仅代表其个人观点。