分布式事务实现的3种方案

分布式事务实现的三种方案

面试前言：

面试中常常被问到你知道怎么实现分布事务吗？

或者你知道实现分布事务的方式有哪几种方案？

分布式事务实现的几种方案如下：

​ 1.基于mq实现分布事务

​ 2.基于XA协议实现分布式事务

​ 3.基于TCC协议机制实现分布式事务

1.基于mq实现分布事务

数据库设计：

原文连接：https://blog.csdn.net/luoyang_java/article/details/84953241

数据库设计：

设计支付宝和余额宝两个应用的数据库两张表一样。

-- 账户表
CREATE TABLE `t_message` (
  `id` int(11) NOT NULL,
  `queueName` varchar(64) DEFAULT NULL,
  `message` varchar(255) DEFAULT NULL,
  `status` varchar(32) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
-- 消息表
CREATE TABLE `t_message` (
  `id` int(11) NOT NULL,
  `queueName` varchar(64) DEFAULT NULL,
  `message` varchar(255) DEFAULT NULL,
  `status` varchar(32) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

如图是分布式架构图：

举个例子支付宝和余额宝转账是一个分布式事务。

使用springboot+springcloud搭建支付宝和余额宝的架构图

分布式业务执行流程简单描述：

1、支付宝扣款成功时往message表插入消息

2、message表有message_id(流水id，标识夸系统的一次转账操作),status（confirm，unconfirm）

3、timer扫描message表的unconfirm状态记录往activemq插入消息

4、余额宝收到消息消费消息时先查询message表如果有记录就不处理如果没记录就进行数据库增款操作

5、如果余额宝数据库操作成功往余额宝message表插入消息，表字段跟支付宝message一致

6、如果5操作成功，回调支付宝接口修改message表状态，把unconfirm状态转换成confirm状态

问题描述：

1、支付宝设计message表的目的

如果支付宝往activemq插入消息而余额宝消费消息异常，有可能是消费消息成功而事务操作异常，有可能是网络异常等等不确定因素。如果出现异常而activemq收到了确认消息的信号，这时候activemq中的消息是删除了的，消息丢失了。设置message表就是有一个消息存根，activemq中消息丢失了message表中的消息还在。解决了activemq消息丢失问题；

2、余额宝设计message表的目的

当余额宝消费成功并且数据库操作成功时，回调支付宝的消息确认接口，如果回调接口时出现异常导致支付宝状态修改失败还是unconfirm状态，这时候还会被timer扫描到，又会往activemq插入消息，又会被余额宝消费一边，但是这条消息已经消费成功了的只是回调失败而已，所以就需要有一个这样的message表，当余额宝消费时先插入message表，

如果message根据message_id能查询到记录就说明之前这条消息被消费过就不再消费只需要回调成功即可，

如果查询不到消息就消费这条消息继续数据库操作，数据库操作成功就往message表插入消息。 这样就解决了消息重复消费问题，这也是消费端的幂等操作。

总结：

message表主要解决的问题：

1.消息丢失问题

2.消息重复消费问题

2.基于XA协议实现分布式事务

原文链接：https://blog.csdn.net/luoyang_java/article/details/84953241

<dependency>
    <groupId>com.tomzgroupId>
    <artifactId>xatomicartifactId>
    <version>1.0.0version>
dependency>

​ XA协议是数据库支持的一种协议，其核心是一个事务管理器用来统一管理两个分布式数据库，如图

理论总结：

​ 事务管理器负责跟支付宝数据库和余额宝数据库打交道，一旦有一个数据库连接失败，另一个数据库的操作就不会进行，一个数据库操作失败就会导致另一个数据库回滚，只有他们全部成功两个数据库的事务才会提交。

基于XA协议的两段和三段提交是一种严格的安全确认机制，其安全性是非常高的，但是保证安全性的前提是牺牲了性能，这个就是分布式系统里面的CAP理论，做任何架构的前提需要有取舍。所以基于XA协议的分布式事务并发性不高，不适合高并发场景。

理论总结2

XA实现分布事务是基于XA的事务管理器来完成分布在不同应用连接的数据库。使用TransactionManger管理器JtaTransactionManger管理器分布式事务的管理。

场景描述

事务管理器负责跟支付宝数据库和余额宝数据库打交道，一旦有一个数据库连接失败，另一个数据库的操作就不会进行，一个数据库操作失败就会导致另一个数据库回滚，只有他们全部成功两个数据库的事务才会提交

事务流程

每次操作一次数据库都会开启 start XA xid ,end XA xid; 开启事务预提交处理prepare，当prepare返回ok表示两个事务预提成功，再做commit事务提交；都会做xa协议的发送。

优点：

数据是很安全，适用与对数据安全性很高的系统，适用并发量不高的系统，可以采用XA协议来做系统分布式事务。

缺点：

对数据有强一致性的校验，有两次握手，导致系统处理速度很慢，吞吐量不高，并发量不高。

3.基于TCC协议机制实现分布式事务

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应 的确认和补偿（撤销）操作。

它分为三个阶段：

1、Try 阶段主要是对业务系统做检测及资源预留

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

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

总结优缺点：

优点：相比两阶段提交，可以用性较强，

缺点：数据一致性要差一些，实现复杂高，需要些很多补充机制代码来实现，

而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。

优缺点：

优点：相比两阶段提交，可以用性较强，

缺点：数据一致性要差一些，实现复杂高，需要些很多补充机制代码来实现，

而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。

视频解说分布式事务实现的3种方案