3 分钟看懂 Debezium：数据库变更捕获怎么做到毫秒级、不动业务库

【免费下载链接】debeziumChange data capture for a variety of databases. Please log issues at https://github.com/debezium/dbz/issues.项目地址: https://gitcode.com/gh_mirrors/de/debezium

订单表刚 commit 完新价格，搜索索引却还在吐旧价格，数据同步难道只能靠不停写轮询脚本？Debezium 干的事说到底是 CDC 变更捕获：它贴在数据库边上，把行级已提交的变更记成事件流，毫秒级推给 Kafka 等下游，数据同步从此不再依赖周期性轮询。

它把什么难题变得简单

先看过去怎么做。最常见的套路是定时轮询：cron 每 5 分钟查一遍updated_at，或者写个脚本全量比对两张表找差异。问题很直观——轮询间隔决定延迟，全量比对压垮业务表，脚本跑到一半挂了，差异就悬在半空没人兜底。Debezium 的路子正好反过来：它不“问”数据库改了什么，而是听数据库自己“吐”什么。MySQL 读 binlog，PostgreSQL 读逻辑复制流，每提交一行就变成一条结构化事件。这就是数据库变更实时同步方案的主流形态——变更按序推给下游，应用不用再去猜。

三条机制线，拆开看

整体链路一句话：source connector 在数据库侧监听，事件落进 Kafka，下游按需取。

基于 CDC 的零侵入变更捕获

这里的关键是：它读的是数据库自身的变更日志——MySQL 的 binlog、PostgreSQL 的 WAL、MongoDB 的 oplog，不加触发器，业务代码不用写任何额外逻辑。只有已提交的变更会被捕获，回滚的事务自动过滤掉。换句话说，给业务库挂数据同步，成本接近于零。

Kafka 管道如何兜住消息不丢

Debezium 接入 Kafka 的标准姿势，是以 Kafka Connect source connector 的身份部署。每条事件先持久化到带副本的 topic，再投递给消费者；消费者中途停掉再重启，会从上次处理的 offset 续读。换句话说，下游宕机半天，恢复后照样逐条补齐，一条不丢。

集群挂了，捕获会停吗

connector 的处理进度随消息一起保存在持久化日志里，节点故障后从最后位置恢复即可。对使用者意味着什么：数据同步链路不依赖某个单进程活着，故障恢复后事件不缺段。

四个真实落地方向 🚀

搜索索引：运维同学把订单表指向 Debezium，变更事件直进 Elasticsearch 集群。commit 完成时文档价格就被刷新，旧价格不再拖到下一次定时重建。用户侧的可见窗口从“分钟级”缩到“秒级”。

微服务事件通知：Order Service 写 ERP 数据库，Inventory Service 订阅 Debezium 所在的 Kafka topic。收到订单创建事件就触发补货动作，两个服务之间不再互相发 HTTP 调用。“写库成功、通知失败”的双写坑就此消失。

缓存失效：缓存服务抢在所有人前面动手——Product 表一更新，变更事件就到，直接删掉或覆盖对应 Redis key。手工清缓存、等 TTL 过期造成的脏读不再发生，主应用代码保持原样。

实时数仓：数据同学把 Debezium 事件接进 Kafka Streams 做实时聚合，再写回数仓。业务大盘看到本小时交易的变化，不用等 T+1 批跑。财务对账的延迟从一天缩到一个小时。

选型前值得确认的 4 件事 ❓

目标库在支持名单里吗？CDC 有前提：数据库得提供变更日志，Debezium 才有东西可听。若目标库是老版本或特殊发行版，先翻 connector 文档 确认。作为 CDC 数据捕获工具，它的 connector 矩阵已覆盖 MySQL / PostgreSQL / MongoDB / Oracle / SQL Server 等主流系统。

低延迟的边界到底在哪里？捕获本身是毫秒级，但端到端延迟还取决于 Kafka 集群配置和下游消费速度。批量大小、分区数决定延迟上限，选型前务必拿自己的业务流量压一遍。

数据库给不给 Debezium 一个专用账号？MySQL 需要复制权限账号，PostgreSQL 需要REPLICATION权限。DBA 不放行，整条链路跑不起来——这是要确认的第一件事。

不上 Kafka 还有路吗？不想养 Kafka 集群时，可以用 embedded engine 或 Debezium Server 把事件直写 Redis、Pulsar 等目标，架构如下。

一句话判断：你要把数据库已提交的变更低延迟、不丢地推给搜索、缓存、消息队列或数仓，Debezium 数据同步值得进选型清单；只是做一次性批量迁移、或 T+1 报表够用，就别引入这套 Kafka，脚本足矣。下一步很具体：照 官方教程 把 MySQL 到 Kafka 的样例在本地跑起来，看到第一条create事件出现在 topic 里，前面所有原理都会变成直观感受。

【免费下载链接】debeziumChange data capture for a variety of databases. Please log issues at https://github.com/debezium/dbz/issues.项目地址: https://gitcode.com/gh_mirrors/de/debezium