Debezium 各种数据库的变更数据捕获

Debezium 是一个开源项目,为变更数据捕获 (CDC) 提供低延迟数据流平台。您设置和配置 Debezium 来监控您的数据库,然后您的应用程序使用对数据库进行的每个行级更改的事件。只有提交的更改是可见的,因此您的应用程序不必担心事务或回滚的更改。Debezium 提供了所有更改事件的单一模型,因此您的应用程序不必担心每种数据库管理系统的复杂性。此外,由于 Debezium 在持久的、复制的日志中记录数据更改的历史记录,因此您的应用程序可以随时停止和重新启动,并且它将能够消耗它在未运行时错过的所有事件,

监控数据库并在数据更改时收到通知一直很复杂。关系数据库触发器可能很有用,但特定于每个数据库,并且通常仅限于更新同一数据库内的状态(不与外部进程通信)。一些数据库提供 API 或框架来监控更改,但没有标准,因此每个数据库的方法都不同,并且需要大量知识渊博的专业代码。确保以相同的顺序查看和处理所有更改同时将对数据库的影响降至最低仍然是非常具有挑战性的。

Debezium 提供了为您完成这项工作的模块。一些模块是通用的,可以与多个数据库管理系统一起使用,但在功能和性能方面也有一些限制。其他模块是为特定的数据库管理系统量身定制的,因此它们通常功能更强大,并且它们利用了系统的特定功能。

基本架构

Debezium 是一个变更数据捕获 (CDC) 平台,通过重用 Kafka 和 Kafka Connect 来实现其持久性、可靠性和容错性。部署到 Kafka Connect 分布式、可扩展、容错服务的每个连接器都监视单个上游数据库服务器,捕获所有更改并将它们记录在一个或多个 Kafka 主题中(通常每个数据库表一个主题)。Kafka 确保所有这些数据更改事件都被复制并完全有序,并允许多个客户端独立消费这些相同的数据更改事件,而对上游系统的影响很小。此外,客户端可以随时停止消费,当他们重新启动时,他们会从上次中断的地方恢复。每个客户端都可以确定他们是否想要一次性或至少一次交付所有数据更改事件,

不需要或不需要这种级别的容错、性能、可扩展性和可靠性的应用程序可以改为使用 Debezium 的嵌入式连接器引擎在应用程序空间内直接运行连接器。他们仍然想要相同的数据更改事件,但更愿意让连接器将它们直接发送到应用程序,而不是在 Kafka 中持久化它们。

常见用例

在许多情况下,Debezium 可能非常有价值,但在这里我们只概述其中一些更常见的情况。

缓存失效

一旦条目的记录发生更改或被删除,缓存中的条目就会自动失效。如果缓存在单独的进程中运行(例如,Redis、Memcache、Infinispan 等),那么可以将简单的缓存失效逻辑放入单独的进程或服务中,从而简化主应用程序。在某些情况下,可以使逻辑更复杂一些,并且可以使用更改事件中的更新数据来更新受影响的缓存条目。

简化单片应用程序

许多应用程序更新数据库,然后在提交更改后执行其他工作:更新搜索索引、更新缓存、发送通知、运行业务逻辑等。这通常称为“双写”,因为应用程序正在写入多个系统在单笔交易之外。不仅应用程序逻辑复杂且更难以维护,如果应用程序在提交后但在执行部分/所有其他更新之前崩溃,双重写入也有丢失数据或使各种系统不一致的风险。使用变更数据捕获,当数据在原始数据库中提交时,这些其他活动可以在单独的线程或单独的进程/服务中执行。这种方法更能容忍失败,不会错过事件,更好地扩展,

共享数据库

当多个应用程序共享一个数据库时,一个应用程序知道另一个应用程序提交的更改通常很重要。一种方法是使用消息总线,尽管非事务性消息总线存在上述“双写”问题。然而,这在 Debezium 中变得非常简单:每个应用程序都可以监控数据库并对更改做出反应。

数据整合

数据通常存储在多个地方,特别是当它用于不同目的并且形式略有不同时。保持多个系统同步可能具有挑战性,但可以使用 Debezium 和简单的事件处理逻辑快速实现简单的 ETL 类型的解决方案。

CQRS

命令查询职责分离 (CQRS)架构模式使用一个数据模型进行更新,使用一个或多个其他数据模型进行读取。随着更新端记录更改,这些更改随后会被处理并用于更新各种读取表示。因此,CQRS 应用程序通常更复杂,尤其是当它们需要确保可靠和完全有序的处理时。Debezium 和 CDC 可以使这更容易实现:写入被记录为正常,但 Debezium 将这些更改捕获在持久的、完全有序的流中,这些流由异步更新只读视图的服务使用。写侧表可以表示面向领域的实体,或者当 CQRS 与事件溯源配对时写侧表是命令的仅附加事件日志。

分类: 默认 标签: 发布于: 2022-09-23 17:02:00, 点击数: