Debezium 核心概念

一、什么是 Debezium（本质）

Debezium 是一个 CDC（Change Data Capture）平台，通过读取数据库的日志（而不是查询表），把数据库的变更转化为有序、可恢复的事件流。

数据库日志 -> 结构化事件 -> 流系统

二、CDC（Change Data Capture）基础理论

1️⃣ CDC 的三种实现方式

方式	原理	问题
轮询表	定时查询	延迟高、压力大
Trigger	触发器写中间表	强侵入、难维护
Log-based（Debezium）	解析 binlog / WAL	✅ 实时、低侵入

Debezium 属于 Log-based CDC。

2️⃣ 为什么日志 CDC 是正确解

日志 天然有序
不影响业务 SQL
不会漏数据
可回放（offset）

三、Debezium 的整体架构

┌────────────┐
│ Database   │
│ binlog/WAL │
└─────┬──────┘
      ↓
┌────────────┐
│ Debezium   │  ← Kafka Connect Source
│ Connector  │
└─────┬──────┘
      ↓
┌────────────┐
│ Kafka      │  ← Topic（事件流）
└─────┬──────┘
      ↓
┌────────────┐
│ Consumers  │
└────────────┘

关键点：

Debezium 不是独立运行的
它运行在 Kafka Connect 之上

四、Kafka Connect 基础概念（必须懂）

1️⃣ Connector

一种插件
Debezium = Source Connector

2️⃣ Task

Connector 的执行单元
一个 Connector -> 多个 Task

⚠️ MySQL / PostgreSQL Debezium 实际通常只能 1 个 Task （因为 binlog / WAL 是顺序的）

3️⃣ Offset

记录读到数据库日志的哪个位置
存在 Kafka 的内部 Topic

connect-offsets

这是 Debezium 能恢复、不丢数据的核心

五、Snapshot（快照）机制

1️⃣ 为什么需要 Snapshot

CDC 只能捕获变化
启动时数据库里已有的数据怎么办？

👉 先全量 -> 再增量

2️⃣ Snapshot 的本质

在某个一致性点
扫描已有数据
每一行也会发成事件

{
  "op": "r"
}

r = read

3️⃣ Snapshot + Binlog/WAL 的一致性

Debezium 在 snapshot 前
先记录日志位置
snapshot 完后
从该位置继续消费日志

➡️ 不会丢、不重复（语义级）

六、事件模型（Event Model）

1️⃣ 统一事件结构

{
  "before": {...},
  "after": {...},
  "source": {...},
  "op": "c|u|d|r",
  "ts_ms": 1730000000000
}

2️⃣ before / after 的意义

操作	before	after
insert	null	新数据
update	旧数据	新数据
delete	旧数据	null

3️⃣ Tombstone 事件

delete 后
Debezium 可发送 tombstone
用于 Kafka compaction

key: {id: 1}
value: null

七、Exactly-once vs At-least-once

Debezium 的语义

At-least-once（至少一次）

可能：

因为重启
因为 rebalance

👉 下游必须具备幂等性

如何实现“逻辑上的 exactly-once”

使用主键作为 Kafka key
下游 upsert
或 Flink state

八、Schema & Schema Evolution

1️⃣ 表结构变化（DDL）

新增字段
修改字段类型
删除字段

Debezium：

捕获 DDL
更新事件 schema

2️⃣ Schema Registry（推荐）

Avro / Protobuf
避免 JSON 无 schema 漂移

九、数据库级关键概念

MySQL

基于 binlog
binlog_format = ROW
Server ID 唯一

PostgreSQL

基于 WAL logical decoding
必须：

wal_level = logical

使用 Replication Slot
表必须有 Primary Key

十、Replication Slot（PG 核心）

Slot 的作用

告诉 PG： “这个消费者还没读完，日志别删”

风险

Debezium 挂了
Slot 没消费
WAL 无限增长

👉 必须监控 slot

十一、顺序性与一致性

单表内顺序保证
事务内顺序保证
跨表顺序 ❌ 不保证

十二、Debezium 不解决什么

❌ 业务语义一致性
❌ 分布式事务
❌ exactly-once end-to-end
❌ 自动冲突解决

十三、典型设计原则

数据库是 事实源（Source of Truth）
Kafka 是事件总线
Debezium 是事实发布者
下游是事件消费者

十四、其它（FastAPI / PostgreSQL）

典型玩法：

PostgreSQL -> Debezium -> Kafka
FastAPI 消费 Kafka
用于：
- 权限变更实时同步
- 用户状态缓存刷新
- 搜索索引更新

十五、总结

Debezium 是基于数据库日志的 CDC 平台
Snapshot + Log 保证全量 + 增量一致
At-least-once，需要下游幂等
PG 使用 logical replication + slot