Q45: 如何设计交易系统？

核心结论

交易系统不是“双方各放点东西然后点确认”，而是一条高风险资产交换链路。

真正需要优先解决的是：

交易双方状态是否稳定
交易物和货币是否被锁定
任一步骤中断时如何回滚或取消
最终提交是否原子

如果这些边界不清晰，复制漏洞、掉线漏洞和脚本重试问题都会集中爆发。

一、先明确交易类型

常见交易至少有两类：

面对面实时交易
异步市场或拍卖交易

这两类虽然都叫交易，但系统结构差别很大。

q45 更适合聚焦在玩家之间的直接交易。

二、面对面交易的核心流程

一条更稳妥的交易链通常包含：

发起请求
对方接受
双方进入交易态
放入物品或货币
锁定内容
双方确认
原子提交或统一取消

看起来简单，但每一步都需要状态约束。

三、为什么“锁定”很关键

交易中的物品和货币如果不先锁定，就会出现典型问题：

放进交易栏后又被使用
放进交易栏后又被邮件或出售
一边确认一边继续改内容

所以交易系统通常要在提交前把参与资产进入受限状态。

四、最终提交必须是原子交换

交易一旦进入最终确认，结果应该只有两种：

双方交换全部成功
双方都不变

不能出现：

A 扣了物品，B 没收到
A 收到钱，B 没拿到货

这是交易系统最基本的正确性要求。

五、取消和异常中断同样要设计

真实线上环境里，异常比正常提交更常见。

例如：

一方掉线
一方超时不确认
一方背包空间变化
服务重启或节点切换

这些场景都需要有明确规则：

自动取消
解锁资产
还原临时状态

六、交易系统要和背包、货币系统强协同

交易不是孤立系统，它至少依赖：

背包锁定和容量检查
货币扣减与增加
绑定物品校验
黑名单、等级、地图限制等规则

所以交易系统更像是“交易状态机加资产提交协调器”。

七、防欺诈和防复制是重中之重

常见风险包括：

重复点击确认
断线重连重复提交
交易中篡改数量
利用回滚窗口复制资产

更稳妥的做法通常是：

服务端权威维护交易状态
最终提交带幂等保护
交易过程有完整审计日志

八、工程上更稳妥的设计

常见做法是：

建立交易会话对象
双方资产进入锁定态
变更内容后清空确认状态
最终提交走单次原子交换
成功和失败都写流水

这样更容易防止状态穿透和重复提交。

九、常见误区

1. 双方都点了确认就够了

不够。确认之后还需要原子提交和异常恢复。

2. 客户端交易栏状态就是最终真相

不对。客户端只能展示，会话状态必须由服务端权威维护。

3. 交易系统只要防外挂

很多事故来自断线、重试、时序和内部 bug，而不只是外挂。

参考资料

各类在线游戏 P2P 交易、资产锁定与防复制实践资料