学习笔记-架构的演进之全局事务-2月day14

july7may

于 2023-02-22 00:25:27 发布

阅读量164

点赞数

文章标签：架构数据库

本文链接：https://blog.csdn.net/sinat_22180095/article/details/129152748

版权

文章目录

全局事务
- XA 协议
- - 两段式提交（2 Phase Commit，2PC）
  - 三段式提交
共享事务
总结
附

全局事务

全局事务（Global Transactions），也会被称为外部事务（External Transactions）。这里我们重点讨论适用于单个服务使用多个数据源场景的事务解决方案。（虽然全局事务是没有“单个服务”这个约束的）
全局事务（单个服务）可以看做是一种在分布式环境中仍追求强一致性的事务处理方案。

XA 协议

1991 年，X/Open组织（后来并入了The Open Group）提出了一套叫做X/Open XA（XA 是 eXtended Architecture 的缩写）的事务处理框架，用于解决分布式事务的一致性问题。这个框架的核心内容是，定义了全局的事务管理器（Transaction Manager，用于协调全局事务）和局部的资源管理器（Resource Manager，用于驱动本地事务）之间的通讯接口。
XA 接口是双向的，是一个事务管理器和多个资源管理器之间通信的桥梁，通过协调多个数据源的动作保持一致，来实现全局事务的统一提交或者统一回滚。

两段式提交（2 Phase Commit，2PC）

为了解决多个事务一致性的问题，XA 将事务提交拆分成了两阶段过程，也就是准备阶段和提交阶段。

准备阶段，又叫做投票阶段。在这一阶段，协调者询问事务的所有参与者是否准备好提交，如果已经准备好提交回复 Prepared，否则回复 Non-Prepared。
这里的“准备”操作，其实和我们通常理解的“准备”不太一样：对于数据库来说，准备操作是在重做日志中记录全部事务提交操作所要做的内容，它与本地事务中真正提交的区别只是暂不写入最后一条 Commit Record。这意味着在做完数据持久化后并不会立即释放隔离性，也就是仍继续持有锁，维持数据对其他非事务内观察者的隔离状态。
提交阶段，又叫做执行阶段，协调者如果在准备阶段收到所有事务参与者回复的 Prepared 消息，就会首先在本地持久化事务状态为 Commit，然后向所有参与者发送 Commit 指令，所有参与者立即执行提交操作；否则，任意一个参与者回复了 Non-Prepared 消息，或任意一个参与者超时未回复，协调者都会将自己的事务状态持久化为“Abort”之后，向所有参与者发送 Abort 指令，参与者立即执行回滚操作。
对于数据库来说，提交阶段的提交操作是相对轻量的，仅仅是持久化一条 Commit Record 而已，通常能够快速完成。回滚阶段则相对耗时，收到 Abort 指令时，需要根据回滚日志清理已提交的数据，这可能是相对重负载操作。

要保证事务的一致性，2PC协议还需要满足两个前提条件：

必须假设网络在提交阶段这个短时间内是可靠的，即提交阶段不会丢失消息。同时也假设网络通讯在全过程都不会出现误差，即可以丢失消息，但不会传递错误的消息；
两段式提交中投票阶段失败了可以补救（回滚），而提交阶段失败了无法补救（不再改变提交或回滚的结果，只能等崩溃的节点重新恢复），因而提交阶段的耗时应尽可能短，这也是为了尽量控制网络风险的考虑。
必须假设因为网络分区、机器崩溃或者其他原因而导致失联的节点最终能够恢复，不会永久性地处于失联状态。由于在准备阶段已经写入了完整的重做日志，所以当失联机器一旦恢复，就能够从日志中找出已准备妥当但并未提交的事务数据，再向协调者查询该事务的状态，确定下一步应该进行提交还是回滚操作。

注意一点，以上的协调者和参与者，通常都是由数据库自己来扮演的，不需要应用程序介入，应用程序相对于数据库来说只扮演客户端的角色。
在这里插入图片描述

2PC的三个缺点：

单点问题：协调者在两段提交中具有举足轻重的作用，协调者等待参与者回复时可以有超时机制，允许参与者宕机，但参与者等待协调者指令时无法做超时处理。一旦协调者宕机，所有参与者都会受到影响。如果协调者一直没有恢复，没有正常发送 Commit 或者 Rollback 的指令，那所有参与者都必须一直等待。
性能问题：两段提交过程中，所有参与者相当于被绑定成为一个统一调度的整体，期间要经过两次远程服务调用、三次数据持久化（准备阶段写重做日志，协调者做状态持久化，提交阶段在日志写入 Commit Record），整个过程将持续到参与者集群中最慢的那一个处理操作结束为止。这就决定了两段式提交的性能通常都比较差。
一致性风险：当网络稳定性和宕机恢复能力的假设不成立时，两段式提交可能会出现一致性问题。

三段式提交

为了解决两段式提交的单点问题、性能问题和数据一致性问题，“三段式提交”（3 Phase Commit，3PC）协议出现了。
三段式提交把原本的两段式提交的准备阶段再细分为两个阶段，分别称为 CanCommit、PreCommit，把提交阶段改为 DoCommit 阶段。其中，新增的 CanCommit 是一个询问阶段，协调者让每个参与的数据库根据自身状态，评估该事务是否有可能顺利完成。

将准备阶段一分为二的理由是，这个阶段是重负载的操作，一旦协调者发出开始准备的消息，每个参与者都将马上开始写重做日志，这时候涉及的数据资源都会被锁住。如果此时某一个参与者无法完成提交，相当于所有的参与者都做了一轮无用功。所以，增加一轮询问阶段，如果都得到了正面的响应，那事务能够成功提交的把握就比较大了，也意味着因某个参与者提交时发生崩溃而导致全部回滚的风险相对变小了。
因此，在事务需要回滚的场景中，三段式的性能通常要比两段式好很多，但在事务能够正常提交的场景中，两段式和三段式提交的性能都很差，三段式因为多了一次询问，性能还要更差一些。
同样地，也是因为询问阶段使得事务失败回滚的概率变小了，所以在三段式提交中，如果协调者在 PreCommit 阶段开始之后发生了宕机，参与者没有能等到 DoCommit 的消息的话，默认的操作策略将是提交事务而不是回滚事务或者持续等待，这将有助于处理大多数可正常commit的情况。
在这里插入图片描述

三段式提交对单点问题和回滚时的性能问题有所改善，但是对一致性风险问题并未有任何改进，甚至是增加了面临的一致性风险。

比如，进入 PreCommit 阶段之后，协调者发出的指令不是 Ack 而是 Abort，而此时因为网络问题，有部分参与者直至超时都没能收到协调者的 Abort 指令的话，这些参与者将会错误地提交事务，这就产生了不同参与者之间数据不一致的问题。

共享事务

与全局事务的单个服务使用多个数据源正好相反，共享事务是指多个服务共用同一个数据源。

为了实现共享事务的一致性，就必须新增一个中间角色，也就是交易服务器。无论是用户服务、商家服务还是仓库服务（客户端），它们都要通过同一台交易服务器来与数据库打交道。交易服务器根据不同服务节点传来的同一个事务 ID，使用同一个数据库连接来处理跨越多个服务的交易事务。
在这里插入图片描述

但是，共享事务解决的可能是一个伪需求！因为这个方案，其实是与实际生产系统中的压力方向相悖的。一个服务集群里，数据库才是压力最大、最不容易伸缩拓展的重灾区。所以，现实中只有类似ProxySQL和MaxScale这样用于对多个数据库实例做负载均衡的数据库代理，而几乎没有反过来代理一个数据库为多个应用提供事务协调的交易服务代理。

让多个微服务去共享一个数据库这个方案，其实还有另一种应用形式：使用消息队列服务器来代替交易服务器，用户、商家、仓库的服务操作业务时，通过消息将所有对数据库的改动传送到消息队列服务器，然后通过消息的消费者来统一处理，实现由本地事务保障的持久化操作。这就是“单个数据库的消息驱动更新”（Message-Driven Update of a Single Database）。