微服务拆分如何规避分布式事务 微服务的分布式事务

微服务实战 05 分布式事务

• 分布式事务

• 分布式事务模型

• X/Open 分布式事务模型
• XA协议

• Mysql的XA事务分为外部XA和内部XA

• 两阶段提交
• 三阶段提交协议
• CAP 和 bash 理论

• CAP 定理
• BASH 理论

参考《Spring Cloud Alibaba 微服务原理与实战》

分布式事务

• 数据库事务的特性

• 原子性
• 一致性
• 隔离性
• 持久性
  但是在微服务架构下，随着业务和数据库的差分，原本的但数据库操作就变成了多个数据库的操作，由于每个数据库的事务执行情况只有自己知道，就无法保证事务的基本特性。
  准确的说，分布式事务是指参与者、支持事务的服务器、资源服务器及事务管理器分别位于分布式系统的不同节点上

分布式事务模型

分布式事务也叫分布式数据一致性问题，就是如何在分布式场景中保证多个节点数据一致性。分布式事务产生的核心原因在于存储资源的分不行。

X/Open 分布式事务模型

(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准，也就是了定义了规范和API接口，由这个厂商进行具体的实现。
X/Open DTP 定义了三种角色

• AP ： application 应用程序
• RM：Resource Manager 表示资源管理器 ， 比如数据库
• TM： Transaction Managet 表示事务管理器，一般指事务协调者，负责协调和管理事务。

大致流程

1. 配置TM，把多个RM注册到TM，相当于TM注册RM作为数据源
2. AP从TM管理的RM中获取连接，如果RM是数据库的话则获取JDBC连接
3. AP向TM发起一个全局事务，生成全局事务ID( XID), XID 会通知各个RM
4. AP 通过第二部获取的连接直接操作RM完成数据操作，这是，AP在每次操作时会把XID传递给RM
5. 根据各个RM的事务执行结果，执行提交或者回滚操作

XA协议

由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。XA接口提供资源管理器（RM）与事务管理器™之间进行通信的标准接口。
XA主要就是TM和RM之间的通讯桥梁。

Mysql的XA事务分为外部XA和内部XA

• 外部XA用于跨多MySQL实例的分布式事务，需要应用层作为协调者，MySQL数据库外部XA可以用在分布式数据库代理层，实现对MySQL数据库的分布式事务支持，例如开源的代理工具：网易的DDB，淘宝的TDDL等等。
• 内部XA事务用于同一实例下跨多引擎事务，由Binlog作为协调者，比如在一个存储引擎提交时，需要将提交信息写入二进制日志，这就是一个分布式内部XA事务，只不过二进制日志的参与者是MySQL本身。Binlog作为内部XA的协调者，在binlog中出现的内部xid，在crash recover时，由binlog负责提交。(这是因为，binlog不进行prepare，只进行commit，因此在binlog中出现的内部xid，一定能够保证其在底层各存储引擎中已经完成prepare)。

两阶段提交

两阶段提交将一个事务的处理过程分为投票和执行两个阶段

• 准备阶段：TM 通知 RM 准备分支事务、记录事务日志，并告诉事务管理器准备结果
• 提交/回滚阶段：如果所有的 RM 在准备阶段都明确返回成功，则事务管理器（TM）向所有的资源管理器 （RM）发起事务提交指令完成数据的变更。反之，如果任何一个 RM 明确返回失败，则 TM 会向所有 RM 发送事务回滚指令
  
  两阶段提交的缺点

1. 同步阻塞，所有的事务操作都是同步阻塞型的，对于任何一个指令都必须要有明确的相应才能继续进行下一步要，否则处于阻塞状态，占用的资源一直会锁定
2. 过于保守：任何一个节点失败都会导致数据回滚
3. 事务协调者单点故障：如果协调者在第二阶段出现了故障，嘛呢其他的参与者（RM）会一直处于锁定状态
4. “脑裂”导致数据不一致：在第二阶段中，TM 向所有 RM 发送 commit 请求后 ，发生局部网络异常导致只有一部分 RM 接收到了 commit操作 ，但是未收到 commit 请求的节点由于事务无法提交，导致出现不一致问题

三阶段提交协议

三阶段提交协议式两阶段提交协议的改进保本，他利用超时机制解决了同步阻塞的问题

• CanCommit ： TM 向 参与者发送事务执行请求，询问是否可以完成指令，参与者只需要回答是或者不是即可，不需要做真正的事务操作，这个阶段会有超时终止机制
• PreCommit：TM 会根据参与者的反馈结果决定是否继续执行，如果在询问阶段所有参与者都返回可以执行操作，则事务协调者会向所有参与者发送PreCommit请求，参与者收到请求后写 redo 和 undo 日志，执行事务操作但是不提交事务，然后返回ACK相应等待事务协调者的下一步通知，如果在询问阶段任意参与者返回不能执行操作的结果，那么事务协调者会向所有参与者发送事务中断请求。
• DoCommit： 根据 PreCommit 决定 DoCommit 的执行方式，如果每个参与者在 PreCommit 阶段都会返回成功，那么事务协调者会所有参与者发送事务提交指令，反之，如果任何一个 参与者 明确返回失败，则事务协调者 会向所有 参与者 发送事务回滚指令。
  
  三阶段提交协议 与 两阶段提交协议 的不同点
• 增加一个 CanCommit 阶段： 用于询问所有参与者是否可以执行事务操作并响应，它可以尽早发现无法执行操作而终止后续的行为
• 在准备阶段，事务协调者和参与者都引入了超时机制，如果超时则回滚
• 在提交阶段： 参与者在等待超时之后执行了commit操作，并且任务处于成功状态，这种情况下事务默认为成功的可能性很大。

三阶段提交一旦超时仍然可能出现数据不一致的问题，当然概率是比较小的，另外，他基于超时机制来避免资源的永久锁定。

无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。

CAP 和 bash 理论

CAP 定理

他是指在分布式系统中不可能同时满足一致性、可用行、分区容错性者三个基本需求，最多同时满足两个

• C （Consistency）： 数据在多个副本中保持强一致性
• A （Availability）： 系统对外提供的服务必须一直处于可用状态，在任何故障下，客户端都能在合理的时间内获得服务端的非错误响应
• P 在分布式系统中遇到任何网格分区故障，系统仍能正常对外提供服务

在分布式系统占用只能由AP或者CP两种选择.。

• AP：对于AP 来说，相当于放弃了强一致性，实现最终的一致
• CP： 放弃了高可用，实现强一致性

BASH 理论

BASH理论的核心思想是通过牺牲数据的强一致性来获取高可用

• Basically Acailable （基本可用）：分布式系统在出现故障时，允许损失一部分功能的可用性，保证核心功能的可用性
• Soft State （软状态）： 允许多个系统存在中间状态，这个状态不影响系统的可用性，也就是允许系统中不同节点的数据副本之间的同步存在延时
• Eventually Consistent （最终一执性）： 中间状态的数据在经过一段事件之后，回达到一个最终的数据一致性

BASE理论并没有要求数据的强一致性，而是允许数据在一段时间内是不一致的，但是数据最终会在某个时间点实现一致