4. 实时事件基础
在核心银行系统中，批处理负责日终清算、计息、对账等周期性任务，而实时事件协同则解决“交易发生瞬间就要感知、判断、响应”的问题。理解实时事件基础，是构建批实时协同能力的第一步。本节从事件驱动架构出发，逐层拆解实时事件的定义、消息中间件、事件流处理与复杂事件处理，并结合典型场景说明其落地方式。
一、核心原理：从“拉”到“推”的架构转变
传统批处理采用“拉”模式：系统按固定周期扫描数据库，批量读取待处理数据。这种方式延迟高、资源集中消耗大，且难以应对突发交易。事件驱动架构（EDA）则采用“推”模式：交易发生时立即产生事件，由消息中间件推送给订阅方，实现近实时响应。
事件驱动架构的核心组件包括：事件生产者、事件通道、事件消费者和事件处理器。生产者负责捕获业务动作并封装为事件；通道负责解耦与缓冲；消费者按需订阅并触发后续逻辑。其关键价值在于解耦——生产者无需知道谁消费，消费者无需关心事件来源，从而支持灵活扩展。
实时事件的定义：实时事件是对业务状态变化的轻量级、不可变记录，通常包含事件类型、发生时间、主体标识、关键属性和上下文。例如“账户A发生一笔转账支出5000元”就是一个典型事件。它强调“已发生”的事实，而非“请求”或“命令”。
二、消息中间件：事件传输的骨干
消息中间件是事件驱动架构的传输层，负责事件的可靠投递、顺序保障和流量削峰。核心银行场景中常用的中间件包括Kafka、RocketMQ、Pulsar等。选型时需关注以下参数：
| 维度 | 说明 | 典型要求 |
|---|---|---|
| 吞吐量 | 单位时间处理消息数 | ≥10万条/秒 |
| 延迟 | 端到端投递时间 | 毫秒级 |
| 持久化 | 消息落盘与重放能力 | 支持多副本 |
| 顺序性 | 同一分区内有序 | 按账户维度保序 |
| 事务 | 跨消息原子性 | 支持事务消息 |
以Kafka为例，生产者发送事件的基本配置如下：
# 生产者关键参数
acks=all # 所有副本确认
retries=3 # 重试次数
enable.idempotence=true # 幂等生产者
max.in.flight.requests.per.connection=1 # 保序
消费者需关注消费位点提交与重复消费问题。核心银行通常要求“至少一次”语义，并在业务层做幂等处理。
三、事件流处理与复杂事件处理
事件流处理（ESP）是对连续事件流进行实时计算，如过滤、聚合、窗口统计。复杂事件处理（CEP）则更进一步，通过模式匹配识别多个事件之间的时序、因果或聚合关系。例如：
- ESP场景：实时统计某账户近1分钟交易笔数，超过阈值触发风控预警。
- CEP场景：识别“同一账户在5分钟内先小额试探、再大额转出”的欺诈模式。
CEP常用工具包括Flink CEP、Esper等。其核心是定义模式序列，例如：
// Flink CEP 模式示例
Pattern.<Event>begin("small")
.where(e -> e.amount < 100)
.next("large")
.where(e -> e.amount > 5000)
.within(Time.minutes(5));
提示：ESP关注“流上的计算”，CEP关注“事件间的模式”。两者常配合使用：先用ESP做实时聚合，再用CEP做模式识别。
四、典型场景与误区复盘
典型场景一：实时反欺诈。交易事件流入后，CEP引擎匹配异常模式，命中后立即冻结账户并通知批处理系统调整日终清算范围。
典型场景二：实时余额更新。转账事件触发余额变更，同时写入事件日志，供批处理对账时核对。
典型场景三：批实时协同。批处理任务完成时发布“批次完成”事件，实时系统据此触发后续通知或报表刷新。
常见误区：① 认为“实时”等于“零延迟”，忽视网络与处理开销；② 忽略事件顺序，导致余额计算错误；③ 未做幂等，重复消费引发重复扣款；④ 过度依赖CEP，简单过滤也用复杂引擎，增加运维成本。
复盘时需关注：事件是否可追溯、消费位点是否可重置、异常事件是否有死信队列、模式匹配是否可回放验证。只有把实时事件基础打牢，批处理与实时事件的协同才能稳定可靠。