1. 课程导入
在银行核心系统里，一笔转账、一次消费、一笔还款，本质上都是交易事件。过去我们习惯用批处理 T+1 对账，用数据库触发器做同步，用 MQ 做点对点通知。但当交易量达到每秒数万笔、下游需要实时风控、实时反欺诈、实时客户画像时，传统方案开始力不从心。Kafka 之所以成为银行交易事件平台的事实标准，不是因为它"快"，而是因为它把事件流变成了可持久化、可回放、可水平扩展的一等公民。
本课程不是 Kafka API 手册，而是一条从"交易事件建模"到"生产级平台落地"的完整工程路径。学完 30 章，你将能独立设计一个支撑日均亿级交易、具备精确一次语义、可审计、可回滚的银行事件平台。
一、学习目标：从"会用 Kafka"到"敢设计平台"
很多工程师对 Kafka 的掌握停留在"生产者发消息、消费者收消息"。但银行场景对平台设计提出了四个硬性要求，这也是本课程的学习目标：
- 事件建模能力：能把一笔复杂银行交易拆解为不可变事件，定义清晰的 Schema 与版本演进策略，而不是把整条数据库记录塞进消息体。
- 可靠性设计能力：理解 acks、min.insync.replicas、幂等生产者、事务、消费者位移提交之间的因果链，能针对"不能丢、不能重"的账务事件做出正确取舍。
- 架构治理能力：能规划 Topic 命名、分区键、保留策略、多集群容灾与数据分级，避免平台随业务增长而失控。
- 可观测与复盘能力：能通过 Lag、ISR、端到端延迟、事务超时等指标定位问题，并形成可复用的排障路径。
二、核心价值：为什么银行需要事件平台而非消息队列
消息队列解决的是"送达"，事件平台解决的是"事实的持续存在"。银行交易事件平台的核心价值体现在三个层面：
| 层面 | 传统 MQ 方案 | Kafka 事件平台 | 银行收益 |
|---|---|---|---|
| 数据形态 | 消费即删除 | 可持久化、可回放 | 支持对账重算、审计追溯 |
| 下游扩展 | 每加一个下游要改上游 | 发布订阅解耦 | 风控、反欺诈、画像独立接入 |
| 一致性 | 难以保证顺序与去重 | 分区有序 + 事务 + 幂等 | 账务事件不重不漏 |
| 吞吐弹性 | 纵向扩容为主 | 分区水平扩展 | 应对秒杀、代发工资峰值 |
换句话说，Kafka 让银行从"交易完成后通知别人"转变为"交易发生即成为可被多方消费的事实流"。这是实时风控和实时决策的前提。
三、整体架构：一张图看清平台分层
下面这张图展示了银行交易事件平台的分层结构。请重点关注数据从核心系统到下游消费的流向，以及 Schema 治理、监控、容灾这些横切能力所处的位置。
四、实战路线图：30 章如何一步步走完
课程按"认知—建模—可靠性—治理—实战"五段推进，每一段都对应真实项目中的一个交付物：
- 认知与建模（第 1–6 章）：理解事件驱动架构，完成银行交易事件分类与 Schema 设计，产出事件字典。
- 核心机制（第 7–14 章）：深入生产者、消费者、分区、副本、位移、再均衡，掌握可靠性参数组合。
- 一致性与容灾（第 15–20 章）：事务、幂等、精确一次、多集群复制、故障切换，产出容灾预案。
- 治理与可观测（第 21–26 章）：Schema 演进、权限审计、监控指标、容量规划，产出平台治理规范。
- 综合实战（第 27–30 章）：从零搭建一个可运行的交易事件平台原型，完成压测与复盘。
建议每学完一段，回到本节这张架构图，标出你当前掌握的层次。平台设计最怕"只见 Topic 不见治理"，这张图就是你的全局坐标。
五、常见误区与复盘提醒
在正式进入技术细节前，先纠正四个高频误区，它们几乎出现在每一个失败的银行 Kafka 项目中：
- 误区一：把 Kafka 当数据库用。 无限保留 + 全量查询会导致成本失控。事件平台应配合分层存储与下游物化视图。
- 误区二：分区键随便选。 银行交易若按随机键分区，同一账户的事件会散落各分区，顺序性丧失，风控规则失效。
- 误区三：acks=all 就万事大吉。 若 min.insync.replicas=1，acks=all 仍可能丢数据。参数必须成组理解。
- 误区四：忽略 Schema 兼容。 下游消费者因字段删除而崩溃，是生产事故的常见根因。
银行交易事件平台的第一原则不是"高吞吐"，而是"事实不可篡改、消费可追溯、故障可恢复"。任何性能优化都不能突破这条底线。
接下来，我们将从银行交易事件的分类与建模开始，把"一笔交易"拆解成平台能正确承载的事件结构。这是整个平台设计的地基。