分布式事物

分布式事务问题也叫分布式数据一致性问题,简单来说就是如何再分布式环境下保持数据的一致性。分布式事务产生的核心原因在于存储资源的分布性，比如多个数据库，或者mysql和redis两种不同的存储设备的数据一致性等。

分布式事务模型

X/Open DTP分布式事务模型，是X/Open组织定义的一套分布式事务的标准，这个标准提出了使用两阶段提交也就是(2PC TWO please Commit)的方式来保证分布式事务的一致性。
DTP分为一下3个角色:

• AP: 应用程序
• RM: Resource Manager 资源管理器 ，如数据库等
• TM :Transaction Manager 事务管理器，一半指事务协调者，负责协调和事务管理，提供AP变
  成接口或者是RM。可以理解为Spring 当中的Transaction Manager
  如果此时RM表示数据库，那么TM需要管理多个数据库的事务。大致的步骤如下:

1. 配置TM，把多个RM注册到TM，相当于TM注册RM作为数据源。
2. AP从TM管理的RM中获取连接，如果RM是数据库则获取JDBC连接。
3. AP向TM发起一个事务请求，生成全局事务ID，XID会通知各个RM。
4. AP通过第二部获取的连接直接操作RM完成数据库操作。这是AP在每次成功操作时会把XID返回给RM。
5. AP结束全局事务，TM会通知各个RM全局事务结束。
6. 根据各个RM的事务执行结果，最终决定是提交还是回滚。

2PC两阶段提交协议如下(整体过程可以分为投票、执行2个阶段):

• 准备提交:事务管理器TM通知RM准备分支事务，记录事务日志，并告知事务管理器的准备结果
• 提交/回滚阶段: 如果所有的RM在准备阶段都明确返回成功，则 事务管理器向所有的RM发起提交指令。反之 事务管理器有一个返回失败，则发送事务回滚指令。
  优点: 2PC的事务提交管理方式 充分考虑到了分布式系统的不可靠因素，并且采用2PC的方式把因为系统不可靠导致事务提交的概率降低到了最小。
  缺点:

• 同步阻塞:在所有的RM都是事务阻塞性的，对于任何一次指令都需要有明确的回应才会执行下一步操作。否则都会处于阻塞状态
• 过于保守:任何一个节点失败，都会导致事务回滚。
• 事务协调者的单点故障:如果协调者在第二阶段出现了故障，其他参与者都会被锁定
• "脑裂导致数据不一致问题": 在第二阶段，TM像所有参与者RM发送了commit请求后，发生局部一场网络导致只有一部分参与者RM收到了commit请求，部分RM会进行数据变更操作，但是未收到commit请求的则数据不会变更，导致数据不一致。

三阶段提交协议

三阶段提交协议是基于两阶段协议的改进版本,在其中加入了超时机制解决两阶段协议同步阻塞的问题。

• CanCommit(询问阶段):TM向参与者发送事务执行请求，询问是否可以完成指令，参与者回答是或者不是即可，不需要真正的执行事务操作，这个阶段会有超时终止操作
• PreCommit(准备阶段):事务协调者会根据参与者的反馈结果决定是否继续执行，如果在询问者阶段所有的参与者都可以正确响应，则TM会向所有参与者发送PreCommit请求，请求者收到后写入redo和undo日志，执行事务但是不提交事务，然后返回ACK等待下一步通知。如果询问阶段任意参与者不能响应，那么事务协调者会发送终止请求。
• DoCommit(提交或回滚): 根据上一步的执行步骤来决定DoCommit的执行操作。如果每个阶段都返回成功则执行提交操作，否则发起终止指令操作，回滚事务。

相比较于2PC增加了一个CanCommit阶段询问所有参与者是否可以正确响应能执行，可以提前发现无法执行操作而终止后续的行为

在准备阶段，事务协调者加入了超时机制，一旦超时，事务协调者会和产于者会继续提交事务，并且人为处于成功状态，因为在这种情况下事务默认为成功的可能性比较大。

CAP定理和BASE理论

CAP定理，又叫布鲁尔定理，C一致性、A可用性、P分区容错性。3个要求最多满足2个

• C:数据在多个副本中要保持移植，比如说分布式数据一致问题

• A：系统对外提供的服务必须一直处于可用状态，在任务和故障下，客户端都能在合理的时间内获取到服务端的非错误响应

• P:在分布式系统中遇到任何网络分区故障，系统仍然能够正常对外提供服务。

  CAP定理证明，在分布式系统中要么CP要么满足AP，不可能实现CAP、或者CA，因为网络通讯并不是绝对可靠的。
  

  如果CA或者CAP这种情况，相当于网络百分之百可靠，否则当出现网络分区的情况下时，为了保证数据的一致性，必须拒绝客户端的请求。单如果拒绝了请求，就无法满足A，所以分布式系统中不可能选择CA，因此只有AP或者CP两种选择。

  BASE理论

  BASE理论是由于CAP中一致性和可用性不能兼得而衍生出来的一种新思想，BASE理论的核心思想是通过牺牲数据的强一致性来获得高可用性。

• Basically Available（基本可用）:分布式系统出现故障时候，允许损失一部分功能的可用性，保证核心功能的可能。

• Soft State(软状态)：允许系统中的数据存在中间状态，这个状态不影响系统的可用性，也就是允许节点之间存在延时

• Elventually Consistent：中间状态在经过一段时间之后，会达到最终的数据一致性。

分布式事务的问题常见解决方案

TCC补偿性方案

TCC是一种比较成熟的分布式一致性数据解决方案，实际上它是把一个完成的业务拆分为三步骤执行

• Try:这个阶段主要是对数据进行校验或者资源的预留
• Confirm: 确认真正执行的任务，只操作Try阶段预留的资源
• Cancel：取消执行，释放Try阶段预留的资源

基于可靠的最终一致性方案

基于可靠性的最终一致性方案，采用kafka、rabbitmq、或者rocketmq的可靠性机制来实现数据一致性的投递。在RocketMQ当中的核心机制是事务回查

执行流程如下:

• 生产者发送一个事务到消息队列上，消息队列只记录这条数据。消费者无法消费这条信息
• 生产者执行具体的业务逻辑 完成本地事物的操作
• 生产者根据本地事务的执行记过发送一条确认消息给消息队列服务器，如果本地事务执行成功，则发送一个commit消息，表示在第一步中发送的消息可以被消费，否则，消息队列服务器会把第一步存储的消息删除
• 如果生产者在执行本地事务的过程中遇因为某些情况一直未发给消息队列服务器发送确认，那么消息队列服务器会定时主动回查生产者获取本地事务的执行结果，然后根据回查结果来决定这条消息是否需要投递给消费者
• 消息队列服务器上存储的消息被生产者确认之后，消费者就可以消费这条消息，消息消费完成之后发送一个确认标识给消息队列服务器，表示消息投送成功。

最大努力通知型

• 最大努力通知性和基于可靠的最终一致性方案是类似的，它是一种比较简单的柔性事务解决方案，也比较用于对数据一致性要求不搞的场景，最典型的使用场景是支付宝结果通知、微信支付结果通知。

  原理在于商户端如果没有返回一个消息确认，支付宝会不断重试，直到收到一个消息确认，或者达到最大重试次数

分布式事务框架Seata

Seata是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式解决方案。它提供了AT、TCC、Saga和XA事务模式

AT模式

AT模式是Seata最主推的分布式事务解决方案，它是基于XA演进而来的一种分布式事务模式，所以它同样分为三大模块，分别是TM、RM和TC，其中TM和RM作为Seata的客户端与业务系统集成，TC作为Seata的服务器独立部署。TC表示事务协调器(Transaction Coordinator)。

执行流程如下:

• TM向TC注册全局事务 并且生成全局唯一的XID3
• RM向TC注册分支事务 并将其纳入该XID对应的全局事务管理范围
• RM向TC汇报资源的准备状态
• TC汇总所有事务参与执行状态，决定分布式事务是全部回滚还是提交
• TC通知所有RM提交/回滚

AT模式的实现原理。分为量阶段提交协议

第一阶段:业务数据和回滚日志记录在同一个本地事务提交，释放本地锁和连接资源。

第二阶段:提交异步化，非常快速的完成。回滚通过第一阶段的回滚日志进行反向补偿。

Saga模式

Saga模式又称为长事务解决方案，核心思想是把一个业务流程中长的事务拆分成多个本地短事务，业务流程中的每个参与者都真是提交事务给本地短事务，当其中一个参与者失败，则通过补偿机制，补偿前面已经成功的参与者。

Saga提供两种补偿恢复方式

• 向后恢复，如果任一子事务执行失败，则把之前的结果逐一撤销
• 向前恢复 也就是不进行补偿，而是对失败的事务进行重试，这种方式比较适合于事务必须要执行成功的场景。