分布式事务理论

分布式事务

事务

事务指的就是一个操作单元，在这个操作单元中的所有操作最终要保持一致的行为，要么所有操作都成功，要么所有的操作都被撤销。简单地说，事务提供一种“要么全部成功，要么全部失败”机制。

本地事务

本地事物其实可以认为是数据库提供的事务机制。说到数据库事务就不得不说，数据库事务中的四大特性:

• A：原子性(Atomicity)，一个事务中的所有操作，要么全部完成，要么全部失败

• C：一致性(Consistency)，在一个事务执行之前和执行之后数据库都必须处于一致性状态

• I：隔离性(Isolation)，在并发环境中，当不同的事务同时操作相同的数据时，事务之间互不影响

• D：持久性(Durability)，指的是只要事务成功结束，它对数据库所做的更新就必须永久的保存下来

数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的执行单元，该执行单元中的所有操作要么都成功，要么都失败，只要其中任一操作执行失败，都将导致整个事务的回滚

分布式事务

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。
本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

分布式事务的场景

单系统访问多个数据库

多个微服务访问同一个数据库

多个微服务访问多个数据库

 

 

分布式事务解决方案

1.基于可靠消息的最终一致性方案

基于可靠消息服务的方案是通过消息中间件保证上、下游应用数据操作的一致性。假设有A和B两个系统，分别可以处理任务A和任务B。此时存在一个业务流程，需要将任务A和任务B在同一个事务中处理。就可以使用消息中间件来实现这种分布式事务。

第一步：消息由系统A投递到中间件

1. 在系统A处理任务A前，首先向消息中间件发送一条消息

2. 消息中间件收到后将该条消息持久化，但并不投递。持久化成功后，向A回复一个确认应答

3. 系统A收到确认应答后，则可以开始处理任务A

4. 任务A处理完成后，向消息中间件发送Commit或者Rollback请求。该请求发送完成后，对系统A而言，该事务的处理过程就结束了

5. 如果消息中间件收到Commit，则向B系统投递消息；如果收到Rollback，则直接丢弃消息。但是如果消息中间件收不到Commit和Rollback指令，那么就要依靠"超时询问机制"。

超时询问机制

系统A除了实现正常的业务流程外，还需提供一个事务询问的接口，供消息中间件调用。当消息中间件收到发布消息便开始计时，如果到了超时没收到确认指令，就会主动调用系统A提供的事务询问接口询问该系统目前的状态。该接口会返回三种结果，中间件根据三种结果做出不同反应：

提交:将该消息投递给系统B
回滚:直接将条消息丢弃
处理中:继续等待

第二步:消息由中间件投递到系统B

消息中间件向下游系统投递完消息后便进入阻塞等待状态，下游系统便立即进行任务的处理，任务处理完成后便向消息中间件返回应答。

• 如果消息中间件收到确认应答后便认为该事务处理完毕

• 如果消息中间件在等待确认应答超时之后就会重新投递，直到下游消费者返回消费成功响应为止。

一般消息中间件可以设置消息重试的次数和时间间隔，如果最终还是不能成功投递，则需要手工干预。这里之所以使用人工干预，而不是使用让Ａ系统回滚，主要是考虑到整个系统设计的复杂度问题。

基于可靠消息服务的分布式事务，前半部分使用异步，注重性能；后半部分使用同步，注重开发成本。

2.本地消息表(最大努力通知)

最大努力通知也被称为定期校对，其实是对第二种解决方案的进一步优化。它引入了本地消息表来记录错误消息，然后加入失败消息的定期校对功能，来进一步保证消息会被下游系统消费。

第一步:消息由系统A投递到中间件

1. 处理业务的同一事务中，向本地消息表中写入一条记录

2. 准备专门的消息发送者不断地发送本地消息表中的消息到消息中间件，如果发送失败则重试

第二步:消息由中间件投递到系统B

1. 消息中间件收到消息后负责将该消息同步投递给相应的下游系统，并触发下游系统的任务执行

2. 当下游系统处理成功后，向消息中间件反馈确认应答，消息中间件便可以将该条消息删除，从而该事务完成

3. 对于投递失败的消息，利用重试机制进行重试，对于重试失败的，写入错误消息表

4. 消息中间件需要提供失败消息的查询接口，下游系统会定期查询失败消息，并将其消费

这种方式的优缺点：

• 优点： 一种非常经典的实现，实现了最终一致性。

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

3.TCC事务补偿型方案

TCC即为Try Confirm Cancel，它属于补偿型分布式事务。TCC实现分布式事务一共有三个步骤：

• Try： 尝试待执行的业务：这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源

• Confirm： 确认执行业务：确认执行业务操作，不做任何业务检查， 只使用Try阶段预留的业务资源。通常情况下，采用TCC则认为 Confifirm阶段是不会出错的。即：只要Try成功，Confifirm一定成功。若Confifirm阶段真的出错了，需引入重试机制或人工处理。

• Cancel： 取消待执行的业务:取消Try阶段预留的业务资源。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理

TCC两阶段提交与XA两阶段提交的区别是：

• XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。

• TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。

TCC事务的优缺点：

• 优点：把数据库层的二阶段提交上提到了应用层来实现，规避了数据库层的2PC性能低下问题。

• 缺点：TCC的Try、Confifirm和Cancel操作功能需业务提供，开发成本高。

 4.两阶段提交（2PC）

2PC即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commitphase），2是指两个阶段，P是指准备阶段，C是指提交阶段

• 准备阶段：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。（Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数据文件）

• 提交阶段：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。

 

第一阶段

• 各参与者都成功的情况

首先事务协调者向所有参与者发送 prepare 请求。
参与者开始执行各自的数据更新，写入各自的 Undo Log 和 Redo Log。
参与者执行成功后，暂时不提交事务，向协调者发送 Done 消息。
进入第二阶段。

 

 

 

第一阶段

• 有参与者失败的情况

向协调者发送 Fail 消息，协调者产生事务中断

• 事务中断

协调者向所有参与者发出 Rollback 请求。
参与者收到 Rollback 请求之后，会利用其在阶段一种记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事物执行期间占用的资源。
参与者在完成事物回滚之后，向协调者发送 Ack 消息。
中断事务

第二阶段

所有参与者的都执行成功，则协调者下发 Commit 消息，参与者提交本地事务，释放锁住的资源，并向协调者发送 Ack 确认。

当协调者受到所有的参与者确认消息后，整个分布式事务结束

二阶段提交的优缺点：

• 优点：实现方便

• 缺点：

  同步阻塞：在分布式事务的执行过程中，存在多次通信，占用时间长，并且在这个过程中所有节点处于阻塞状态，每个参与者持有的资源始终要加锁。
  单点故障：由上面可知协调者扮演着非常重要的角色，一旦协调者发生故障，参与者就会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。
  数据不一致：在第二阶段中，当协调者向参与者发送 commit 请求之后，发生了局部网络异常或者在发送 commit 请求过程中协调者发生了故障，就会导致只有一部分参与者接受到了commit 请求。而在这部分参与者接到 commit 请求之后就会执行 commit 操作，但是其他未接到 commit 请求的机器则无法执行事务提交，就导致了数据的不一致。