操作记录是交易系统的「一致性锚点」。 它记录了「某次操作是否已经开始/完成」，是幂等控制、补偿重试、问题排查的核心依据。

一、操作记录的定位：为什么需要这个模型

在分布式交易系统中，一次业务操作（创单、支付、取消、退款等）往往需要：

  1. 更新本地订单状态
  2. 调用多个外部系统（库存、营销、支付等）
  3. 保证整个过程的幂等性和最终一致性

核心问题：如果操作执行到一半失败了，或者请求因超时被重试，系统如何知道「这次操作是否已经开始过」？

解决方案：引入「操作记录」模型，作为本地的一致性锚点。

1.1 操作记录的三个核心职责

操作记录核心职责.png

二、操作记录模型的设计

2.1 核心字段设计

操作记录表需要承载「幂等控制 + 状态追踪 + 业务溯源」三个职责：

字段类别 字段示例 设计意图
幂等键 source_id + modify_type 联合唯一索引，确保同一业务操作唯一
状态机 modify_status CREATED(1) → PROCESSING(2) → SUCCESS(3)/FAILED(4)
业务标识 order_id, user_id, biz_id 关联业务单据，支持按订单查询
操作类型 modify_type 创单、支付、取消、退款、改价、关单等
操作来源 source_type 用户、商家、系统、平台
业务快照 previous_data, target_data 操作前后的数据状态，用于审计
扩展信息 biz_extra_info, attributes 存储业务扩展字段、补偿标记等

2.2 操作类型（ModifyType）的设计

操作类型应该覆盖订单生命周期的所有关键节点：

操作类型 业务语义 典型场景
CREATE_ORDER 创建订单 用户提交订单
PAID_ORDER 订单支付成功 支付回调处理
CANCEL_ORDER 取消订单 支付前取消
REFUND_ORDER 发起退款 付款后退款申请
CLOSE_SKU_ORDER 关 SKU 单 退款完成后关单
TRADE_FINISH 交易完结 确认收货或超时完结
PRICE 改价 商家/客服修改价格
ADDRESS 改地址 修改收货地址

设计原则：操作类型的粒度应该与「业务上的关键事件」对齐，而不是与「技术实现步骤」对齐。