交易系统之”缓存交易”

1、在遇到需要在两个不同系统间交易时， 做管理系统的人， 往往会想到联系到生活中银行系统间的交易。 比如100金额从就建行账号A转到中行账号B， 大体想象出的交易过程是这样，建行向中行发起账号A到账号B 转100的申请，双方同意了， 就进行扣除账号A 100， 加账号B 100 的操作， 双方应该有日志记录这一条操作； 底下可能有更复杂的验证交易可信的过程，我们这一般外行就不多推测了。

 

 2、IT上， 接触过两个或以上不同系统间通信的都清楚， 单个系统内部（内网）的交易操作是非常容易的， 多个不同（不同开发商不同网段）系统时要保证事务性就复杂很多。

建立握手和信任机制之后，一次带反馈的A系统向B 交易流程大概是： A ---->B---->A， 涉及3个过程： 步骤1：A 向 B 发起交易内容， 带上交易订单号； 步骤2：B收到来自步骤1通知，上款或扣款或失败，然后向A反馈本结果;  步骤3：A收到B反馈结果，扣款或上款或失败， 完成。

                               

 

外部网络比较出现问题， 就有时会发生短暂的网络中断， 上面的过程可能会被打断， 可能性2种， 1、在到步骤2的途中中断； 2、在到步骤3的途中中断，系统B扣款，系统B没有；

针对上面两种可能，比较严谨点的做法就是系统A 在间隔检查未完成订单，用这个老订单号从步骤1重新走流程直到完成

 

3、最近接触到了不同游戏平台间互玩游戏时，涉及到分值转帐，除了严谨程度不一和一些细节不同外，都是用类似这种模式。 这种模式需要平台间都支持，交易过程频繁。

   针对这种业务， 我设计出一种新模式（不清楚现实是否有人已经用过这种， 认知里是还没有的）。

   我把银行间交易业务称为永久性业务， 建行转到中行的钱是可以长久保存到中行的， 怎么处理是由中行决定的。

   而游戏平台间的交易没有永久性， A平台的玩家从A平台把分带到B平台玩了过后， 从B平台返回需要把玩剩的分返还给A平台。 感觉B平台是不是有种缓存分值的作用。根据这种特性，可以设计出一种更简单又安全的交易模式：

 

 

 

附加细节自定义

这种模式会让平台间交互少很多，通讯接口简单易实现， 而且可以让平台A 比较主动