一、what

        分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

二、CAP原理

        C-consistency一致性，A-availability可用性,P-partition tolerance分区容错性。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

        因为分布式系统中系统肯定部署在多台机器上，无法保证网络做到100%的可靠，所以网络分区一定存在，即P一定存在；就出现了可用性和一致性的问题，我们必须要在这两者之间进行取舍，因此就有了两种架构：CP架构，AP架构。

三、相关协议

        解决分布式事务，也有相应的规范和协议。分布式事务相关的协议有2PC、3PC。由于三阶段提交协议3PC非常难实现，目前市面主流的分布式事务解决方案都是2PC协议。

1.2PC两阶段提交协议(Two-Phase Commit)

        第一阶段：所有事务参与者，执行后进行预提交；直到协调者收到所有参与者的预提交才会进入第二步；

        第二阶段：所有事务预提交了各自的结果后，由协调者决定最终事务是成功(commit)还是失败(rollback)。

        问题

        1) 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。

        2) 可靠性问题：如果协调者存在单点故障问题，或出现故障，提供者将一直处于锁定状态。

        3) 数据一致性问题：在阶段 2 中，如果出现协调者和参与者都挂了的情况，有可能导致数据不一致。

        优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）。

        缺点：牺牲了可用性，对性能影响较大，不大适合高并发高性能场景。

2.3PC三阶段提交协议(Three-Phase Commit)

        与两阶段提交不同的是，三阶段提交是“非阻塞”协议。三阶段提交在两阶段提交的第一阶段与第二阶段之间插入了一个准备阶段，使得原先在两阶段提交中，参与者在投票之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。

四、两阶段提交的四种模式

1.AT模式   

          AT 模式是一种无侵入的分布式事务解决方案(阿里seata框架，实现了该模式)。

          在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

          在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在seata自己的一个数据库事务内完成，这样保证了一阶段操作的原子性。

          二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

          二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

2.TCC 模式     

          TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。   

          Try：资源的检测和预留；

          Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功；

          Cancel：预留资源释放；

3.saga模式

          分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

          Saga 正向服务与补偿服务也需要业务开发者实现。因此是业务入侵的。

          Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。

优势：

          一阶段提交本地数据库事务，无锁，高性能；

          参与者可以采用事务驱动异步执行，高吞吐；

          补偿服务即正向服务的“反向”，易于理解，易于实现；

缺点：

          Saga 模式由于一阶段已经提交本地数据库事务，且没有进行“预留”动作，所以不能保证隔离性。

4.XA模式

         XA被许多数据库（如Oracle、DB2、SQL Server、MySQL）和中间件等工具(如CICS 和 Tuxedo)本地支持 。JTA(Java Transaction API) 是Java实现的XA规范的增强版 接口。

         在XA模式下，需要有一个[全局]协调器，每一个数据库事务完成后，进行第一阶段预提交，并通知协调器，把结果给协调器。协调器等所有分支事务操作完成、都预提交后，进行第二步；第二步：协调器通知每个数据库进行逐个commit/rollback。

5.每种模式都有它的适用场景

    AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，几乎0学习成本。

    TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。

    Saga 模式是长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。

    XA模式是分布式强一致性的解决方案，但性能低而使用较少。

五、解决方案

1.强一致性：

          seata 阿里分布式事务框架(支持AT 、TCC、Saga 、XA)

2.最终一致性：

a.本地消息表：

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

缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

b.MQ消息事务

有一些第三方的MQ是支持事务消息的，比如RocketMQ，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。

执行流程：

1.发送prepare消息到消息中间件

2.发送成功后，执行本地事务

3.如果事务执行成功，则commit，消息中间件将消息下发至消费端

4.如果事务执行失败，则回滚，消息中间件将这条prepare消息删除

5.如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

6.消费端接收到消息进行消费，如果消费失败，则不断重试。

这种方案也是实现了最终一致性，对比本地消息表实现方案，不需要再建消息表，不再依赖本地数据库事务了，所以这种方案更适用于高并发的场景。

c.最大努力通知

          最大努力通知相比前两种方案实现简单，适用于一些最终一致性要求较低的业务，比如支付通知，短信通知这种业务。

       以支付通知为例，业务系统调用支付平台进行支付，支付平台进行支付，进行操作支付之后支付平台会尽量去通知业务系统支付操作是否成功，但是会有一个最大通知次数，如果超过这个次数后还是通知失败，就不再通知，业务系统自行调用支付平台提供一个查询接口，供业务系统进行查询支付操作是否成功。