支付订单的生命周期是一台状态机:创建、支付中、已支付、已发货、已关闭,每个状态有明确的流转条件与超时规则。订单状态机的存储设计决定支付故障的排查效率与资损的防控精度。
---订单的状态流转
local ORDER_STATE = { created = 1, paying = 2, paid = 3, delivered = 4, closed = 5 }
function OrderLog.transit(orderId, newState)
local order = orderIndex[orderId]
local old = order.state
order.state = newState
QF_AppendOrderLog(orderId, old, newState, os.time())
if newState == ORDER_STATE.delivered then
OrderLog.markSettled(orderId)
end
end
状态机的每次流转写前后状态与时间戳,订单的生命周期按日志完整回放。状态流转的合法性校验:不允许从已关闭跳回支付中,非法的流转直接拒绝并告警。订单的超时规则:支付中超过 30 分钟自动关闭,关闭后的延迟到账走补单流程。
---延迟到账的补单流程
function OrderLog.recover(orders)
local recovered = 0
for _, o in ipairs(orders) do
if o.state == ORDER_STATE.paid and o.paidAt < os.time() - 1800 then
OrderDeliver.run(o)
recovered = recovered + 1
end
end
return recovered
end
补单的扫描每 5 分钟执行一次:支付成功但未发货的订单自动补发货,补发的动作与原发货同源。补发的记录与原订单关联,同一订单的多次补发被幂等标记拦截。订单的日志与支付平台的流水每日对账,差异订单在 24 小时内清结。
订单状态分布的快照监控,卡在中间状态的订单数量突增即为支付通道的异常信号。
状态机的并发流转曾经出现双向写入,同一订单被两个回调同时处理,状态流转的互斥锁补上。补单的幂等曾经依赖订单号的唯一性,平台重发不同单号的同一笔支付让幂等失效,平台的交易号纳入幂等键。
订单的状态与资损的关联监控:卡在已支付未发货的订单数量是资损风险的先行指标。对账的差异处理时限 24 小时,超时的差异升级到财务的专项。订单日志的保留期五年,支付类的纠纷追溯周期最长。
本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付,内容以官方知识库与真实项目为出处,按版本持续修订。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
实战应用:用在哪里 沙巴克开战前600秒,行会会长一键集结,全会在线成员无论在哪张图都收到带坐标的集结消息,点击直达集合点。…
实战应用:用在哪里 远征副本上线前夜,压测编排把“上线会不会崩”变成一场有脚本的预演:模拟满员远征、三选一齐选、奖励齐领三个…
实战应用:用在哪里 结义合击玩法上线三天,客服收到“攻击加成叠了三层”的报告:同一次合击,三个入口各挂了一次加成Buff。复…
实战应用:用在哪里 “强化石×3”值不值得跑一趟毒蛇山谷,玩家心里没数。任务接取页的奖励预览把物品换算成战力参考值:每件物品…
实战应用:用在哪里 “转生怎么升”“红名怎么洗”这类问题八成答案都在帮助中心,玩家却习惯直接问客服。自助查询把帮助条目做成关…
实战应用:用在哪里 烈火剑法的打击节奏由前摇与后摇决定:前摇太长玩家觉得迟钝,后摇太短连招没有张力。节奏调优把前后摇参数化:…