架构解析：Debezium 的组件与 Kafka Connect 的角色

这一章我们来拆解 Debezium 的骨架。说实话，很多初学者一上来就写配置、跑任务，结果出了问题根本不知道从哪查起。我个人习惯是，先搞清楚每个组件是干什么的，它们之间怎么配合，这样出了问题你才能快速定位。

Debezium 并不是一个孤立的工具。它跑在 Kafka Connect 之上，本质上是 Kafka Connect 的一组 Source Connector。所以理解 Debezium，必须先理解 Kafka Connect 的角色，再深入 Debezium 自己的三大核心组件：Connector、Snapshot、Streaming。

Kafka Connect：Debezium 的运行底座

Kafka Connect 是什么？说白了，它是一个数据搬运框架。专门用来把数据从源系统搬到 Kafka，或者从 Kafka 搬到目标系统。Debezium 就是利用了这个框架，把自己包装成一个个 Source Connector，去捕获数据库的变更。

Kafka Connect 有两种运行模式：

• Standalone 模式：单进程运行，适合开发测试。配置简单，但没高可用。
• Distributed 模式：多进程组成集群，自动做任务分配和故障转移。生产环境必须用这个。

我在项目中遇到过有人把 Standalone 模式直接丢到生产，结果进程挂了整个数据管道全停。嗯，这坑我踩过，后来就再也不敢了。

Kafka Connect 里有两个核心概念：

概念	作用	类比
Connector	定义如何连接外部系统，是配置层面的抽象	像一份作业指导书
Task	实际干活的工作线程，负责拉取或写入数据	像执行作业的工人

一个 Connector 可以拆成多个 Task 并行工作。比如你监控 8 张表，可以配置 4 个 Task，每个 Task 负责 2 张表。这就是 Kafka Connect 的并行能力。

Debezium 三大组件

Debezium 的每个 Connector 内部，又分为三个逻辑组件：Connector、Snapshot、Streaming。它们协同完成一次完整的数据库变更捕获。

1. Connector 组件

Connector 是入口。它负责解析配置、校验参数、决定要监控哪些表、以及分配 Task。

当你提交一个 Debezium 配置时，Connector 会做这几件事：

1. 解析数据库连接信息、表白名单/黑名单、快照模式等配置。
2. 调用数据库的元数据 API，获取表结构信息（字段名、类型、主键）。
3. 根据表数量，决定创建多少个 Task。
4. 把表结构信息和 Offset 信息传给 Task。

我记得有一次，用户配置了 2000 张表的白名单，结果 Connector 启动时光获取元数据就花了 10 分钟。后来我建议他按业务模块拆成多个 Connector，问题就解决了。你想想看，一个 Connector 管太多表，元数据加载就是瓶颈。

2. Snapshot 组件

Snapshot 是初始快照阶段。当一个 Connector 第一次启动时，它需要把数据库的当前全量数据读出来，写入 Kafka。这就是 Snapshot 干的事。

Snapshot 有两种模式：

模式	行为	适用场景
initial	先做全量快照，再切到增量流	首次部署，需要完整数据
schema_only	只捕获表结构，不做全量数据	已有历史数据，只关心增量
when_needed	只在需要时触发快照	特定场景手动控制
never	跳过快照，直接进入流式	已有 Offset，恢复运行

这里有个坑。默认的 initial 模式在做快照时，会加锁吗？取决于数据库和配置。MySQL 用 snapshot.locking.mode 控制，默认是 minimal，只对读取的表加短暂读锁。但如果你用的是 extended，可能会阻塞写入。我曾经在生产环境遇到过因为快照锁导致业务写入延迟飙升的情况，后来改成了 schema_only 配合外部数据同步才解决。

3. Streaming 组件

Streaming 是核心。Snapshot 做完后，Streaming 就开始实时监听数据库的变更日志。

对于 MySQL，它监听 Binlog；对于 PostgreSQL，它监听 WAL；对于 MongoDB，它监听 Oplog。Streaming 组件会持续读取这些日志，解析成 Debezium 的统一变更事件格式，然后写入 Kafka。

Streaming 的工作流程：

1. 从上次记录的 Offset 位置开始读取日志。
2. 解析每条变更记录，提取 before/after 数据。
3. 根据表结构，把数据转换成 Avro/JSON/Protobuf 格式。
4. 写入对应的 Kafka Topic。
5. 定期提交 Offset，记录当前读取位置。

Streaming 最怕什么？日志堆积。如果 Kafka 写入变慢，或者数据库瞬间产生大量变更，Streaming 可能跟不上。我遇到过 MySQL 大事务提交后，Binlog 一下子吐出几百万条变更，Streaming 处理不过来，延迟从毫秒级飙升到分钟级。后来我加了 max.batch.size 和 poll.interval.ms 的调优，才稳住。

三者协作流程

为了让你更直观地理解，我画了一张架构图。Connector、Snapshot、Streaming 是怎么配合的，一目了然。

从图上你能看到，整个流程是串行的。Connector 先启动，然后触发 Snapshot，Snapshot 完成后自动切换到 Streaming。Streaming 会一直运行，直到你手动停止 Connector 或发生故障。

Offset 管理：让组件记住位置

这里有个关键机制——Offset。Debezium 用 Offset 来记录当前处理到的日志位置。比如 MySQL 的 Binlog 文件名和位置号，PostgreSQL 的 LSN。

Offset 由 Kafka Connect 统一管理，存储在 Kafka 的 __consumer_offsets 主题里，或者你配置的 Offset 存储后端。这样即使 Connector 重启，Streaming 也能从上次中断的地方继续，不会重复也不会丢失。

我曾经遇到一个场景：数据库做了主从切换，Binlog 文件名变了，但 Offset 还记录着旧文件名。结果 Debezium 启动后找不到那个 Binlog 文件，直接报错。后来我配置了 database.history.store.only.monitored.tables.ddl 和合理的 Offset 保留策略，才避免这类问题。

组件配置示例

最后给一个 MySQL Connector 的配置示例，你可以看到这三个组件是如何通过配置体现的：

{
  "name": "mysql-connector",
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
    "database.hostname": "192.168.1.100",
    "database.port": "3306",
    "database.user": "debezium",
    "database.password": "debezium",
    "database.server.id": "184054",
    "database.server.name": "myapp",
    "database.include.list": "mydb",
    "table.include.list": "mydb.orders,mydb.users",
    "snapshot.mode": "initial",
    "snapshot.locking.mode": "minimal",
    "offset.storage": "org.apache.kafka.connect.storage.KafkaOffsetBackingStore",
    "offset.flush.interval.ms": "60000",
    "max.batch.size": "2048",
    "poll.interval.ms": "500"
  }
}

你看，snapshot.mode 控制 Snapshot 组件的行为，max.batch.size 和 poll.interval.ms 影响 Streaming 组件的性能，而 connector.class 决定了用哪个 Connector 实现。理解了这三个组件，这个配置就不再是一堆参数，而是一张清晰的架构蓝图。