很久很久以前。应用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
