面试题三 分布式事务方案_面试官问分布式事务在你的项目里是怎么用的

一、两阶段提交

1、介绍：

有一个事务管理器的概念，负责协调多个数据库的事务，事务管理器先问各个数据库是否可以存储数据，如果都可以，那就正式提交事务，否则就回滚事务

2、缺点：

严重依赖数据库层面来搞定事务，效率很低，绝对不适合高并发的场景。在实际的分布式系统中，基本不可能使用。因为分布式服务中的每个服务按规定只能访问自己的库，所以没法使用两阶段提交

二、三阶段提交

第一步先判断数据库等资源是否可用，第二步发起业务，并返回给事务管理器是否可以提交，第三步提交或回滚事务。第二步和第三步跟两阶段一样，缺点也跟两阶段一样，commit的时候如果第一个库commit成功了，第二个库commit失败了，那也是无解的

三、TCC方案

1、介绍：

用业务代码实现分布式事务，TCC全称try、confirm、cancel

1）try阶段：对各个服务的资源做检测和锁定

2）confirm阶段：在各个服务中执行实际的操作

3）cancel阶段：如果confirm阶段中任何一个服务的方法报错，需要进行补偿，将已经执行成功的业务逻辑进行回滚

2、缺点：

每个业务逻辑不同，回滚方案也不同，都要手写，所以工作量大，维护也复杂

3、适用场景：

非常核心的业务，比如钱相关的，要严格保证数据准确

四、本地消息表

1、介绍：

使用操作记录表来记录操作状态，通过操作状态来判断操作是否完成，并有补偿机制的线程，定时处理执行失败的任务

2、举例：

把银行卡里的钱转到余额宝，可能出现银行卡里钱扣了，但余额宝里钱没有增加，并且支付宝里的记录显示等待对方扣款

1）转账系统记录操作，状态为等待对方扣款，随后发送消息给MQ

2）扣款系统消费MQ中的消息，记录操作，状态为等待银行扣款，调用银行接口扣款，如果调用成功，更改状态为扣款成功，如果调用失败，更改状态为扣款失败。随后再发送结果消息给MQ

3）转账系统消费到结果消息后，加上金额，并更改第一步的状态为交易成功，随后返回success给MQ

4）如果转账系统没有消费到结果消息，那么状态就一直是等待对方扣款，这个时候可以每天定时查询这个操作日志库，找到等待对方扣款状态的记录，然后询问别的系统该任务是否执行完成

3、优点

相比TCC方案而言，业务代码简单很多，易于维护

4、缺点

消息表依赖关系型数据库，而关系型数据库扩展有限，遇到高并发场景时会有性能问题

五、可靠消息最终一致性方案

1、介绍：

和上一个方案比较像，区别在于不使用数据库，而是使用MQ。比如阿里基于rocketmq来实现

1）系统A发送prepared消息给MQ，发送成功后执行本地事务

2）如果执行成功，发送confirm消息给MQ，然后MQ让系统B消费到这条消息

3）如果执行失败，发送cacel消息给MQ

4）MQ定时轮询所有prepared消息来回调系统A，询问系统A，是执行成功了但confirm消息没发成功，还是失败了cacel消息没发成功，那么是要继续重试还是回滚。系统A就判断任务是否执行成功，如果失败了，那就回滚吧，如果成功了，就发送confirm消息

5）如果系统B失败了，要么就不断重试直到成功，要么就想办法通知系统A也回滚，也可以发送报警信息之类的

2、和本地消息表的区别

使用MQ替代了本地消息表，不需要业务自己存消息，也不需要来轮询消息表，更加简便