📚 课程目录第2章金融事件基础

2. 金融事件基础

在金融系统中，“事件”不是简单的日志记录，而是业务状态发生确定性变化的不可变事实。一笔支付从发起到入账，一次风控从规则命中到拦截，一条行情从交易所撮合到推送，本质上都是事件在时间轴上的有序排列。理解金融事件的定义、类型与生命周期，是掌握顺序性与 Exactly Once 语义的前提。

一、核心原理：什么是金融事件

金融事件是对“已经发生的业务动作”的权威描述，具备三个关键属性：不可变性（发生即定稿，不可修改）、时序性（携带发生时间与全局顺序）、可追溯性（可回放、可审计）。它与“命令”有本质区别：命令是“请做某事”的意图，可能被拒绝；事件是“已经做了某事”的结果，必须被记录。

事件 = 唯一事件ID + 事件类型 + 发生时间戳 + 业务主体 + 状态变更载荷 + 因果链标识（如 traceId / 父事件ID）

在事件驱动架构（EDA）中，系统不再以“请求-响应”为中心，而是以事件流为中心：生产者发布事件，消费者订阅并驱动后续动作。这种模式天然契合金融业务，因为金融的核心诉求正是状态可追溯、流程可编排、系统可解耦。

二、金融事件的类型与典型场景

按业务域划分，金融事件主要分为四类，它们对顺序性和一致性的要求各不相同：

事件类型	典型场景	顺序性要求	一致性要求
支付事件	下单、扣款、退款、冲正	强（同一订单必须有序）	Exactly Once（资金不可重复扣）
清算事件	轧差、结算、对账、日切	强（批次内严格有序）	Exactly Once + 幂等
风控事件	规则命中、评分、拦截、放行	中（同一用户需有序）	At Least Once 可接受
行情事件	逐笔委托、成交、快照推送	极强（价格时间优先）	顺序优先，允许少量重复

可以看到，越靠近资金和账务，对 Exactly Once 的要求越高；越靠近行情和监控，顺序性反而比去重更关键。这正是后续章节要解决的核心矛盾。

三、事件的生命周期

一个金融事件从产生到归档，通常经历六个阶段：

产生（Produce）：业务动作触发，生成带唯一ID的事件。
发布（Publish）：写入消息中间件（如 Kafka、Pulsar），分配分区与偏移量。
传输（Transport）：按分区有序传递，可能发生重试与重复。
消费（Consume）：消费者拉取并处理，更新本地状态。
确认（Ack）：提交偏移量，标记处理完成。
归档（Archive）：落入事件存储，供审计与回放。

生命周期中最容易出问题的是“消费”与“确认”之间：如果先处理再确认时崩溃，事件会被重复消费；如果先确认再处理时崩溃，事件会丢失。Exactly Once 的本质，就是让这两步成为一个原子操作。

四、事件驱动架构概述与常见误区

事件驱动架构（EDA）在金融落地时，通常采用“事件溯源 + 消息中间件 + 幂等消费者”的组合。生产者只追加事件，消费者通过重放事件重建状态。这种架构的优点是审计友好、扩展性强，但也带来新的挑战。

常见误区一：认为“消息中间件保证顺序”就等于“业务顺序正确”。实际上，Kafka 只保证单分区有序，若业务键被散列到不同分区，顺序依然会乱。
常见误区二：把“至少一次”当成“足够安全”。在支付扣款场景，重复消费意味着重复扣钱，必须通过幂等键或去重表实现 Exactly Once 效果。
常见误区三：忽略事件时间与处理时间的差异。行情事件若按处理时间排序，会得到错误的价格序列。

复盘一个典型支付场景：用户下单产生 OrderCreated，支付网关产生 PaymentInitiated，银行回调产生 PaymentSucceeded。若这三个事件因分区不同而乱序到达账务系统，就可能出现“先入账后扣款”的错账。解决方案是以订单号作为分区键，确保同一订单的所有事件进入同一分区，从而获得局部严格顺序。

// 以订单号为分区键，保证同一订单事件有序
producer.send(new ProducerRecord<String, String>(
    "payment-events",   // topic
    orderId,            // key = 分区键
    eventJson           // value
));

// 消费者幂等处理示例
if (dedupTable.exists(event.getEventId())) {
    return; // 已处理，直接跳过
}
process(event);
dedupTable.save(event.getEventId());
commitOffset();