3. 状态机设计模式：有限状态机(FSM)概念、状态转移表与事件驱动模型

在支付订单幂等校验与中间件调度场景中，业务逻辑往往呈现“状态-事件-转移”的闭环特征。有限状态机（Finite State Machine, FSM）正是描述这类行为最精确的数学模型。本章从概念、表格化建模到事件驱动实现，逐层拆解 FSM 在支付中间件中的落地方式。

3.1 有限状态机核心概念

有限状态机由以下四要素构成：

• 状态（State）：系统在某一时刻所处的稳定情形，数量有限且可枚举。
• 事件（Event）：触发状态转移的外部输入或内部信号。
• 转移（Transition）：在特定事件下，从当前状态迁移到下一状态的动作。
• 动作（Action）：转移发生时执行的副作用，如写日志、发消息、更新数据库。

3.2 状态转移表：支付订单的完整生命周期

以一笔标准电商支付订单为例，其核心状态包括：待支付、支付中、已支付、已退款、已关闭。下表完整定义了各状态在收到不同事件时的转移规则：

3.3 事件驱动模型与 FSM 引擎架构

在 PostgreSQL 中间件中，FSM 引擎通常采用事件驱动架构。外部请求（HTTP 回调、MQ 消息、定时器）统一封装为事件对象，由调度器分发至对应的状态机实例。下图展示了支付订单状态机引擎的核心组件与数据流：

3.4 状态转移表到代码的映射

在 PostgreSQL 中间件中，状态转移表通常以配置化方式存储于数据库或配置中心。以下示例展示如何用 JSON 描述一张状态转移表，并在运行时由 FSM 引擎加载：

-- 状态转移配置表（示例）
CREATE TABLE fsm_transition (
    id          SERIAL PRIMARY KEY,
    state_from  VARCHAR(32) NOT NULL,   -- 当前状态
    event       VARCHAR(64) NOT NULL,   -- 事件名称
    state_to    VARCHAR(32) NOT NULL,   -- 下一状态
    action_bean VARCHAR(128),           -- Spring Bean 名称，执行动作
    UNIQUE (state_from, event)
);

-- 插入支付订单核心转移规则
INSERT INTO fsm_transition VALUES
(1, '待支付',   '发起支付',     '支付中',   'lockOrderAction'),
(2, '支付中',   '支付成功回调', '已支付',   'confirmPayAction'),
(3, '支付中',   '支付失败回调', '待支付',   'releaseLockAction'),
(4, '支付中',   '超时未回调',   '已关闭',   'closeOrderAction'),
(5, '已支付',   '申请退款',     '已退款',   'refundAction'),
(6, '已支付',   '重复支付回调', '已支付',   'idempotentIgnoreAction'),
(7, '待支付',   '用户取消',     '已关闭',   'cancelOrderAction');

3.5 事件驱动模型在幂等校验中的角色

事件驱动模型与 FSM 的结合，天然解决了支付幂等校验中的两个核心难题：

1. 重复事件去重：事件队列本身支持幂等消费（如 Kafka 的幂等生产者、Redis Stream 的消费者组），结合状态机当前状态，可快速判断事件是否已被处理。
2. 乱序事件处理：状态机只接受符合当前状态的事件。例如，订单处于“已支付”时，再次收到“支付成功回调”会被状态机判定为非法转移，直接触发幂等忽略逻辑，不会导致重复入账。

下图展示了事件驱动 FSM 处理重复支付回调的完整时序：

3.6 状态机设计的最佳实践

• 状态枚举化：所有状态定义在统一的枚举类中，避免字符串散落各处。
• 转移原子化：状态更新与动作执行必须在同一数据库事务中完成，防止状态与数据不一致。
• 终态不可逆：已关闭、已退款等终态必须拒绝所有事件，这是幂等安全的最后防线。
• 事件溯源：记录每次状态转移的完整流水（谁、什么时间、什么事件、从哪到哪），便于对账与问题排查。
• 并发控制：使用乐观锁（版本号）或悲观锁（SELECT FOR UPDATE）保护状态更新，避免并发请求导致状态错乱。