分布式事务

1、两个阶段提交（2PC），具体如下图：

优点：尽量保证了数据的一致性，适合对数据强一致性要求很高的场景。

缺点：实现复杂，牺牲了可用性，对性能影响比较大，不适合高并发性能的场景

第一个阶段：事务协调器要求每一个涉及到事务的数据库预提交此操作，并返回是否可以提交。

第二个阶段：事务协调器要求每个数据库进行提交。

其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。这样做的缺陷是什么呢? 咋看之下我们可以在数据库分区之间获得一致性。

如果CAP 定理是对的，那么它一定会影响到可用性。

如果说系统的可用性代表的是执行某项操作相关所有组件的可用性的和。那么在两阶段提交的过程中，可用性就代表了涉及到的每一个数据库中可用性的和。我们假设两阶段提交的过程中每一个数据库都具有99.9%的可用性，那么如果两阶段提交涉及到两个数据库，这个结果就是99.8%。根据系统可用性计算公式，假设每个月43200分钟，99.9%的可用性就是43157分钟, 99.8%的可用性就是43114分钟，相当于每个月的宕机时间增加了43分钟。

以上，可以验证出来，CAP定理从理论上来讲是正确的，CAP我们先看到这里，等会再接着说。

2、补偿式事务(TCC)

针对每一个操作，都要注册一个与其对应的确认和补偿（撤销）操作，整个过程分为三个阶段：

（1）Try 阶段主要是对系统做检测及资源的预留

（2）Confirm阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认Confirm阶段是不会出错的。即只要Try成功执行，Confirm一定成功。

（3）Cancel阶段主要是业务执行错误，需要回滚的状态下执行业务取消，预留资源释放。

举一个例子：Bob转账给Smith,本地方法依次调用的是：1、在Try阶段要先调用远程的接口把Smith和Bob的钱进行冻结。2、在Confirm阶段，执行远程调用的转账操作，转账成功进行解冻。3、如果在第二步执行成功，那么转账成功，如果执行失败，则调用远程冻结接口对应的解冻接口。

优点：跟2PC相比较，实现以及流程相对简单一点，但数据库的一致性比2PC要差一些。

缺点：缺点还是比较明显的，在2、3步都可能失败,TCC属于应用层的一种补偿方式，需要在实现时多写一些补偿代码。在某些场景中不太好处理补偿的定义及处理方式。

3、本地消息表

此方法是业界使用最多的，其实质是将分布式事务拆分成本地事务进行处理。

基本思路：

消息的生产方（A）需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交。也就是说他们要在一个数据库里，然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。

消息的消费方（B）需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行事务回滚。

生产方和消费方定时扫描本地消息表，把没有发送的消息进行再次发送。如果有靠谱的自动对账补偿逻辑，这种方案是非常实用的。这种方案遵循了BASE理论，采用的是最终一致性。

优点：一种非常经典的实现，避免了分布式事务，实现了最终的一致性

缺点：消息表会耦合到业务当中去，如果没有进行良好的封装，会有很多杂活要去做。

CAP定理：一致性：客户端知道一系列的操作都会同时发生。可用性：每一个操作都必须以可预期的响应结束，分区容错性：即使出现单个组件无法使用，操作依然可以完成。

BASE定理：基本可用，软状态，最终一致性，BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

详见：http://www.roncoo.com/article/detail/127500