分布式事务的几种方式（原理）详解

1、分布式事务有哪些？

        1、XA方案（两阶段提交）

        2、TCC方案（三阶段提交）

        3、本地消息异步确认

        4、可靠消息最终一致性

        5、最大努力通知        

2、 他们的实现方式原理、优缺点是什么？

    1、XA方案（两阶段提交）

                XA方案又叫2PC，是X/OPEN组织定义的一种分布式事务处理标准，利用数据库（mysql、oracle等）对XA协议的支持而设计的一种分布式事务操作。

                 两阶段提交中有三个角色分别是TM（事务管理器）、RM（资源管理器）、TC（全局事务协调者）。

                  TM（事务管理器）：开始全局事务的角色，用来划定分布式事务的边界和范围

                  RM（资源管理器）：对数据库进行具体操作的角色

                  TC（全局事务协调者）：用于事务注册，全局事务提交，全局事务回滚

       1、实现流程：

             1、TM（事物管理器）向TC（全局事务协调者）进行事务注册，并开启全局事务；

             2、RM（资源管理器）向TC（全局事务协调者）进行分支事务注册，此时sql会进行暂存，不会立即提交；

             3、TM（事务管理器）向TC（全局事务协调者）下达全局事务提交，此时TC会将各个分支事务进行提交操作；

             4、如果有一个或多个分支事务提交失败，则TC会将所有的分支事务进行回滚操作，如果全部事务分支提交成功，则完成了分布式事务的提交

       2、实现原理：

             1、各个数据库例如：mysql、oracle、db等都实现了XA协议，我们只需要设计一个资源管理器，去实现各个数据库实现的XA协议。

             2、依次将所有操作进行提交，如果有失败的，则会根据sql去调用该数据库实现XA回滚的相关接口操作进行回滚操作。

       3、优缺点：

             优点：

                  1、属于强一致性，简单粗暴，实现简单

                  2、主流数据库都实现了XA协议

             缺点：

                  1、效率比较低，同步阻塞，本地事务在锁定资源后，其他事物只能等待

                  2、协议阻塞，资源管理器在收到commit或rollback前，必须阻塞等待，如果某一个RM分支事务“失联”，其他所有的分支事务都得进行等待

       4、使用场景：

             适合低并发，多数据源的系统，最好使用在单体项目中多数据的场景。

       5、实现方案：

             spring+JTA、阿里的seate、Atomiikos、Bitronix（btm）等，引入jar包进行配置即可使用

    2、TCC方案（三阶段提交）

                TCC方案又叫3PC，也叫TCC补偿方案。主要有三个角色，分别是try（尝试）、confirm（确认）、cancel（取消）；

               try（尝试）：尝试执行，对各个服务的资源做检测，并对资源进行预留或锁定；

               confirm（确认）：确认执行，真正的执行数据库操作；

               cancel（取消）：执行回滚操作

       1、实现方式：

                TCC方案中有一个TM（事务管理器），是对所有分支事务进行统一操作的，可以设计成一个单独的服务。TM在发起全局事务时会生成一个全局事务id，该id会贯穿整个分布式事务调用链条；

             1、开启全局事务，TM（事务管理器）生成一个全局事务id；

             2、TM会让所有的分支事务进行try操作，所有的分支事务进行资源检测和预留（隔离），如果有try操作失败的，则直接全部cancel；

             3、TM会让所有的分支事务进行confirm操作，所有的分支事务进行commit提交操作，如果有commit失败的，则TM会对该分支事务进行重试操作；

             4、如果重试次数超过了设置的次数，则TM会让全部分支事务进行回滚操作，回滚操作需要自己手动编写代码实现；

       2、优缺点：

             优点：严格保证了分布式事务，不是成功就是失败，比较严谨。适合在支付场景中使用；

             缺点：代码侵入性大，所有的回滚逻辑需要自己手写，改造成本很高，并且回滚逻辑很复杂，需要根据网络状态，故障状态来实现各种回滚策略，例如正常回滚，断网回滚等；

       3、应用场景：

             适合支付交易相关的场景。

       4、实现方案：

             实现方案有tcc-transaction、Bytetcc、EasyTransaction等，引入jar包进行配置即可使用。

    3、本地消息异步确认

           该方案是国外ebay的一种方案，主要借助一些消息中间件、数据库、注册中心（zookeeper）等，用第三方来进行整个事务状态的传递。

       1、实现方式:

             1、A系统首先在本地事务进行操作，操作失败则不需要开启事务，如果操作成功则往自己的数据库消息表中插入一条数据（或向zookeeper中注册一个节点），同时往mq中发送一条消息；发送的消息中必须有一个全局事务的唯一值，该值是为了保证该次事务的唯一性。

             2、B系统从mq中接收到A系统发送的消息后，也会往自己的数据库消息表中插入一条数据（或也向zookeeper中注册一个节点）；

             3、B系统进行业务操作，操作成功后将自己数据库消息表中的那个消息状态进行更新，表示完成B系统操作完成且成功，或将zookeeper中B系统注册的节点进行删除；

             4、B系统成功后会调用A系统，告知A系统，B系统已成功。A系统将自己的消息表状态进行更新（或删除zookeeper上A系统注册的节点）。此处通知A系统的方法有很多，例如调用A系统进行通知，使用mq通知A系统等

             5、如果B系统操作失败了，则进行本地回滚。但是B系统消息表中的消息不删除或zookeeper中的节点不删除。

             6、A系统会单独启一个线程用来检测A系统消息表中状态未更新的数据，设置一个超时时间，查找出超过这个时间的消息表中状态未更新状态的数据（或未删除的zookeeper节点），然后将这些超时数据在次向mq中发送消息，直到A系统的消息表数据状态变更。

             7、B系统接收到mq的消息后，首先会根据A系统传过来的唯一值去B系统数据库消息表中查询是否存在，如果存在说明B系统接收过条消息。然后去查看该条消息对于的业务是否成功，如果不成功则重新执行；注意：A系统传过来的唯一值是为了确保B系统对该条业务的幂等性操作。保证了该条消息不会重复执行B系统的业务

          2、优缺点：

                优点：分布式事务对业务的侵入很小，基本不会对业务添加更多的操作

                缺点：他不是实时一致性，而是保证最终一致性；并且比较依赖第三方，必须要保证mq、zookeeper的高可用性

          3、应用场景：

                基本所有项目都可以使用。

          4、实现方案：

                没有具体的实现方案，根据自己项目业务进行操作。

    4、可靠消息最终一致性

          该方案基于本地消息异步确认方案的升级和优化，该方案去掉了消息表，使用的是mq或可靠服务。所谓的可靠服务就是我们自己开发设计的一个不会出问题的服务，或者将可靠服务换成zookeeper、redis等比较稳定的服务。用途也是做全局事务状态的跟踪。

        1、实现方式：

               消息传递过程中都有一个全局唯一值，全局唯一值贯穿整个调用链路

             1、A系统操作数据前往可靠服务中方式一条数据，表示待确认状态，A系统完成业务操作后在往可靠服务中发送一条消息，将待确认状态改为已确认状态。A系统操作失败后删除掉可靠服务中的消息；

             2、可靠服务将已确认状态的数据发送给mq，mq将消息发送给B系统

             3、B系统接收到消息后，进行业务操作。如果成功了则对mq中的消息进行手动确认，并告知可靠系统操作成功。如果业务操作失败则进行业务回滚操作。

             4、可靠系统如果接收到了B系统告知的操作成功，则修改消息状态为已完成。A系统如果需要知道结果的话可以进行回调可靠系统或者监听可靠系统。

             5、可靠系统启一个定时任务，不断去查询那些消息状态为已确认的消息，超过了设置的超时时间的消息会再次发送到mq中，B系统会进行重新业务操作，直到可靠系统接收到B系统的成功操作并修改状态位置；

             注意：可靠系统表示的是不会出问题，即：可靠系统在保存、更新消息时不会报错并且也是高可用的。我们可以使用redis来保存全局唯一值和状态，因为快和安全。

        2、优缺点：

             优点：去掉了消息表，进行了解耦合，并且适合高并发场景。国内一般使用该方案做分布式事务。

             缺点：使用的中间件比较多，需要保证各个环节的集群高可用。

       3、应用场景：

             适合高并发的场景，一般公司都会选择该方案。

       4、实现方案：

              实现比较简单，没有具体的实现方案，根据自己项目业务进行操作。

    5、最大努力通知

                该方案一般支付宝、微信等支付平台的支付结果回调通知都是使用这种方案的。该方案和上面的最终一致性方案类似。区别在于使用的场景和业务不同而已。   

       1、实现方式：   

             1、A系统进行业务操作，操作成功后往mq中发送一条消息；

             2、有一个最大努力通知服务（相当于可靠服务）接收mq的消息，并将消息持久化保存，然后去调用B系统；

             3、B系统进行业务操作，如果操作成功，则返回操作成，最大努力通知服务接收到成功后删除持久化的消息，操作完成。

             4、如果B系统操作失败，最大努力通知会定时查询持久化的消息存储时间，如果超时了就再次调用B系统，直到B系统返回操作成功。

             注意：此处A系统不直接连接最大努力通知服务是为了解耦合。并且该操作可能会失败，所以叫最大努力通知。如果失败了那就需要人工干预了。

       2、优缺点：

             优点：解耦合，适合高并发。

             缺点：需要多个组件来保证服务的高可用性

       3、使用场景：

             一些操作完成后需要异步通知的业务场景

       4、实现方案：               

             实现比较简单，没有具体的实现方案，根据自己项目业务进行操作。