多数据库CDC“通才”——Debezium

在之前的CDC系列文章中，我们认识了擅长实时捕获MySQL变更的“专才”Canal，也聊过擅长“搬一次家”的离线同步工具DataX。如果说Canal是专注于MySQL生态的“专才”，那么今天要介绍的这位主角，就是一位支持多种数据库的“通才”——Debezium。

一、什么是Debezium？

Debezium（发音为 /dɛˈbiːziəm/）是一个开源的分布式变更数据捕获（CDC）平台。它由Red Hat于2016年发起并持续主导社区发展，旨在将现有的数据库转变为事件流，让应用程序能够几乎实时地感知并响应数据库中每一行数据的变更。

简单来说，Debezium就像一个7×24小时不间断工作的“数据监控摄像头” ，时刻盯着数据库的一举一动——一旦有数据被插入、更新或删除，它立刻捕获这些变化，并将它们转化为结构化的事件流，推送给需要这些数据的下游系统。

与Canal主要聚焦于MySQL不同，Debezium的设计目标从一开始就是多数据库支持。无论是MySQL、PostgreSQL、Oracle、SQL Server等关系型数据库，还是MongoDB、Cassandra等NoSQL数据库，Debezium都能通过对应的连接器实现精准的变更捕获。

二、核心原理：读取事务日志，捕获行级变更

Debezium的核心工作原理与Canal类似，都是基于数据库的事务日志来实现变更捕获：

1. 读取事务日志：Debezium的连接器会连接到目标数据库，读取其事务日志。对于MySQL来说是binlog，对于PostgreSQL来说是WAL（Write-Ahead Log），对于MongoDB来说是oplog。
2. 解析变更事件：连接器将日志中的二进制数据解析为结构化的变更事件，每个事件都包含操作类型（INSERT/UPDATE/DELETE）、变更前后的数据（before/after）、以及事件来源的元数据（数据库名、表名、日志位置、时间戳等）。
3. 输出事件流：解析后的变更事件被发送到Kafka等消息中间件中，供下游系统消费。

Debezium只捕获已提交的事务，避免了中间状态或回滚数据带来的数据一致性问题。同时，由于它是通过读取日志而非直接查询数据库来获取变更，对源数据库的性能影响极小。

三、架构：基于Kafka Connect的插件化设计

Debezium最显著的特点之一，是它并非一个独立运行的服务，而是作为Kafka Connect的Source Connector插件运行。

Kafka Connect是Apache Kafka提供的一个用于在Kafka与外部系统之间进行可扩展、可靠数据流传输的框架。Debezium提供了一系列与Kafka Connect兼容的连接器，这些连接器就像是智能的“数据探测器”，能够深入到不同类型的数据库中精准捕获数据变更。

这种架构带来的好处是：

• 高可用与分布式：Kafka Connect支持分布式部署，可以水平扩展
• 持久化与可重放：所有变更事件都被持久化在Kafka中，即使下游系统暂时离线，恢复后也能从断点继续消费
• 顺序保证：Kafka能够保证单个分区内消息的顺序性

除了基于Kafka Connect的标准部署方式外，Debezium还提供了两种替代方案：

• Debezium Server：一个可配置的、即用型应用程序，可以将变更事件从源数据库直接流式传输到各种消息中间件（如Kinesis、Pub/Sub、Pulsar等），无需依赖Kafka Connect
• Debezium Engine：将Debezium作为库嵌入到自定义的Java应用程序中，在应用内部直接消费变更事件

四、支持哪些数据库？

Debezium的“兼容性”堪称CDC领域的“海王”级：

关系型数据库：

• MySQL / MariaDB
• PostgreSQL
• Oracle
• SQL Server
• CockroachDB

NoSQL数据库：

• MongoDB
• Cassandra

持续扩展中：

• DB2、Vitess等也在逐步支持

无论你的技术栈使用的是哪种主流数据库，Debezium基本都能覆盖。

五、主要应用场景

Debezium的应用场景非常广泛，以下是几个典型的例子：

1. 实时数据同步
将MySQL中的订单数据实时同步到Elasticsearch，实现搜索服务的秒级更新。有电商公司用Debezium+Kafka替代了原先Sqoop每天全量同步的方式，节省了90%的ETL开发时间。

2. 微服务架构解耦
在微服务架构中，服务A的数据库发生变更后，Debezium将其发布为Kafka事件，服务B消费该事件后更新自己的缓存或数据库。从此服务间不再需要直接的API调用，架构更加清爽。

3. 缓存失效与更新
数据库中的数据发生变化时，自动触发Redis等缓存的更新，保证缓存与数据库的一致性。

4. CQRS（命令查询职责分离）
Debezium捕获写模型的数据更改，持久化到事件流中，用于异步更新读模型的视图。

5. 实时数据集成与分析
将数据库变更实时同步到数据湖或分析系统，支持实时看板和实时决策。

六、Debezium vs. Canal：有何不同？

结合上一篇文章介绍的Canal，两者最核心的区别在于数据库支持的广度：

简单来说：Canal是专注于MySQL的“专才”，而Debezium是支持多数据库的“通才”。如果你的技术栈只用MySQL，Canal是一个轻量高效的选择；如果你的系统涉及多种数据库，或者你正在构建微服务架构需要统一的CDC方案，Debezium会是更合适的选择。

七、快速入门：配置MySQL连接器

以下是一个最简的MySQL连接器配置示例，通过Kafka Connect REST API提交：

{
  "name": "mysql-connector",
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
    "database.hostname": "localhost",
    "database.port": "3306",
    "database.user": "root",
    "database.password": "secret",
    "database.server.id": "184054",
    "database.server.name": "dbserver1",
    "table.include.list": "inventory.*",
    "database.history.kafka.topic": "dbhistory.inventory"
  }
}

提交后，Debezium就会开始监听inventory库的所有表变更，并将变更事件推送到Kafka Topic中。

关于快照模式，Debezium支持多种快照策略：

• 初始快照（Initial Snapshot） ：首次启动时全量抓取数据，适合冷启动
• 增量快照（Incremental Snapshot） ：边读历史边追增量，支持断点续传
• 按需触发：通过向信号表插入指令，可随时对指定表发起快照

八、总结

Debezium作为CDC领域的“通才”，以其多数据库支持、基于Kafka Connect的成熟架构、强大的社区生态，成为企业级实时数据同步方案的首选之一。它让数据库的每一次变更都能被实时捕获、可靠传输、有序消费，为微服务解耦、缓存更新、实时分析等场景提供了坚实的数据基座。

如果说Canal是MySQL实时同步的“专才” ，那么Debezium就是多数据库CDC的“通才” ——两者各有所长，选择哪一个，取决于你的数据库技术栈和架构需求。

希望这篇文章能帮助你全面了解Debezium。如果你正在构建多数据库环境下的实时数据管道，不妨从Debezium开始，让数据真正“流动”起来。