1. 课程导论：中间件状态机与幂等校验在支付系统中的核心价值
在分布式支付系统中，订单处理涉及多个微服务、消息队列、数据库和外部渠道。任何一个环节的网络抖动、超时重试或节点故障，都可能导致同一笔支付请求被重复处理。此时，中间件状态机与幂等校验成为保障资金安全和数据一致性的两大基石。
1.1 支付系统的核心挑战
支付场景对数据一致性要求极高，但分布式环境天然存在以下问题：
- 重复请求：客户端超时重试、MQ 消息重复投递、网关回调重复推送。
- 状态不一致：订单状态在多个服务间流转，缺乏统一的状态机约束。
- 中间件故障：数据库主从延迟、缓存失效、消息丢失或乱序。
关键指标：在支付系统中，一次重复扣款可能导致资损；一次状态回退可能导致对账不平。因此，幂等性是支付系统的第一道防线，状态机是第二道防线。
1.2 中间件状态机：支付订单的“交通规则”
状态机为支付订单定义了明确的生命周期：每个状态都有合法的前驱和后继，非法状态转换被强制拦截。通过将状态机逻辑封装在中间件层，可以实现以下目标：
- 统一管控：所有服务通过中间件查询或变更订单状态，避免各自维护状态逻辑。
- 防乱序：状态机保证“已支付”不能回退到“待支付”，“已退款”不能再次退款。
- 可审计：每次状态变更都记录事件，便于对账和问题追溯。
1.3 幂等校验：防止重复处理的“安全锁”
幂等性是指同一操作无论执行多少次，其结果都与执行一次相同。在支付系统中，幂等校验通常通过唯一请求键（Idempotency Key）实现：
| 场景 | 幂等键来源 | 校验时机 | 处理方式 |
|---|---|---|---|
| 用户发起支付 | 订单号 + 支付渠道 | 请求到达中间件时 | 查询 Redis/DB，若已处理则直接返回结果 |
| 支付网关回调 | 渠道交易流水号 | 回调接收时 | 去重表 + 分布式锁 |
| MQ 消息消费 | 消息唯一 ID | 消费前 | 幂等表 + 状态机前置校验 |
| 退款请求 | 退款请求号 | 退款发起时 | 幂等键 + 状态机检查订单状态 |
最佳实践：幂等校验不应仅依赖数据库唯一索引，还需结合状态机。例如：同一订单的“支付成功”回调重复到达时，幂等校验应返回已成功，但状态机应拒绝“待支付→已支付”的重复转换。
1.4 状态机 + 幂等校验：双保险架构
将状态机与幂等校验结合，形成支付中间件的核心能力：
- 请求入站：中间件拦截所有支付相关请求，提取幂等键。
- 幂等校验：查询幂等记录，若已处理则直接返回历史结果；若未处理则继续。
- 状态机校验：检查当前订单状态是否允许目标转换。
- 原子写入：在数据库事务中同时更新订单状态和幂等记录。
- 结果返回：将处理结果写入缓存，供后续幂等查询使用。
1.5 为什么选择 PostgreSQL 作为中间件存储
本课程选用 PostgreSQL 作为状态机和幂等校验的底层存储，原因如下：
| 特性 | 对支付系统的价值 |
|---|---|
| 事务 ACID | 保证状态变更与幂等记录原子写入 |
| 唯一索引 + 部分索引 | 高效实现幂等键去重，支持条件唯一约束 |
| 行级锁 + 乐观锁 | 避免并发请求下的状态覆盖 |
| CTE 与子事务 | 在一条 SQL 中完成状态机校验与数据更新 |
| 逻辑复制与物化视图 | 支撑中间件的高可用与实时对账 |
避坑提示：不要将幂等校验完全交给数据库唯一索引。在高并发下，唯一索引冲突会导致大量重试和死锁。正确的做法是：先查缓存 + 再查 DB + 最后用唯一索引兜底。
1.6 本课程工程案例概览
在后续章节中，我们将基于一个真实的支付中间件项目，逐步实现：
- 基于 PostgreSQL 的通用状态机引擎
- 支持多场景的幂等校验中间件
- 状态机与幂等校验的集成方案
- 高并发下的性能优化与压测
- 生产级部署与监控
通过本课程，你将掌握如何用 PostgreSQL 构建一个稳定、高效、可扩展的支付中间件，从根本上解决分布式支付系统的重复处理和状态混乱问题。