互联网中的分布式事务解决方案

第1种解决方案：业务接口整合，避免分布式事务此方案是将一个业务流程中需要在一个事务里执行的多个相关业务接口包装整合到一个事务中，这属于“就具体问题具体分析”的做法。就问题场景来说，可以将服务A、B、C整合为一个服务D来实现单一事务的业务流程服务。如果在项目一开始就考虑到分布式事务的复杂问题，则采用这里的方案，精心规划和设计系统，避免分布式事务；对于实在不能避免的，则采用其他措施去解决，这应该是最好的做法。

第2种解决方案：最终一致性方案之eBay模式这是eBay于2008年公布的关于BASE准则的论文中提到的一个分布式事务解决方案，在业界影响比较大。eBay的方案其实是一个最终一致性方案，主要采用了消息队列来辅助实现事务控制流程，其核心是将需要分布式处理的任务通过消息队列的方式来异步执行。如果事务失败，则可以发起人工重试的纠正流程。人工重试被更多地应用于支付场景中，通过对账系统对事后的问题进行处理。在该论文中描述了一个很常见的支付交易场景：如果某个用户（user）产生了一笔交易，则需要在交易表（transaction）中增加记录，同时修改用户表的金额（余额），由于这两个表属于不同的远程服务，所以涉及分布式事务与数据一致性的问题。

初看这个方案并没有什么问题，但实际上还没有解决分布式问题。为了使第1个事务不涉及分布式操作，消息队列必须与transaction表使用同一套存储资源。但为了使第2个事务也是本地的，消息队列存储又必须与user表在一起。这两者是不可能同时满足的，我们假设消息队列与transaction表使用同一套存储资源，则后面从消息队列消费消息的逻辑来看可能会产生不一致的错误：数据库已经更新了user的余额信息，但接下来从消息队列中删除消息时发生异常，比如进程死机或者消息服务突发故障，则此消息还在系统中，下次又会被投递，产生了消息被重复投递的问题。除非此消息的处理逻辑具有幂等性，可以重复触发，否则重复投递消息就会引发事故

第3种方案：X/OpenDTP模型的支付宝的DTS框架DTS（Distributed Transaction Service）框架是由支付宝在X/OpenDTP模型的基础上改进（模仿）的一个设计，定义了类似于2PC的标准两阶段接口，业务系统只需要实现对应的接口就可以使用DTS的事务功能。DTS从架构上分为xts-client和xts-server两部分，前者是一个嵌入客户端应用的JAR文件，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。DTS最大的特点是放宽了数据库的强一致约束，保证了数据的最终一致性（Eventually Consistent）。