Java Web分布式篇之分布式事务

Java Web系列文章汇总贴: Java Web知识总结汇总

---

分布式事务基本理论

基本概念

通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。 所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库（可以是不同的应用对应的数据库）。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。 一般情况下，某一数据库无法知道其它数据库在做什么。因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）映射到全局事务中。

2PC、3PC基本概念

2PC,3PC主要是基于分布式事务的分布式一致性算法（因为分布式事务也可能会导致数据的不一致问题，这跟副本的不一致性从大类上看是都归于数据的不一致）。

在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是，相互独立的节点之间无法准确的知道其他节点中的事务执行情况。所以从理论上讲，两台机器理论上无法达到一致的状态。如果想让分布式部署的多台机器中的数据保持一致性，那么就要保证在所有节点的数据写操作，要不全部都执行，要么全部的都不执行。但是，一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果。所以他也就不知道本次事务到底应该commit还是 roolback。所以，常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。使用2PC,3PC可以实现分布式的强一致性和分布式事务。

2PC

二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。2PC就是用来解决分布式事务的原子性问题。所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。

2PC的优缺点

优点：2PC的优点是很显然的，原理简单，实现方便。目前，绝大多数关系型数据库都是采用两阶段提交协议来完成分布式事务处理的。（也就是上边的2pc过程应用于关系型数据库的分布式事务）

缺点：2PC的缺点也很致命：同步阻塞，单点问题，数据不一致，脑裂等

3PC

3PC，即三阶段提交，是2阶段提交的改进版，其将二阶段提交协议的“准备阶段”一份为二，形成了cancommit，precommit，do commit三个阶段。

与两阶段提交不同的是，三阶段提交有两个改动点。

• 1、引入超时机制。（超时提交策略，当第三阶段参与者等待协调者超时后会提交事务，解决参与者同步阻塞问题，同时能在发生单点故障时，继续达成一致）
• 2、在第一阶段和第二阶段中插入一个准备阶段。（也是为了减少同步阻塞的发生范围）

3PC优缺点

优点：降低参与者阻塞范围，并能够在出现单点故障后继续达成一致
缺点：引入preCommit阶段，在这个阶段如果出现网络分区，协调者无法与参与者正常通信，参与者依然会进行事务提交，造成数据不一致。

2PC、3PC区别

区别	2PC	3PC
阶段	提交事务请求 + 执行事务请求	3PC将2PC的提交事务请求分成了CanCommit以及PreCommit
超时	只有协调者有超时判断	3PC上参与者和协调者都有超时的判断

3PC解决的问题：
一旦进入阶段三：可能会出现：1 协调者出现问题（单点） 2 协调者参与者之间的网络出现故障

二阶段无法解决的问题：协调者（在第二阶段）发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit（所以产生新的协调者之后，可以确定事务的状态，这就解决了单点）。而不会一直持有事务资源并处于阻塞状态。

3PC无法解决：数据不一致以及太过保守问题。

但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

2PC、3PC的应用

我们前面说过，对于大多数的关系型数据库来说，解决分布式事务的方法就是利用两阶段提交2pc，其过程就是我们上边介绍的2PC的过程。可参考：Mysql的2PC应用 。主要涉及mysql的几个日志：mysql日志文件 ，另外还有在事务过程中的redo_log undo redo undo。

更多：
分布式一致性理论，CAP，BASE理论
2PC、3PC及其应用

TCC事务

基本流程

TCC三个阶段的介绍：

• Try 阶段：尝试执行，完成所有业务检查（一致性），预留必需业务资源（准隔离性）。
• Confirm 阶段：确认真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作满足幂等性。要求具备幂等设计，Confirm 失败后需要进行重试。
• Cancel 阶段：取消执行，释放 Try 阶段预留的业务资源，Cancel 操作满足幂等性。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致。

举个简单的例子：
如果你用 100 元买了一瓶水， Try 阶段：你需要向你的钱包检查是否够 100 元并锁住这 100 元，水也是一样的。
如果有一个失败，则进行 Cancel(释放这 100 元和这一瓶水)，如果 Cancel 失败不论什么失败都进行重试 Cancel，所以需要保持幂等。
如果都成功，则进行 Confirm，确认这 100 元被扣，和这一瓶水被卖，如果 Confirm 失败无论什么失败则重试(会依靠活动日志进行重试)。

TCC解决的问题

• 解决了协调者单点，由主业务方发起并完成这个业务活动。业务活动管理器也变成多点，引入集群。
• 同步阻塞：引入超时，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小。
• 数据一致性，有了补偿机制之后，由业务活动管理器控制一致性。

本地消息表（异步确保）

基本原理

本地消息表这种实现方式应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理(因为本地的事务有成熟的方案解析，参考MySQL保证ACID的思路，参考Java Web数据库篇之MySQL特性中的数据库事务部分)，这种思路是来源于ebay。我们可以从下面的流程图中看出其中的一些细节：

基本思路就是：

• 消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。
• 消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
• 生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。

这种方案遵循BASE理论，采用的是最终一致性，笔者认为是这几种方案里面比较适合实际业务场景的，即不会出现像2PC那样复杂的实现(当调用链很长的时候，2PC的可用性是非常低的)，也不会像TCC那样可能出现确认或者回滚不了的情况。

优缺点

优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。
缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

MQ事务

在 RocketMQ 中实现了分布式事务，实际上是对本地消息表的一个封装，将本地消息表移动到了 MQ 内部。下面来看下RocketMQ实现分布式事务的机制。

概述

基本流程介绍

• 第一阶段 Prepared 消息，会拿到消息的地址。
• 第二阶段执行本地事务。
• 第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。消息接受者就能使用这个消息。

消息失败的处理

• 如果确认消息失败，在 RocketMQ Broker 中提供了定时扫描没有更新状态的消息。
• 如果有消息没有得到确认，会向消息发送者发送消息，来判断是否提交，在 RocketMQ 中是以 Listener 的形式给发送者，用来处理。
• 如果消费超时，则需要一直重试，消息接收端需要保证幂等。如果消息消费失败，这时就需要人工进行处理，因为这个概率较低，如果为了这种小概率时间而设计这个复杂的流程反而得不偿失

更多：
分布式开放消息系统(RocketMQ)的原理与实践

SAGA事务

Saga 是 30 年前一篇数据库伦理提到的一个概念。其核心思想是将长事务拆分为多个本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。

SAGA是一种多个事件组合成大事务的方式。有结合CQRS的开源实现(Axon)。

该模型其核心思想就是拆分分布式系统中的长事务为多个短事务，或者叫多个本地事务，然后由 Sagas 工作流引擎负责协调，如果整个流程正常结束，那么就算是业务成功完成，如果在这过程中实现失败，那么Sagas工作流引擎就会以相反的顺序调用补偿操作，重新进行业务回滚。

比如我们一次关于购买旅游套餐业务操作涉及到三个操作，他们分别是预定车辆，预定宾馆，预定机票，他们分别属于三个不同的远程接口。可能从我们程序的角度来说他们不属于一个事务，但是从业务角度来说是属于同一个事务的。

参考：
聊聊分布式事务，再说说解决方案
第一次有人把“分布式事务”讲的这么简单明了