分布式事务解决方案学习整理

接触了分布式以及微服务，就需要了解一下分布式事物的一些常用的解决方案，以及各自的优缺点。方便遇到问题的时候找到一些性能的瓶颈以及解决实际问题的思路。

1. 基于XA协议的两阶段提交（2PC）

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



两阶段提交的方案优点：

XA协议比较简单，大多数商业数据库实现了该接口，成本较低

两阶段提交的方案缺点：

两阶段提交中的第二阶段，协调者需要等待所有参与者发出yes请求或者其中一个发出no请求后，才能执行提交或者中断操作，这会造成长时间同时锁住多个资源，造成性能瓶颈，如果参与者有一个耗时长的操作性能损耗会更明显

实现复杂，不利于系统扩展

2. 基于消息中间件的最终一致（使用消息队列来避免分布式事务）

所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊使用，它将本地事务和发送消息放在了一个分布式事务，保证要么本地操作成功并且对外发送消息成功，要么两者都是失败。

举一个比较容易理解的例子：

我们去饭店点饭，付钱之后前台不会立马给你一份饭，而是给你一张小票，凭着小票就可以领取一份你点过的饭。也就是收钱跟做饭的事务通过一个小票来避免，小票就相当于消息中间件。

优点：消息数据独立存储，降低业务系统与消息系统间的耦合；

缺点：一次消息发送需要两次请求；业务处理服务需要实现消息状态回查接口

3. TCC编程模式

所谓TCC编程模式，也是两个阶段提交的一个变种，TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、confirm、cancel三个操作。

以客户购买商品的付款操作为例可以理解一下TCC编程模式。

1.try

完成所有的业务检查（一致性），预留必须业务资源（准隔离性）

体现在本例中就是确认客户的账户余额足够支付（一致性），锁住客户账户以及商户账户（准隔离性）

2.confirm

使用try阶段预留的业务资源执行业务（业务操作必须是幂等的），如果执行出现异常，要进行重试

体现在本例中就是执行客户扣款、商户入账的操作

优点：

对各个字段分别锁定，各自执行，能提高性能

缺点：

侵入性太强

3.cancel

释放try阶段预留的业务资源，这里就是释放客户与商户的账户锁，如果任一子业务在confirm阶段操作无法执行成功，会造成业务活动管理器的响应超时，此时要对其他业务执行补偿性事务，如果补偿操作执行也出现了异常，必须进行重试，若无法执行，则需要事务管理器感知到失败操作，进行log，由人工补偿或者其他方式补偿