1. 课程导入
欢迎进入《核心银行CDC与下游事件分发实战》。在动手配置任何一条链路之前，我们需要先建立一张"全局地图"：核心银行系统长什么样、CDC在其中的位置、它解决什么问题、下游又有哪些典型消费者。只有把这三层关系看清楚，后面的参数调优、故障排查才有判断依据。
一、核心银行系统架构：从集中式到服务化
核心银行系统（Core Banking System）承载存款、贷款、卡、总账等关键账务，是银行IT体系中最"重"的部分。典型架构可以按纵向分层理解：
- 渠道接入层：柜面、手机银行、网银、ATM、开放银行API，负责交易发起与协议转换。
- 业务服务层：账户、交易、产品、定价、额度等微服务或CICS/COBOL交易程序，负责业务规则与编排。
- 核心账务层：账务引擎与总账，保证借贷平衡、余额准确、流水可追溯，是数据一致性的"最后防线"。
- 数据存储层：关系型数据库（如DB2、Oracle、GaussDB、OceanBase）与主机VSAM/IMS等，是CDC真正捕获变更的源头。
关键认知是：核心账务层的数据变更，才是下游最关心的事实来源。渠道和服务的日志往往只反映"请求"，而账务库的变更才代表"资金真正动了"。
二、CDC技术价值：为什么不用"查库"和"双写"
CDC（Change Data Capture，变更数据捕获）通过解析数据库日志（redo/archive log、binlog、WAL）或触发器，把行级变更以近实时方式输出为事件流。相比传统方案，它的价值集中在三点：
| 方案 | 时效性 | 对核心库压力 | 数据完整性 | 典型问题 |
|---|---|---|---|---|
| 定时批量抽数 | 分钟~小时级 | 高（大范围扫描） | 易漏中间态 | 窗口期长、影响联机交易 |
| 应用双写 | 准实时 | 低 | 依赖代码质量 | 漏写、顺序错乱、事务不一致 |
| CDC日志解析 | 秒级/亚秒级 | 低（读日志） | 完整、有序 | 需处理DDL、大事务、断点续传 |
CDC的核心承诺是：不侵入核心交易代码，不增加联机库查询压力，同时提供完整、有序、可回放的变更流。这正是核心银行系统最需要的"低扰动、高可靠"数据出口。
三、下游事件分发场景
CDC捕获的变更不会只给一个消费者。真实生产中，同一条账务变更往往要同时服务多个下游，形成"一对多"的事件分发拓扑：
- 实时风控与反欺诈：需要毫秒级感知大额、频繁、异地交易。
- 客户画像与营销：关注余额变动、产品持有变化，用于实时推荐。
- 数据仓库/湖仓：需要准实时入仓，支撑T+0报表与监管报送。
- 对账与清算：要求事件不丢不重，支持按业务主键幂等消费。
- 缓存与查询服务：把变更同步到Redis/ES，支撑高并发查询。
这些下游的时效、顺序、幂等要求各不相同，因此分发层必须解决路由、过滤、格式转换、顺序保障、失败重试五类问题。
四、学习路径与常见误区
本课程后续30章将沿着"原理—采集—分发—治理—实战"推进。建议的学习顺序是：先理解日志解析与事务边界，再掌握分发路由与幂等设计，最后进入压测、监控与故障复盘。
学习建议：每学一个组件，都问自己三个问题——它捕获的是什么粒度的变更？它如何保证顺序与不丢？它在下游如何被幂等消费？
三个高频误区：
- 把CDC当成"数据库导出工具"，忽略DDL变更和大事务对解析的影响。
- 认为"消息中间件保证不丢"就等于"端到端不丢"，忽视消费端幂等与位点提交。
- 所有下游共用一条无差别事件流，导致风控被报表流量拖慢。
下面是一段典型的CDC采集配置片段，后续章节会逐项拆解其含义：
# CDC采集任务核心参数示例
source:
type: logminer
database: coredb
tables: [acct_txn, acct_balance, card_info]
start_mode: latest
transaction_order: true
sink:
type: kafka
topic: core.cdc.txn.v1
partition_key: acct_no
exactly_once: true