分布式事务与一致性：CDC数据变更捕获

可视化演示

观察binlog日志型CDC的变更解析与实时流向，对比三种CDC类型的延迟与侵入性，以及offset断点续传机制，可切换三种模式。

CDC基本概念

老周在档案局干了三十年，他最清楚：兄弟单位要的从来不是整本总册，而是“变化”。今天哪个片区添了新生儿，哪户人家搬走了，哪家店铺注销了——只要知道这些“变”，各家的小本子就能自动跟上。CDC 干的就是这件事：把数据库里的每一次插入、修改、删除，从“变更登记簿”里抄出来，变成一条条结构化的“变更事件”，再推送给订阅了这些变化的下游系统。

技术上讲，CDC 全称 Change Data Capture（数据变更捕获），是一套“识别并发布数据变更”的机制。它观察源数据库的变化，把变化封装成事件——事件记录了什么时间、哪张表、哪一行、发生了什么操作，以及变更前后的值。下游拿到事件后可以更新缓存、同步搜索索引、汇入数据仓库，而源系统的业务代码完全不需要改动。

一个典型的 CDC 变更事件，可以用下面的结构描述：

老周把通知单送到各家兄弟单位后，银行更新了客户地址，学校更新了家长联系方式，医院更新了参保人名单——所有人都不必去档案局查原件，就都知道了“世界上发生了什么变化”。这正是 CDC 在分布式系统中的价值：用一份“变更流水”，驱动无数下游副本保持一致。

实现机制

老周这份差事，其实有四种干法。第一种，抄登记簿（日志解析），最省事——办事员每写一笔，登记簿上就有流水。第二种，每天下班把整本总册复印一遍，和昨天的对比找差异（轮询对比），费纸费墨。第三种，在每位办事员桌上放一个小铃铛，每改一笔敲一次铃（触发器），办事员烦不胜烦。第四种，靠市民自觉打电话报备（时间戳），总有人不报，销户更是没法报。

日志解析是目前的主流：MySQL 的 binlog、PostgreSQL 的 WAL，本身就是数据库为了崩溃恢复而写的“流水账”。CDC 工具像老周一样蹲在登记簿旁边，顺序往下读，把每条日志翻译成标准事件。这个方案对业务代码零侵入，还能捕捉到业务层容易漏掉的删除操作——这是轮询和时间戳方案做不到的。

轮询方案则是定期跑一次全表扫描，与上次快照对比找出差异，实现简单但代价高昂。两者成本差距，用下面的式子能直观感受：

触发器方案是在表上建触发器，每次写操作额外执行一段 SQL 把变更记入审计表——相当于给办事员加了一道“每笔都要额外填表”的负担；时间戳方案依赖业务更新时顺手维护 updated_at 字段，却对删除束手无策。老周最终选了登记簿这条路，不是因为它最聪明，而是因为它最安静——档案局里没人感觉到他的存在，这正是日志型 CDC 被广泛采用的原因。

核心优势

老周送单三个月后，局长做了一次复盘，发现这套模式有三个好处。第一，办事员们几乎没感觉到他的存在——不用改窗口流程，不用迁就他。第二，各家兄弟单位拿到通知的时间从“半个月一次”变成“几秒钟一次”。第三，档案局和兄弟单位之间不用专门开会约定格式，一切以登记簿上的流水为准。

从技术视角翻译这三点，就是 CDC 的三大核心优势：低侵入、实时性、解耦。低侵入是因为捕获逻辑完全在源系统之外，业务代码零改动，这也是它区别于“双写”方案的关键——双写要求业务在同一个事务里既写数据库又发消息，一旦消息发送失败就面临一致性风险；CDC 只是默默读日志，从根上杜绝了这个矛盾。

实时性上，日志从提交到被解析，通常毫秒到秒级。对比传统的定时批量同步：

至于解耦，则体现在依赖方向上：源库不需要知道下游是谁、有几个、干什么用，它只需要写好自己的日志；下游通过订阅事件流各取所需。好比档案局从不关心银行和医院拿到通知后怎么用，它只管放好登记簿，让老周去抄。

主流工具

老周不是唯一的信差。市里的快递业卷得厉害，各家有各家的绝活。老李（Debezium）走国际化路线，无论 MySQL、PostgreSQL 还是 Oracle，都输出统一格式的事件；阿强（Canal）是本地土专家，专注 MySQL 的 binlog，在阿里生态里摸爬滚打多年；大刘（Flink CDC）最特别，他送信路上顺手就把包裹拆开、归类、算好账再送——把“捕获”和“实时计算”融为一体。

工具虽多，但骨架一致：一个解析器读懂日志，一条传输通道投递事件，一套格式协议定义消息长相，一个断点机制记录读到哪儿了。用这个框架去打量任何 CDC 工具，几分钟就能摸清它的能力边界：

选工具时，别被“功能全”迷惑。先看清自家数据库是什么、下游接什么、有没有流计算需求。老周的经验是：工具再花哨，四根柱子缺一根都跑不远。

关键挑战

送信路上坑不少。有一天老周遇到三桩麻烦：一叠通知单被风吹乱了顺序，银行照着错序记账，把客户账算岔了；同一张通知单因为摩托车抖动重复送了两遍，银行登记了两次；赶上暴雨天，信送到时晚了两小时，医院的药品库存也跟着晚了两小时更新。

这三个坑，在分布式系统里分别叫：乱序、重复、延迟。乱序的根因是并行：多个消费者同时处理同一业务键的事件，先处理的反而后到。解法是按业务主键哈希分区——同一个订单的所有事件永远进同一分区，由同一线程顺序消费。延迟的根因可能是解析慢、网络抖动或下游消费慢，度量方式是比对事件提交时间与到达时间之差。

重复则几乎必然出现——网络超时重试、消费端“处理成功但提交偏移失败”都会导致一条事件被投递两次。下游必须把消费逻辑写成幂等的，最通用的形式是下面这个性质：

老周后来给自己定了规矩：每个片区的信永远同一个信差送（有序），每张通知单盖上唯一编号、收到先查重（幂等），每趟车装上计速表、超时立刻报警（延迟监控）。CDC 管道健不健壮，看的就是这三件事有没有做扎实。

性能优化

业务越来越大，登记簿一天到晚都有人在写。老周一个人跑不过来了，于是开始优化路线。第一招，把全市按片区划分，每个片区一个信差（并行分片）。第二招，不再一封信跑一趟，攒够一叠再出发（批量投递）。第三招，遇到银行收件特别慢时放慢发件节奏，别把所有信都堆在人家门口（背压控制）。

并行分片是提升吞吐最有效的手段：把事件流按主键哈希拆成多条通道，各通道独立消费。请注意，分片必须保证“同一业务键总是落在同一分片”，否则就会引入上一节说的乱序问题。需要的分片数，可以由事件速率和单线程处理能力估算：

批量处理通过攒批、批写减少 IO 次数，通常能把单线程吞吐提高数倍。背压则是下游的保护机制：当某分片消费跟不上时，自动暂停拉取、控制水位，避免内存溢出。老周的路线图最终平衡了速度与安全：分片给吞吐，批量给效率，背压给稳健。

工程实践

干得久了，老周又接了三个大活：处理新市民登记时的“户籍格式改版”（Schema 变更）；给刚成立的新区分局做“先搬老档案、再送新变更”的首次建账（全量加增量）；以及给市里新建的“数据湖”持续供水（数据入湖）。

Schema 变更最容易翻车——上游加了一列，事件格式变了，下游老代码直接解析报错。规范做法是：用 Schema 注册中心管理事件版本，字段演进只做向前兼容的加法；不兼容的大改造，要“双跑、灰度、回滚”三步走。全量加增量则解决“从零开始”的问题：先做一致性快照并记录快照时刻的日志位点，全量导入完成后从该位点续传增量，最后用对账校验兜底：

如今，订单同步、缓存刷新、搜索索引构建、实时数仓入湖，到处都有老周这样“读日志、抄变更、送事件”的身影。老周在行业里也终于有了正式头衔：Change Data Capture，数据变更捕获。下次你看到某个系统在悄悄保持数据一致，背后很可能就站着一个这样的“信差”。

AI 应用场景

Python 演示

# 老周信差模拟器: 极简日志型 CDC 演示, 含幂等消费与乱序防御class SourceDB:    """档案局: 维护一本市民变更登记簿(日志)"""     def __init__(self):        self.log = []      # 变更登记簿        self.offset = 0    # 日志水位     def apply(self, op, uid, name):        """产生一条变更流水, version 取日志序号保证单调递增"""        entry = {            "offset": self.offset,            "op": op,            "uid": uid,            "name": name,            "version": self.offset,        }        self.log.append(entry)        self.offset += 1        return entry  class CDCChannel:    """老周: 从登记簿抄单, 用游标记录已投递位点"""     def __init__(self, source):        self.source = source        self.cursor = 0     def poll(self):        """拉取尚未投递的变更事件"""        events = self.source.log[self.cursor:]        self.cursor = len(self.source.log)        return events  class DownstreamDB:    """银行等下游: 按唯一键与版本号幂等更新"""     def __init__(self):        self.records = {}     def apply_idempotent(self, event):        """同一事件重复投递无副作用, 旧版本不覆盖新版本"""        key = event["uid"]        old = self.records.get(key)        if event["op"] == "DELETE":            if old is None or event["version"] <= old["version"]:                return            self.records.pop(key, None)            return        if old is not None and event["version"] <= old["version"]:            return        self.records[key] = event  def main():    source = SourceDB()    cdc = CDCChannel(source)    bank = DownstreamDB()     source.apply("INSERT", 1, "Alice")    source.apply("INSERT", 2, "Bob")    for event in cdc.poll():        bank.apply_idempotent(event)     # 模拟网络重试: 同一条事件投递两次    duplicate = source.log[1]    bank.apply_idempotent(duplicate)    assert len(bank.records) == 2, "重复投递产生了重复数据"     # 模拟乱序: 先到 v2 再到 v1, 旧版本应被丢弃    v2 = {"op": "UPDATE", "uid": 1, "name": "Alice2", "version": 2}    v1 = {"op": "UPDATE", "uid": 1, "name": "Alice1", "version": 1}    bank.apply_idempotent(v2)    bank.apply_idempotent(v1)    assert bank.records[1]["name"] == "Alice2", "旧版本覆盖了新版本"     # 删除事件同步    source.apply("DELETE", 2, "Bob")    for event in cdc.poll():        bank.apply_idempotent(event)    assert 2 not in bank.records, "删除同步失败"     print("同步后银行档案:", {k: v["name"] for k, v in bank.records.items()})    print("CDC 演示通过: 幂等/乱序防御/删除同步均正常")  if __name__ == "__main__":    main()

1. events = self.source.log[self.cursor:]老周抄单的核心：只取游标之后的变更，天然支持断点续传
2. self.cursor = len(self.source.log)抄完一批就推进水位，下次从这里继续
3. def apply_idempotent(self, event):下游银行的核心防御：不管信来几遍，结果只认一次
4. if old is not None and event["version"] <= old["version"]:版本号比较，旧事件一律丢弃
5. duplicate = source.log[1]模拟网络重试造成的重复投递
6. bank.apply_idempotent(v2)先应用新版本，为后面的乱序测试做铺垫
7. assert bank.records[1]["name"] == "Alice2", "旧版本覆盖了新版本"核心断言：证明 v1 没能覆盖 v2
8. if __name__ == "__main__":保证模块既能被导入也能独立运行

常见误区

面试题