转账交易这件小事，是如何被程序员玩坏的？

很久很久以前。应用APP只有一个，功能都写在一起。数据库也只有一个，所有的数据一致性问题也可以通过事务解决。转账交易当然是小菜一碟：

try{
    transaction.begin();
    
    db.execute(A-1000);
    db.execute(B+1000);
    
    transaction.commit();
}catch(Exception e){
    transaction.rollback();
}

转账-单机.png

后来随着应用的复杂，需要拆分出多个领域单独部署应用和数据库。比如A账户属于借记卡领域，而B账户属于信用卡领域。我们可以用分布式事务，也可以用补偿机制：

转账-多机多库 .png

NOTE：基于两阶段提交的分布式事务并不能100%保证一致性（比如在第二阶段数据库发生当机）。基于补偿的最终一致性方案，也有需要人工介入的情况。

上面的方案并不完善，没有把考虑网络问题考虑进来。在跨公司远程访问中，网络问题会比较突出和频繁。

转账-远程交互.png

在复杂的网络情况下。除了成功和失败，可能遇到没有响应或超时的情况，这种情况下对方可能收到的请求也可能没收到请求。可能处理了，也可能没处理。如果重试一定次数后始终调用不成功，就需要人工介入。

转账-远程同步.png

我们首先需要引入一张交易事务流水表，来记录账户每次的变更情况和状态。账户数据只保存最新的状态。考虑到可能存在的重复提交，在被调用方也需要流水表，来实现实现“幂等性”。

其次考虑到转账可能失败，我们加入一个冻结资产的概念F，使得用户可以明确看到这部分资金

当然交易可能是异步的，接收方可能需要做一些别的处理才返回

转账-远程异步.png

可以接收方推送通知，也可以调用方查询结果，或者两者结合。

最后，这些unknow状态的订单怎么办呢？解决方案叫“对账”。一种是双方协商着对账解决分歧。更多的是以一方的数据为准，通过查询或倒文件的方式对账。