1. 课程导入

在金融交易、清算、风控与账务系统中，事件不是“普通消息”，而是带有资金含义、法律效力和审计要求的业务事实。一笔支付指令、一次账户扣款、一条风控决策、一条清算状态变更，一旦被重复处理或乱序处理，轻则造成对账差异，重则引发资金损失与合规风险。因此，顺序性与Exactly Once不是可选的技术优化，而是金融事件处理系统的生存底线。

一、核心原理：为什么金融场景必须同时关注顺序与精确一次

金融事件流通常具备三个特征：有状态、有依赖、有因果。例如“开户→入金→交易→扣费→出金”构成一条业务链，后一事件必须在前一事件生效后才能被正确处理。如果系统只保证“至少一次”，重复消息会导致重复扣款；如果只保证“至多一次”，丢失消息会导致账实不符；如果只保证“最终一致”但允许乱序，则可能先执行出金、后执行入金，造成透支或风控误判。

Exactly Once 的本质不是“消息只发一次”，而是端到端处理效果只发生一次。它通常由三部分共同保证：幂等写入、事务性提交、以及可重放且可去重的偏移量管理。顺序性则分为分区内顺序、全局顺序和业务因果顺序三个层次。金融系统往往不需要全局顺序，但必须保证同一账户、同一交易、同一清算批次内的事件严格有序。

二、方法流程：从事件产生到账务生效的完整链路

一个典型的金融事件处理链路包括：事件生产、序列化与分区、传输、消费、状态更新、结果提交与对账。要同时实现顺序与 Exactly Once，需要在每个环节做针对性设计。

1. 生产端：为每个业务键（如账户号、交易号）计算分区键，确保同一键的事件进入同一分区；同时为事件分配业务序列号或版本号。
2. 传输端：启用幂等生产者与事务写入，避免网络重试造成重复消息。
3. 消费端：按分区顺序拉取，使用事务性消费或幂等写入，将“处理结果”和“偏移量提交”放在同一事务中。
4. 状态端：账务表、余额表、风控状态表必须支持唯一约束或版本号比对，防止重复更新。
5. 对账端：通过业务序列号、全局事件ID和账务流水进行三方核对，发现乱序或重复时触发补偿。

下面是一个简化的消费端幂等写入示例，展示如何用业务唯一键和版本号避免重复扣款：

-- 账务流水表：event_id 唯一，account_no + seq_no 唯一
INSERT INTO account_ledger (
  event_id, account_no, seq_no, amount, direction, status
) VALUES (
  'evt_20250101_0001', 'ACC10086', 1001, 500.00, 'DEBIT', 'POSTED'
)
ON CONFLICT (event_id) DO NOTHING;

-- 余额更新：仅当当前版本号小于事件版本号时才更新
UPDATE account_balance
SET balance = balance - 500.00,
    version = 1001
WHERE account_no = 'ACC10086'
  AND version < 1001;

三、案例/场景：支付清算中的乱序与重复

假设某支付系统在同一账户上依次产生三条事件：入金 1000 元、交易扣款 300 元、出金 800 元。若消息因网络抖动乱序到达，系统先处理出金 800 元，此时余额为 0，出金会被拒绝或造成透支；若入金事件因重试被重复消费两次，账户会凭空多出 1000 元。这两种错误在金融场景中都属于严重事故。

再考虑清算批次场景：同一批次内包含多笔交易，批次状态从“待清算”变为“清算中”再变为“已清算”。如果“已清算”事件先于“清算中”到达，后续对账逻辑会认为批次从未进入清算流程，导致资金挂账。因此，金融系统通常要求同一清算批次的事件必须严格有序，且每个状态迁移只能生效一次。

四、误区/复盘：常见错误与正确认知

很多团队在初期会陷入几个典型误区。第一，认为“消息中间件支持 Exactly Once，业务就自动精确一次”。实际上，中间件只能保证其内部链路，业务侧仍需幂等。第二，认为“全局顺序”是必须的。全局顺序代价极高，金融系统通常只需保证业务键级别顺序。第三，认为“重试无害”。在金融场景中，重试必须配合唯一键和版本号，否则重试就是重复扣款。

五、整体课程框架与实战环境准备

本课程共 30 章，整体分为五个模块：基础原理（第1-5章）、顺序性设计（第6-12章）、Exactly Once 实现（第13-20章）、金融场景实战（第21-27章）、对账、补偿与复盘（第28-30章）。每章都会围绕一个可运行的最小场景展开，避免只讲概念。

实战环境建议准备如下组件：

# 推荐环境
JDK 17+
Apache Kafka 3.x 或 Pulsar 3.x
PostgreSQL 15+（用于账务与幂等表）
Redis 7+（用于去重与序列号缓存）
Docker Compose（一键启动依赖）
# 核心配置示例
spring.kafka.producer.enable-idempotence=true
spring.kafka.producer.transaction-id-prefix=fin-tx-
spring.kafka.consumer.isolation-level=read_committed
spring.kafka.consumer.enable-auto-commit=false