4. CDC技术选型
在核心银行系统中，CDC（Change Data Capture，变更数据捕获）承担着将账务、客户、额度、交易流水等关键表的增量变化，可靠地投递到下游数仓、风控、反欺诈、客户画像与实时对账系统的职责。选型一旦偏差，轻则下游数据延迟、重复，重则引发账务口径不一致。本节围绕四类主流CDC技术——基于日志、基于触发器、基于时间戳、基于快照——从原理、优劣、适用场景到决策框架逐层展开。
一、四类CDC技术的核心原理
基于日志的CDC：读取数据库的重做日志或二进制日志（如Oracle Redo/Archive Log、MySQL Binlog、PostgreSQL WAL），解析出INSERT/UPDATE/DELETE的物理或逻辑变更。它不侵入业务SQL，对源库性能影响极小，能捕获完整的前后镜像，是核心银行账务类表CDC的首选。
基于触发器的CDC：在源表上创建AFTER INSERT/UPDATE/DELETE触发器，将变更写入影子表或变更队列表。优点是实现直接、可精确控制捕获字段；缺点是触发器与业务事务同事务提交，增加锁竞争与提交延迟，高并发账务场景下风险显著。
基于时间戳的CDC：依赖表中的last_update_time、version等字段，通过轮询“大于上次水位”的记录来抽取增量。实现简单、无需数据库特殊权限，但无法捕获物理删除，且同一时间戳内的并发更新可能被漏读或重复读。
基于快照的CDC：周期性对全表或分区做快照，通过前后快照比对计算差异。它不依赖日志与触发器，适合无法开启日志的遗留系统，但延迟高、资源消耗大，通常作为兜底或初始化手段。
二、方法流程：从需求到选型的五步决策
- 明确下游时效要求：实时风控要求秒级，报表对账可接受分钟级，历史归档可接受小时级。时效直接决定是否必须走日志。
- 盘点源库能力与权限：是否可开启Binlog/Supplemental Log、是否有DBA配合、是否允许创建触发器。核心银行生产库通常权限收紧，日志方案需提前申请。
- 识别变更语义需求：是否需要删除事件、是否需要变更前镜像、是否需要事务边界。账务冲正、抹账等场景必须保留前后镜像与事务顺序。
- 评估源库负载敏感度：交易高峰TPS、锁等待阈值、触发器带来的提交延迟。高并发账务表应排除触发器方案。
- 确定兜底与补偿机制：任何方案都需配套全量初始化与定期对账，快照常作为初始化与差异修复手段。
选型口诀：账务走日志，配置走时间戳，低频走触发器，初始化与兜底走快照。四者不是互斥，而是分层组合。
三、案例场景：核心银行三类表的选型实践
场景一：交易流水表（高并发、强一致）。该表每秒数千笔写入，下游反欺诈要求秒级。选型为基于日志的CDC，开启MySQL Binlog ROW模式并配置binlog_row_image=FULL，通过Canal/Debezium解析后投递Kafka。关键参数示例：
# MySQL 日志CDC关键配置
log_bin = ON
binlog_format = ROW
binlog_row_image = FULL
binlog_expire_logs_seconds = 604800
server_id = 3301
# Debezium 连接器核心参数
"connector.class": "io.debezium.connector.mysql.MySqlConnector",
"database.server.name": "corebank",
"table.include.list": "corebank.txn_flow",
"snapshot.mode": "schema_only",
"decimal.handling.mode": "string"场景二：客户配置表（低频、无删除）。如利率参数、产品配置，每日变更几十条，下游T+1使用。选型为基于时间戳的轮询抽取，水位字段为update_time，配合唯一键去重。需注意同一秒内多条更新，建议水位回退1秒并做幂等。
场景三：遗留系统无日志权限。某老核心库不允许开日志、不允许建触发器，只能每日凌晨做快照比对。选型为基于快照的CDC，通过主键哈希比对生成差异，延迟为T+1，作为过渡方案并推动上游改造。
四、误区与复盘
误区一：认为时间戳CDC能替代日志CDC。时间戳无法捕获物理删除，且并发更新会因水位推进而漏读。账务类表使用时间戳CDC，极易造成下游余额与核心不一致。
误区二：忽视触发器对事务提交的影响。触发器写入影子表与业务同事务，高并发下会放大锁等待，甚至引发交易超时。核心银行生产库应默认禁用触发器方案。
误区三：只做增量不做初始化与对账。任何CDC方案都可能丢事件或重复。必须配套全量快照初始化、定期主键与金额对账、以及基于幂等键的重放能力。
| 技术方案 | 延迟 | 源库影响 | 删除捕获 | 典型适用场景 |
|---|---|---|---|---|
| 基于日志 | 毫秒级 | 极低 | 支持 | 账务、交易流水、实时风控 |
| 基于触发器 | 事务级 | 高 | 支持 | 低频表、临时过渡方案 |
| 基于时间戳 | 轮询周期 | 中 | 不支持 | 配置表、参数表、无删除表 |
| 基于快照 | 小时/天级 | 高 | 支持 | 初始化、对账兜底、遗留系统 |
综上，CDC选型不是单一技术的取舍，而是以日志为主干、时间戳与触发器为补充、快照为兜底的分层组合。在核心银行场景中，凡涉及资金与账务的表，应优先采用基于日志的CDC，并配套全量初始化、幂等消费与定期对账，才能保证下游事件分发的准确性与可追溯性。