分布式事务二阶段提交的处理方案

• 分布式事务的应用场景

支付

最经典的场景就是支付了，一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些操作必须在一个事务里执行，要么全部成功，要么全部失败。而对于买家账户属于买家中心，对应的是买家数据库，而卖家账户属于卖家中心，对应的是卖家数据库，对不同数据库的操作必然需要引入分布式事务。

在线下单

买家在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态，库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。

 XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。

• 一、两阶段提交。

      第一阶段，所有事务参与者将执行结果的成功与否反馈给事务协调者，但是不提交。

      第二阶段，事务协调者根据返回的结果，决定是全部提交，还是全部不提交。

      该方案可以保证事务的4个特性ACID。

          A原子性，一个事务内的操作要么全部成功，要么全部失败。

          C一致性，事务提交后，数据必须满足完整性约束。

          I隔离性，事务间的操作是独立的，互不影响。

          D持久性，事务提交后，数据永久生效。

      该方案不足之处，可能子事务B在执行时，要访问还未提交事务的子事务A锁定的资源，导致锁等待，吞吐量会遇到瓶颈，导致性能不高。

•    二、TCC

         TCC是两阶段提交的一个变种，在事务的ACID和性能间找到一个平衡点，部分牺牲一致性和隔离性，保证事务最终的一致性。

        T，也就是Try，它会执行完所有的操作，并提交（准确说是临时提交），不会导致锁等待。

        C，也就是Confirm，如果Try操作全部成功，则所有操作Commit。

        C，也就是Cancel，如果Try操作没有全部成功，则所有操作Rollback。

     

• 三 、基于消息中间件的两阶段提交

往往用在高并发场景下，将一个分布式事务拆成一个消息事务（A系统的本地操作+发消息）+B系统的本地操作，其中B系统的操作由消息驱动，只要消息事务成功，那么A操作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地操作，如果本地操作失败，消息会重投，直到B操作成功，这样就变相地实现了A与B的分布式事务。原理如下：

 

虽然上面的方案能够完成A和B的操作，但是A和B并不是严格一致的，而是最终一致的，我们在这里牺牲了一致性，换来了性能的大幅度提升。当然，这种玩法也是有风险的，如果B一直执行不成功，那么一致性会被破坏，具体要不要玩，还是得看业务能够承担多少风险。