1. 课程导入
在核心银行系统中，批处理与实时事件协同并不是两个可以割裂看待的技术模块，而是同一套账务体系在“日终清算”与“日间服务”两种时间尺度上的协同运行机制。很多系统故障并非源于单个批处理作业写错，也不是实时接口本身不可用，而是两者在时间窗口、数据版本、状态归属和补偿责任上发生了冲突。本课程的第一章不急于进入代码和配置，而是先建立一张完整的认知地图：我们究竟要解决什么问题，系统由哪些关键部件构成，批处理与实时事件在哪些边界上交汇，以及掌握这些协同机制后能在生产实践中获得什么价值。
一、学习目标：从“会跑批”到“能协同”
本课程的学习目标分为四个层次，逐层递进。第一层是理解核心银行批处理的基本运行模型，包括日终批量、联机批量、定时任务、文件交换和账务汇总等典型形态。第二层是掌握实时事件在核心银行中的产生、路由、消费和落账机制，尤其是交易事件、账户变动事件、限额事件和风控事件的区别。第三层是能够识别批处理与实时事件在时间窗口、数据一致性、幂等控制和异常补偿上的冲突点，并给出可落地的协同方案。第四层是具备生产排障与复盘能力，能够从日志、队列积压、批处理状态和账务核对结果中定位协同失效的根因。
核心判断：批处理与实时事件协同的本质，不是让批处理变快，也不是让实时链路变慢，而是让两者在正确的数据版本和正确的业务时点上各司其职。批处理负责终态一致性和批量清算，实时事件负责日间响应和状态同步，二者通过明确的边界和补偿机制形成闭环。
二、业务背景：为什么核心银行必须同时依赖批处理与实时事件
核心银行的业务天然具有“双时间尺度”特征。一方面，存款、贷款、卡、支付、总账等业务在日间需要实时响应，客户发起一笔转账后，账户余额、可用余额、交易流水和风控状态都需要在秒级内更新。另一方面，利息计提、手续费分摊、还款计划重算、总分核对、监管报送和日终决算等操作，又必须在日终或特定时间窗口内以批量方式完成。如果只依赖实时链路，系统难以承受大规模汇总和复杂计算；如果只依赖批处理，客户体验和风险控制又无法满足日间要求。
因此，现代核心银行普遍采用“实时事件驱动日间状态，批处理驱动终态清算”的混合架构。日间交易产生的事件进入消息队列或事件总线，由实时消费者更新账户状态、登记流水并触发风控；日终批处理则基于已落地的流水和状态，执行计提、汇总、核对和清算。两者之间通过数据版本、切日标记、事件重放和补偿任务进行衔接。
三、整体知识框架：五个协同层次
为了便于后续章节展开，这里将核心银行批处理与实时事件协同划分为五个层次。第一层是时间边界层，解决日间与日终的切日、窗口和锁控制问题。第二层是数据一致性层，解决实时更新与批量汇总之间的数据版本和幂等冲突。第三层是事件路由层，解决事件产生、分发、消费和重试的链路问题。第四层是批处理调度层，解决作业依赖、并发控制、失败重跑和断点续跑。第五层是监控与补偿层，解决队列积压、账务不平、事件丢失和批量失败的发现与修复。
这五个层次不是孤立存在的。例如，切日标记会直接影响事件路由的消费位点，数据版本会影响批处理汇总的准确性，监控补偿层则决定了协同失效后系统能否快速恢复。后续章节将围绕这五层逐一展开。
四、核心原理：批处理与实时事件的协同边界
批处理与实时事件协同的核心原理可以概括为“三个边界”。第一是时间边界：日间实时链路和日终批量链路必须在明确的切日点上切换，切日之前的事件属于当日，切日之后的事件属于下一日。第二是数据边界：实时链路负责更新账户的日间状态，批处理负责生成终态账务和汇总数据，两者不能同时修改同一份余额记录而不加控制。第三是责任边界：实时事件负责“发生了什么”，批处理负责“最终应该是什么”，当两者不一致时，必须有明确的补偿责任方。
| 协同维度 | 实时事件链路 | 批处理链路 | 协同关键点 |
|---|---|---|---|
| 运行时间 | 日间 7×24 小时持续运行 | 日终窗口或定时触发 | 切日标记与窗口互斥 |
| 数据对象 | 账户状态、可用余额、流水 | 总账、计提、汇总、报表 | 数据版本与快照一致性 |
| 处理粒度 | 单笔交易或单事件 | 批量分片或全量汇总 | 幂等键与分片边界 |
| 失败处理 | 重试、死信、人工干预 | 断点续跑、失败重跑 | 补偿任务与对账机制 |
| 一致性要求 | 最终一致，允许短暂延迟 | 终态一致，必须平账 | 核对与差异修复 |
五、案例场景：一次切日窗口引发的协同故障
某银行核心系统在日终切日时，批处理作业开始汇总当日交易流水，但实时事件消费者仍在消费切日前的延迟事件。由于切日标记已经生效，批处理将部分延迟事件归入下一日，导致当日流水汇总少计，次日流水多计。次日日间，客户发现账户余额与流水不一致，风控系统触发异常告警。排查后发现，根因不是批处理算错，也不是实时消费者丢失事件，而是切日标记与事件消费位点没有形成原子切换。
故障时间线：
22:00:00 批处理切日标记置为 NEXT_DAY
22:00:03 实时消费者仍在消费 21:59:58 产生的事件
22:00:05 批处理开始汇总当日流水，未包含上述延迟事件
22:00:30 批处理汇总完成，当日流水少计 37 笔
次日 09:15 客户对账发现余额差异，触发告警
次日 10:40 通过事件重放和补偿任务修复差异复盘要点：切日不是简单改一个状态位，而是需要与事件消费位点、批处理启动条件和补偿任务联动。任何一方的时序错位，都会导致账务差异。生产环境中应优先保证切日操作的原子性，并设置延迟事件缓冲区和差异核对任务。
六、常见误区与学习建议
- 误区一：认为批处理只是“夜间跑数”。实际上批处理承担终态清算、总分核对和监管报送等关键职责，其正确性直接决定账务是否可信。
- 误区二：认为实时事件越多越好。事件过多会增加消费链路复杂度和幂等控制难度，应根据业务时点和一致性要求选择事件粒度。
- 误区三：忽视补偿任务的设计。协同系统不可能永远不出错，关键在于出错后能否快速发现、定位和修复。
- 误区四：只关注单笔交易正确性，忽视批量汇总一致性。单笔正确不等于汇总正确，汇总正确也不等于总账平账，必须建立多层核对机制。
学习建议：在学习后续章节时，建议始终带着三个问题：这个机制解决的是时间边界、数据边界还是责任边界？它在生产环境中最容易在哪个环节失效？如果失效，我应该看哪些日志、队列和核对结果？带着问题学习，比单纯记忆配置和代码更有效。
七、实战价值：掌握协同能力后的职业收益
掌握核心银行批处理与实时事件协同能力后，最直接的收益是具备生产排障的全局视角。面对账务不平、队列积压、批量失败或事件丢失等问题，能够快速判断问题属于哪个层次，而不是盲目重启作业或重放事件。其次，能够参与核心系统架构设计，在切日方案、事件模型、幂等策略和补偿机制上给出可落地的建议。最后，这种能力在银行、支付、清算和金融科技领域具有较高的稀缺性，是从“业务开发”走向“核心系统专家”的关键一步。