©2020-2024 ioDraw All rights reserved,
Privacy Policy
<>什么是分布式事务
<>什么是事务
事务即单位逻辑工作单元执行的多个数据库操作，必须同时失败/成功，且必须满足ACID原则。
ACID原则
* 原子性：事务必须是原子工作单元，不可继续分割，同时全部失败/成功。
* 隔离性：并发场景下各个事务之间操作隔离，互不影响。
* 持久性：事务执行完成后对系统的影响是永久性的。
* 一致性：事务完成时所有的数据需要保持一致。
<>什么是分布式事务
事务的参与者、执行事务的服务器、资源服务器和事务管理器分别位于分布式系统的不同节点之上
。产生的核心原因主要是因为，在分布式系统中，多个节点之间的存储资源的分布性，比如不同的服务节点使用了多个数据库，又或者是因为数据库(mysql/oralce)与缓存数据库(redis)之间的数据一致性。
<>分布式事务理论模型
<>X/Open DTP(X/Open Distributed Transaction Processing Reference Model)
X/Open DTP(X/Open Distributed Transaction Processing Reference
Model)是由X/Open组织定义的一套分布式事务
的标准。该标准提出了使用两阶段提交（2PC，Two-Phase-Commit）的方式来保证分布式事务的完整性。
X/Open DTP模型中包含了三个角色：
* Application(AP)，即应用程序。
* Resource Manager(RM)，资源管理器即数据库等持久化存储。
* Transaction Manger™，事务管理器，一般是指事务的协调者，主要职责是协调和管理事务，需要提供API接口或者管理RM。
X/Open DTP模型的实现步骤一般如下：
* 配置一个全局的TM，并且将多个RM注册到TM。
* AP从TM管理的RM中获取资源连接，假如是RM是数据库则RM返回的是JDBC连接。
* AP向TM发起一个全局事务，生成全局事务ID（XID），XID会通知每个RM。
* AP通过获取到的连接操作RM，每次操作时都会把XID传递给TM。
* AP结束全局事务，TM通知各个RM全局事务结束。
* 根据各个RM的事务执行结果，执行提交或者回滚事务操作。（只要有任何一个节点事务执行失败就会触发各个RM的事务回滚）
在DTP模型中，TM和多个RM之间的事务控制，是基于XA协议（XA Specification）来完成的。
XA协议是X/Open提出的分布式事务处理规范，也是分布式事务处理的工业标准
。XA协议定义了定义了xa_和ax_系列的函数圆形和功能描述、约束等，目前实现了该规范的关系型数据库有MySql、Oracle、DB2。
<>两阶段提交协议
顾名思义，在该协议中分布式事务中TM对于多个RM事务的管理会涉及到两个阶段的提交动作。
* 准备阶段：在该阶段中TM通知RM准备分支事务，记录事务日志，并告知TM准备结果。
*
提交/回滚阶段：在该阶段中如果所有的RM在上一个阶段都能够返回成功，则TM会向所有的RM发起提交事务的指令来完成数据的更改；假如有任一RM在上一个阶段返回失败，则TM会向所有的RM发送事务回滚的指令。
两阶段提交协议交一个事务拆分成了投票和执行两个阶段，其优点在于充分考虑到了分布式系统的不可靠因素，并且采用两阶段提交就
把由于系统不可靠而导致事务提交失败的概率降到最小。但是其也不是完美的解决方案，存在着如下的几个缺点：
* 同步操作引起阻塞：所有的RM都是事务阻塞型，指令都需要明确响应才能继续执行否则会处于阻塞导致占用的资源一直被占用。
* 对事务异常处理过于保守：只要有任一RM节点失败就会回退其他所有的节点不管其准备阶段返回成功或是失败。
* TM单点故障：假如事务协调者在提交/回滚阶段出现故障则会导致其他的RM一直都处于锁定状态不可用。
* “脑裂”导致数据不一致：假如提交/回滚阶段发生局部网络异常导致只有部分RM接收到了
commit请求，部分RM未接收到commit请求，导致出现数据不一致的问题。
<>三阶段提交协议
三阶段提交协议属于二阶段提交协议的改良版本，在该协议中利用了超时机制从而解决了同步阻塞的问题。在该协议中三个提交阶段的具体执行描述如下：
* 询问阶段（Can Commit?）：在阶段中TM向参与者（即RM）发送事务执行请求，询问是否可以完成指令，参与者只需要回答是或者否，不需真正提交事务
。在该阶段中会有超时中止机制。
* 准备阶段（Pre Commit）：假如全部参与者返回可执行，则协调者会向所有的参与者发送PreCommit请求，参与者接收后写undo和redo日志，
执行事务操作但是不提交，然后反馈ACK等待下一步通知。假如任一参与者返回不能够执行操作，则TM会向所有的参与者发送中断事务的指令。
* 执行阶段（Do Commit）：如果每个参与者在Pre Commit阶段都返回成功，那么协调者会向所有的参与者发起事务提交请求。反之只要
任意参与者返回失败，则发起中止指令来回滚事务。
三阶段提交协议相比于两阶段提交协议有一些不同之处：
* 增加Can Commit阶段用于询问所有参与者是否能执行事务并且响应，尽早地发现无法执行操作而中止后续的行为。
* Pre Commit阶段后TM和RM都引入了超时机制，一旦超时协调者和参与者还会继续提交事务且认为成功状态，这种情况下事务默认为成功的可能性较大。
* 基于超时机制避免了两阶段提交协议中出现的资源的永久锁定的情况。
其实，不管是三阶段提交和二阶段提交都是属于保证数据强一致性的协议。(Zookeeper集群节点一致性使用的是改良版的二阶段提交协议，不需要
所有的参与者第一阶段返回成功才能够提交事务，而是采用少数服从多数的投票机制完成数据的提交或回滚)。并且，两阶段提交和三阶段提交其实都是
XA协议解决分布式数据一致性问题的基本原理。
<>CAP定理和BASE理论
XA协议的数据强一致性实际上涉及到分布式事务的两个理论模型，分别是CAP定力和BASE理论。
<>CAP定理
又叫布鲁尔定理，指的是分布式系统中不可能同时满足CAP三个基本需求，最多只能同时满足两个。CAP分别的含义：
* C：Consistency 一致性。指的是数据在多个节点副本中保持强一致。
* A：Availability 可用性。指的是系统对外提供服务必须一致处于可用状态，在任何故障下都能在合理的时间内获取服务端的非错误相应。
* P：Partition Tolerance 分区容错性。指的是分布式系统中遇到任何网络分区(指的是不同节点在不同子网络中，在内部子网络正常下
由于某些原因导致这些节点出现网络不通的情况从而导致整个系统环境被切分成若干个独立的区域)故障，系统仍然能够对外提供正常服务。
由于网络通信并不是绝对可靠的，并且在分布式系统中即使网络故障也需要保证系统能够正常对外提供服务，因此Partition Tolerance是必然存在的
，所以只能够满足**AP或者CP，**而无法满足CAP或者CA。
* CP：放弃高可用性，实现强一致性。两阶段提交和三阶段提交都属于CP，可能会带来用户一个操作等待较长时间的问题带来不好的用户体验。
* AP：放弃了强一致性，实现最终一致性。是大多数互联网公司分布式系统一致性问题的选择。
如果是CA或者CAP，相当于保证网络百分百可靠
，否则当出现网络分区时，为了数据一致性，必须拒绝客户端请求。如果拒绝了请求则无法满足A，所以分布式系统中无法实现CAP或者CA。
<>BASE理论
BASE理论是由于CAP中一致性和可用性不可兼得而衍生出来的一种分布式系统数据一致性的新思想，核心思想是通过牺牲数据的强一致性来获取高可用性。
BASE理论拥有三个特性：
* Basically Available(基本可用)：分布式系统出现故障时通过损失一部分功能的可用性从而保证核心功能可用。
* Soft State(软状态)：允许系统中数据存在中间状态并且不影响系统可用性，也就是允许系统中不同节点的数据副本之间的同步存在延时。
* Eventuanlly Consistent(最终一致性)：中间状态数据经过一段时间后达到一个数据的一致性。
BASE理论通过允许数据在一段时间内不一致但是最终在某时间点实现一致
来保证整个系统的可用性。大多数互联网产品使用BASE理论，毕竟产品可用性对用户而言更加重要。（例如电商系统的订单支付，用户发起支付后并不需等待支付结果响应，可以从订单列表查看支付状态，而系统在支付成功后只需要更新该记录状态即可。这种场景下虽然会有短期的状态不一致，但是用户能够得到很良好的体验）。
参考：
《SpringCloudAlibaba微服务原理与实践》