3. CDC技术原理
在金融主数据同步场景中，核心诉求是让下游风控、报表、客户画像等系统尽快感知上游核心系统的数据变化，同时不能对交易库造成明显压力。CDC（Change Data Capture，变更数据捕获）正是解决这一矛盾的关键技术。它并不复制整张表，而是持续识别“哪些行发生了插入、更新、删除”，并把变更事件按发生顺序交付给下游。理解CDC的原理与工具差异，是后续使用Flink CDC构建实时同步链路的基础。
一、CDC的核心概念与价值
CDC的本质是把数据库内部的数据变更转化为可消费的事件流。一次变更通常包含操作类型（INSERT/UPDATE/DELETE）、变更前后的字段值、发生时间以及事务边界信息。对金融主数据而言，客户信息、账户状态、产品参数等表的每一次修改，都可能触发下游的合规校验或额度重算，因此CDC不仅要“捕获到”，还要保证顺序性、不丢不重和可追溯。
与批量抽取相比，CDC的优势在于：延迟从小时级降到秒级甚至毫秒级；只传输变化量，网络与目标库写入压力更小；能够保留删除和更新前值，便于下游做精确回放。它的典型价值可以概括为三点：实时性、低侵入、可审计。
关键认知：CDC不是“把数据库当消息队列”，而是通过解析数据库自身的变更记录或触发器机制，生成结构化变更事件。事件顺序与事务提交顺序的一致性，是金融场景选型的硬指标。
二、基于日志的CDC：原理与流程
基于日志的CDC是目前主流方案。MySQL的binlog、Oracle的redo log、PostgreSQL的WAL都记录了数据页或行的物理/逻辑变更。CDC工具以复制协议或日志解析方式读取这些日志，将其转换为JSON或Avro格式的变更事件。以MySQL为例，binlog_format需设置为ROW，才能拿到每一行的前后镜像。
-- MySQL 关键参数示例
[mysqld]
server-id = 223344
log_bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL
expire_logs_days = 7基于日志的CDC流程通常分为四步：第一，建立日志读取连接并记录起始位点（binlog file + position 或 GTID）；第二，按事务顺序解析日志事件；第三，将行级变更封装为带schema的变更消息；第四，向下游发送并定期提交位点。位点管理决定了故障恢复后能否从断点续传，是生产稳定性的关键。
三、触发器与快照方案对比
除日志解析外，还有两类常见思路。其一是触发器方案：在源表上创建AFTER INSERT/UPDATE/DELETE触发器，把变更写入一张变更日志表，再由采集程序读取。其优点是实现直观、对数据库版本要求低；缺点是触发器与业务事务耦合，增加提交延迟，且高并发下容易成为瓶颈，金融核心库通常不推荐。
其二是快照方案：周期性执行全量或增量查询，通过时间戳、版本号比对差异。它实现简单，但无法捕获物理删除，且高频轮询会给源库带来压力。实际生产中，快照常作为日志CDC的补充，用于初始化全量数据或修复历史缺口。
| 对比维度 | 基于日志CDC | 触发器CDC | 快照/轮询CDC |
|---|---|---|---|
| 实时性 | 毫秒到秒级 | 秒级 | 分钟到小时级 |
| 对源库影响 | 低，仅读日志 | 高，写入放大 | 中，查询压力 |
| 能否捕获删除 | 可以 | 可以 | 通常不能 |
| 顺序一致性 | 强，按事务 | 受触发器执行影响 | 弱 |
| 金融场景适用性 | 首选 | 谨慎使用 | 仅作初始化补充 |
四、常见CDC工具与选型要点
开源生态中，Debezium是最具代表性的日志CDC工具，支持MySQL、PostgreSQL、Oracle、SQL Server等，输出结构化变更事件，常与Kafka Connect配合。Canal是阿里开源的MySQL binlog解析工具，在国内金融与互联网场景使用广泛。Flink CDC则把采集与计算统一到Flink作业中，支持全增量一体化读取，并可直接做流式转换后写入下游，减少组件拼接成本。
商业与云服务方面，Oracle GoldenGate、AWS DMS、阿里云DTS等提供托管能力，适合运维力量有限但预算充足的团队。选型时应重点评估：源库类型与版本兼容性、是否支持无锁快照、位点管理可靠性、schema变更处理能力、Exactly-Once语义以及社区活跃度。
选型建议：金融主数据同步优先选择“日志CDC + 全量快照初始化”的组合。若团队已使用Flink，Flink CDC可显著降低链路复杂度；若已有Kafka生态，Debezium是成熟稳妥的选择。
五、误区与复盘
实践中常见误区有三。第一，认为开启binlog就等于CDC，忽略了ROW格式、位点管理和事务边界处理。第二，用触发器方案承载高并发交易库，导致源库性能下降。第三，只做增量不做快照，导致历史数据缺失、下游无法对齐。复盘时应检查：位点是否持久化、是否支持断点续传、schema变更是否有预案、删除事件是否被正确传递。
风险提示：金融场景中，CDC链路的延迟和丢失都可能影响风控决策。务必对位点提交、异常重试和监控告警做专项设计，避免“看起来通了，实际上漏了”。
掌握CDC的概念、日志原理、方案对比与工具差异后，下一步就可以进入Flink CDC的具体接入与作业开发，把变更事件真正转化为金融主数据的实时同步能力。