分布式事务常见问答

标签：事务 协调者 阶段 提交 RM 问答 参与者 分布式

v>

2.1 强一致性模型

 

 

 

 v>

在DTP模型中定义了3个核心组件: AP(Application Program)应用程序，AP组件定义了分布式事务（也即全局事务）的边界（即事务的开始和结 束）以及组成事务的具体操作（Actions）； RM(Resource Managers)资源管理器，RM指的是诸如MySQL、Oracle这样的数据库或者相应的数据库驱动或 可访问的文件系统或者打印机服务器，用以提供访问数据库资源的接口； TM(Transaction Manager)事务管理器，TM是分布式事务的协调者，其负责为分布式事务分配事务ID，监控事 务的执行过程，负责事务的完成和容错工作。TM管理的分布式事务可以跨多个RM，TM还管理2PC协议，协调分 布式事务的提交/回滚决策。 在DTP模型中使用了2种通信规范   v> 两阶段提交协议（ Two Phase Commit）不是在XA规范中提出，但是XA规范对其进行了优化。XA规范对两阶段提交 协议有2点优化： 在Phase 1中，RM可以断言“我这边不涉及数据增删改”来答复TM的prepare请求，从而让这个RM脱离当前的全局 事务，从而免去了Phase 2。 如果需要增删改的数据都在同一个RM上，TM可以使用一阶段提交——跳过两阶段提交中的Phase 1，直接执行 Phase 2。   v> 两阶段提交（ Two Phase Commit），就是将提交(commit)过程划分为2个阶段(Phase)： 阶段1： TM（事务管理器）通知各个RM（资源管理器）准备提交它们的事务分支。如果RM判断自己进行的 工作可以被提交，那就对工作内容进行持久化，再给TM肯定答复；要是发生了其他情况，那给TM的 都是否定答复。 以mysql数据库为例，在第一阶段，事务管理器向所有涉及到的数据库服务器发出prepare"准备提 交"请求，数据库收到请求后执行数据修改和日志记录等处理，处理完成后只是把事务的状态改成"可以 提交",然后把结果返回给事务管理器。 阶段2 TM根据阶段1各个RM prepare的结果，决定是提交还是回滚事务。如果所有的RM都prepare成功， 那么TM通知所有的RM进行提交；如果有RM prepare失败的话，则TM通知所有RM回滚自己的事务分 支。 以mysql数据库为例，如果第一阶段中所有数据库都prepare成功，那么事务管理器向数据库服务器 发出"确认提交"请求，数据库服务器把事务的"可以提交"状态改为"提交完成"状态，然后返回应答。如 果在第一阶段内有任何一个数据库的操作发生了错误，或者事务管理器收不到某个数据库的回应，则 认为事务失败，回撤所有数据库的事务。数据库服务器收不到第二阶段的确认提交请求，也会把"可以 提交"的事务回撤。 两阶段提交方案下全局事务的ACID特性，是依赖于RM的。一个全局事务内部包含了多个独立的事务 分支，这一组事务分支要么都成功，要么都失败。各个事务分支的ACID特性共同构成了全局事务的 ACID特性。也就是将单个事务分支支持的ACID特性提升一个层次到分布式事务的范畴。 二阶段提交看起来确实能够提供原子性的操作，但是不幸的是，二阶段提交还是有几个缺点的： 2PC 中的参与者是阻塞的。在第一阶段收到请求后就会预先锁定资源，一直到 commit 后才会释放。 由于协调者的重要性，一旦协调者TM发生故障，参与者RM会一直阻塞下去。尤其在第二阶段，协 调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。 若协调者第二阶段发送提交请求时崩溃，可能部分参与者收到commit请求提交了事务，而另一部 分参与者未收到commit请求而放弃事务，从而造成数据不一致的问题。   v> 三阶段提交（3PC)，是二阶段提交（2PC）的改进版本。 2PC 2PC存在的问题 同步阻塞问题 单点故障 数据不一致 3PC与两阶段提交不同的是，三阶段提交有两个改动点： 引入超时机制。同时在协调者和参与者中都引入超时机制。 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。也就是 说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、 PreCommit、DoCommit三个阶段。 CanCommit阶段 3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返 回Yes响应，否则返回No响应。 1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响 应。 2.响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应， 并进入预备状态。否则反馈No PreCommit阶段 协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。 假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。 1.发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。 2.事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。 3.响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。 假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行 事务的中断。 1.发送中断请求 协调者向所有参与者发送abort请求。 2.中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。 doCommit阶段 该阶段进行真正的事务提交，也可以分为以下两种情况。 Case 1：执行提交 1.发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者 发送doCommit请求。 2.事务提交 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资 源。 3.响应反馈 事务提交完之后，向协调者发送Ack响应。 4.完成事务 协调者接收到所有参与者的ack响应之后，完成事务。 Case 2：中断事务 协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响 应超时），那么就会执行中断事务。 1.发送中断请求 协调者向所有参与者发送abort请求 2.事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成 回滚之后释放所有的事务资源。 3.反馈结果 参与者完成事务回滚之后，向协调者发送ACK消息 4.中断事务 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。 相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他 会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样 就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。 了解了2PC和3PC之后，我们可以发现，无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。 Google Chubby的作者Mike Burrows说过， there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即世上只有一种一致性算法，那就是Paxos，所有其他一致性算法 都是Paxos算法的不完整版     v> 2.2 最终一致性模型 TCC TCC是Try-Confirm-Cancel的简称: Try 阶段：调用 Try 接口，尝试执行业务，完成所有业务检查，预留业务资源。 Confirm 或 Cancel 阶段：两者是互斥的，只能进入其中一个，并且都满足幂等性，允许失败重试。 Confirm 操作：对业务系统做确认提交，确认执行业务操作，不做其他业务检查，只使用 Try 阶段预留的业务资 源。 Cancel 操作：在业务执行错误，需要回滚的状态下执行业务取消，释放预留资源。 Try 阶段失败可以 Cancel，如果 Confirm 和 Cancel 阶段失败了怎么办？ TCC 中会添加事务日志，如果 Confirm 或者 Cancel 阶段出错，则会进行重试，所以这两个阶段需要 支持幂等；如果重试失败，则需要人工介入进行恢复和处理等。     v> TCC VS XA XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。TCC是 业务层面的分布式事务，最终一致性，不会一直持有资源的锁。 1) 在阶段1： 在XA中，各个RM准备提交各自的事务分支，事实上就是准备提交资源的更新操作(insert、delete、 update等)；而在TCC中，是主业务活动请求(try)各个从业务服务预留资源。 2) 在阶段2： XA根据第一阶段每个RM是否都prepare成功，判断是要提交还是回滚。如果都prepare成功，那么 就commit每个事务分支，反之则rollback每个事务分支。 TCC中，如果在第一阶段所有业务资源都预留成功，那么confirm各个从业务服务，否则取消 (cancel)所有从业务服务的资源预留请求。 TCC VS DTPTCC模型中的主业务服务 相当于 DTP模型中的AP，TCC模型中的从业务服务 相当于 DTP模型中的RM TCC模型中，从业务服务提供的try、confirm、cancel接口， 相当于 DTP模型中RM提供的prepare、commit、 rollback接口 DTP模型和TCC模型中都有一个事务管理器。不同的是： 在DTP模型中，阶段1的(prepare)和阶段2的(commit、rollback)，都是由TM进行调用的。 在TCC模型中，阶段1的try接口是主业务服务调用(绿色箭头)，阶段2的(confirm、cancel接口)是事务管理 器TM调用(红色箭头)。 可靠消息最终一致性 异步化在分布式系统设计中随处可见，基于消息队列的最终一致性就是一种异步事务机制，在业务中 广泛应用。 本地消息表 本地消息表的方案最初是由 ebay 的工程师提出，核心思想是将分布式事务拆分成本地事务进行处理， 通过消息日志的方式来异步执行。 本地消息表是一种业务耦合的设计，消息生产方需要额外建一个事务消息表，并记录消息发送状态， 消息消费方需要处理这个消息，并完成自己的业务逻辑，另外会有一个异步机制来定期扫描未完成的 消息，确保最终一致性。 下面我们用下单减库存业务来简单模拟本地消息表的实现过程： （ 1）系统收到下单请求，将订单业务数据存入到订单库中，并且同时存储该订单对应的消息数据，比 如购买商品的 ID 和数量，消息数据与订单库为同一库，更新订单和存储消息为一个本地事务，要么都 成功，要么都失败。 （ 2）库存服务通过消息中间件收到库存更新消息，调用库存服务进行业务操作，同时返回业务处理结 果。 （ 3）消息生产方，也就是订单服务收到处理结果后，将本地消息表的数据删除或者设置为已完成。 （ 4）设置异步任务，定时去扫描本地消息表，发现有未完成的任务则重试，保证最终一致性。

标签：事务,协调者,阶段,提交,RM,问答,参与者,分布式
From： https://www.cnblogs.com/JavaYuYin/p/18024118