关于分布式事务:分布式事务理论及最终一致性解决方案

分布式事务

分布式事务是指会波及到操作多个数据库的事务，其实就是将对同一库事务的概念扩充到了对多个库的事务。目标是为了保障分布式系统中的数据一致性。

分布式事务处理的要害是：

1. 须要记录事务在任何节点所做的所有动作；
2. 事务进行的所有操作要么全副提交，要么全副回滚。

1.CAP 实践

分布式系统的三个指标：

• 一致性 Consistency：对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败。
• 可用性 Availability：任何客户端的申请都能失去响应数据，不会呈现响应谬误。
• 分区容错性 Partition tolerance：因为分布式系统通过网络进行通信，网络是不牢靠的。当任意数量的音讯失落或提早达到时，零碎仍会持续提供服务，不会挂掉。

一个分布式系统，不可能同时做到这三点；

对于一个分布式系统而言，P 是前提，必须保障，因为只有有网络交互就肯定会有提早和数据失落，这种情况咱们必须承受，必须保证系统不能挂掉。所以只剩下 C、A 能够抉择。要么保证数据一致性（保证数据相对正确），要么保障可用性（保证系统不出错）。

当抉择了 C（一致性）时，如果因为网络分区而无奈保障特定信息是最新的，则零碎将返回谬误或超时。

当抉择了 A（可用性）时，零碎将始终解决客户端的查问并尝试返回最新的可用的信息版本，即便因为网络分区而无奈保障其是最新的。

CP 架构

因为网络问题，节点 A 和节点 B 之前不能相互通信。当有客户端（上图 Actor）向节点 A 进行写入申请时（筹备写入 Message 2），节点 A 会不接管写入操作，导致写入失败，这样就保障了节点 A 和节点 B 的数据一致性，即保障了 Consisteny（一致性）。

而后，如果有另一个客户端（上图另一个 Actor）向 B 节点进行读申请的时候，B 申请返回的是网络故障之前所保留的信息（Message 1），并且这个信息是与节点 A 统一的，是整个零碎最初一次胜利写入的信息，是能失常提供服务的，即保障了 Partition tolerance（分区容错性）。

AP 架构

因为网络问题，节点 A 和节点 B 之前不能相互通信。当有客户端（上图 Actor）向节点 A 进行写入申请时（筹备写入 Message 2），节点 A 容许写入，申请操作胜利。但此时，因为 A 和 B 节点之前无奈通信，所以 B 节点的数据还是旧的（Message 1）。当有客户端向 B 节点发动读申请时候，读到的数据是旧数据，与在 A 节点读到的数据不统一。但因为零碎能照常提供服务，所以满足了 Availability（可用性）要求。

注意事项

对于开发者而言，构建服务的时候须要依据业务个性作出衡量思考，哪些点是以后零碎能够取舍的，哪些是应该重点保障的。

如在某个电商零碎中，属于用户模块的数据（账密、钱包余额等）对一致性的要求很高，就能够采纳 CP 架构。

而对于一些商品信息方面的数据对一致性要求没那么高，但为了关照用户体验，所以对可用性要求更高一些，那么这个模块的数据就能够采纳 AP 架构。

注：只能抉择 CP 和 AP，无奈抉择 CA，这句话成立的前提条件是在零碎产生了网络故障的状况下。在网络失常状况下，CA 是能够实现的，咱们也须要去保障在绝大多数工夫下的 CA 架构。

2.Base 实践

核心思想：既是无奈做到强一致性（Strong consistency），但每个利用都能够依据本身的业务特点，采纳适当的形式来使零碎达到最终一致性（Eventual consistency）。

Basically Available 根本可用

假如零碎，呈现了不可预知的故障，但还是能用，相比拟失常的零碎而言会有响应工夫和性能上的损失：

1. 响应工夫上的损失：失常状况下的搜索引擎 0.5 秒即返回给用户后果，而根本可用的搜索引擎能够在 2 秒作用返回后果。
2. 性能上的损失：在一个电商网站上，失常状况下，用户能够顺利完成每一笔订单。然而到了大促期间，为了爱护购物零碎的稳定性，局部消费者可能会被疏导到一个降级页面。

Soft state(软状态)

绝对于原子性而言，要求多个节点的数据正本都是统一的，这是一种“硬状态”。

软状态指的是：容许零碎中的数据存在中间状态，并认为该状态不影响零碎的整体可用性，即容许零碎在多个不同节点的数据正本存在数据延时。

如先把订单状态改成已领取胜利，而后通知用户曾经胜利了；剩下在异步发送 mq 音讯告诉库存服务减库存，即便生产失败,MQ 音讯也会从新发送（重试）。

注：不可能始终是软状态，必须有个工夫期限。在期限过后，该当保障所有正本保持数据一致性，从而达到数据的最终一致性。这个工夫期限取决于网络延时、零碎负载、数据复制方案设计等等因素。

Eventually consistent(最终一致性)

• 强一致性读操作要么处于阻塞状态，要么读到的是最新的数据
• 最终一致性通常是异步实现的，读到的数据刚开始可能是旧数据，然而过一段时间后读到的就是最新的数据

3. 最终一致性解决方案

留神

• 可查问操作：业务方须要提供可查问接口，来查问数据信息和状态，供其余服务晓得数据状态。
• 幂等操作：同样的参数执行同一个办法，返回的后果都一样。在分布式环境，难免会呈现数据的不统一，很多时候为了保证数据的统一，咱们都会进行重试。如果不保障幂等，即便重试胜利了，也无奈保证数据的一致性。咱们能够通过业务自身实现实现幂等，比方数据库的惟一索引来束缚；也能够缓存（记录）申请和操作后果，当检测到一样的申请时，返回之前的后果。
• 弥补操作：某些数据存在不失常的状态，须要通过额定的形式使数据达到最终一致性的操作。

XA 标准

XA 标准是由 X/Open 组织（即当初的 Open Group）定义的分布式事务处理模型。\

XA 一共分为两阶段：

第一阶段（prepare）：即所有的参与者 RM 筹备执行事务并锁住须要的资源。参与者 ready 时，向 TM 报告已准备就绪。

第二阶段 (commit/rollback)：当事务管理者 (TM) 确认所有参与者 (RM) 都 ready 后，向所有参与者发送 commit 命令。

目前支流的数据库根本都反对 XA 事务，包含 mysql、oracle、sqlserver、postgre

XA 标准的组成

• 应用程序（AP）
• 事务管理器（TM）：交易中间件等
• 资源管理器（RM）：关系型数据库等
• 通信资源管理器（CRM）：消息中间件等

XA 标准定义

XA 标准定义了交易中间件与数据库之间的接口标准（即接口函数），交易中间件用它来告诉数据库事务的开始、完结以及提交、回滚等。而 XA 接口函数由数据库厂商提供。

二阶提交协定和三阶提交协定就是基于 XA 标准提出的其中，二阶段提交就是实现 XA 分布式事务的要害。

XA 编程标准

1. 配置 TM，给 TM 注册 RM 作为数据源。其中，一个 TM 能够注册多个 RM。
2. AP 向 TM 发动一个全局事务。这时，TM 会发送一个 XID（全局事务 ID）告诉各个 RM。
3. AP 从 TM 获取资源管理器的代理（例如：应用 JTA 接口，从 TM 治理的上下文中，获取出这个 TM 所治理的 RM 的 JDBC 连贯或 JMS 连贯）。
4. AP 通过从 TM 中获取的连贯，间接操作 RM 进行业务操作。TM 在每次 AP 操作时把 XID 传递给 RM，RM 正是通过这个 XID 关联来操作和事务的关系的。
5. AP 完结全局事务时，TM 会告诉 RM 全局事务完结。开始二段提交，也就是 prepare – commit 的过程。

二阶段提交协定 2PC

思路：每个参与者将操作成败告诉协调者，再由协调者依据所有参与者的反馈情报，决定各参与者是否要提交操作还是停止操作。

• 第一阶段：筹备阶段（投票阶段）
• 第二阶段：提交阶段（执行阶段）

筹备阶段

a. 事务询问

协调者向所有的参与者询问，是否筹备好了执行事务，并开始期待各参与者的响应。

b. 执行事务

各参与者节点执行事务操作。如果本地事务胜利，将 Undo 和 Redo 信息记入事务日志中，但不提交；否则，间接返回失败，退出执行。

c. 各参与者向协调者反馈事务询问的响应

如果参与者胜利执行了事务操作，那么就反馈给协调者 Yes 响应，示意事务能够执行提交；如果参与者没有胜利执行事务，就返回 No 给协调者，示意事务不能够执行提交。

提交阶段

在提交阶段中，会依据筹备阶段的投票后果执行 2 种操作：执行事务提交，中断事务。

事务提交

a. 发送提交申请

协调者向所有参与者收回 commit 申请。

b. 事务提交

参与者收到 commit 申请后，会正式执行事务提交操作，并在实现提交之后，开释整个事务执行期间占用的事务资源。

c. 反馈事务提交后果

参与者在实现事务提交之后，向协调者发送 Ack 信息。

d. 事务提交确认

协调者接管到所有参与者反馈的 Ack 信息后，实现事务。

中断事务

a. 发送回滚申请

协调者向所有参与者收回 Rollback 申请。

b. 事务回滚

参与者接管到 Rollback 申请后，会利用其在提交阶段种记录的 Undo 信息，来执行事务回滚操作。在实现回滚之后，开释在整个事务执行期间占用的资源。

c. 反馈事务回滚后果

参与者在实现事务回滚之后，向协调者发送 Ack 信息。

d. 事务中断确认

协调者接管到所有参与者反馈的 Ack 信息后，实现事务中断。

优缺点

• 长处：原理简略，实现不便。
• 毛病：同步阻塞，单点问题，数据不统一，容错性不好。

问题

1、同步阻塞问题。执行过程中，所有参加节点都是事务阻塞型的。当参与者占有公共资源时，其余第三方节点拜访公共资源不得不处于阻塞状态。

2、单点故障。因为协调者的重要性，一旦协调者产生故障。参与者会始终阻塞上来。尤其在第二阶段，协调者产生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无奈持续实现事务操作。（如果是协调者挂掉，能够从新选举一个协调者，然而无奈解决因为协调者宕机导致的参与者处于阻塞状态的问题）

3、数据不统一。在二阶段提交的阶段二中，当协调者向参与者发送 commit 申请之后，产生了部分网络异样或者在发送 commit 申请过程中协调者产生了故障，这回导致只有一部分参与者承受到了 commit 申请。而在这部分参与者接到 commit 申请之后就会执行 commit 操作。然而其余局部未接到 commit 申请的机器则无奈执行事务提交。于是整个分布式系统便呈现了数据部一致性的景象。

4、二阶段无奈解决的问题：协调者再收回 commit 音讯之后宕机，而惟一接管到这条音讯的参与者同时也宕机了。那么即便协调者通过选举协定产生了新的协调者，这条事务的状态也是不确定的，没人晓得事务是否被曾经提交

TCC 事务模式

TCC：Try（预处理）、Confirm（确认）、Cancel（勾销）

三个阶段

• Try 阶段：次要是对业务零碎做检测及资源预留
• Confirm 阶段：次要是对业务零碎做确认提交，Try 阶段执行胜利并开始执行 Confirm 阶段时，默认 Confirm 阶段是不会出错的。即：只有 Try 胜利，Confirm 肯定胜利。如果 confirm 出错了，那么就须要引入弥补机制或者人工解决。
• Cancel 阶段：次要是在业务执行谬误，须要回滚的状态下执行的业务勾销，预留资源开释。同样 TCC 中咱们认为 cancel 阶段肯定会执行胜利，如果失败也须要引入重试或者人工解决。

三种异样解决

• 空回滚：分支事务异样调用失败，并未执行 try 办法，当复原后事务执行回滚操作就会调用此分支事务的 cancel 办法，如果 cancel 办法不能解决此种状况就会呈现空回滚。

  解决：记录全局事务 ID，当 cancel 执行时，先判断是否有该全局事务 ID，有则回滚，否则不做任何操作。

• 幂等：因为服务宕机或者网络问题，办法的调用可能呈现超时，为了保障事务失常执行咱们往往会退出重试的机制，因而就 须要保障 confirm 和 cancel 阶段操作的幂等性。

  解决：在分支事务记录表中减少事务执行状态，每次执行 confirm 和 cancel 办法时都查问该事务的执行状态，以此判断事务的幂等性。

• 悬挂：调用 try 之前会先注册分支事务，注册分支事务之后，调用呈现超时，此时 try 申请还未达到对应的服务，因为调用超时了，所以会执行 cancel 调用，此时 cancel 曾经执行完了，然而这个时候 try 申请达到了，这个时候执行了 try 之后就没有后续的操作了，就会导致资源挂起，无奈开释。

  解决：执行 try 办法时咱们能够判断 confirm 或者 cancel 办法是否执行，如果执行了那么就不执行 try 阶段。同样借助分支事务表中事务的执行状态。如果曾经执行了 confirm 或者 cancel 那么 try 就执行。

长处：跟 2PC 比起来，实现以及流程绝对简略了一些，但数据的一致性比 2PC 也要差一些

毛病：毛病还是比拟显著的，在 2,3 步中都有可能失败。TCC 属于应用层的一种弥补形式，所以须要程序员在实现的时候多写很多弥补的代码，在一些场景中，一些业务流程可能用 TCC 不太好定义及解决。

本地音讯

将须要分布式解决的工作通过音讯的形式来异步确保执行。

写本地音讯和业务操作放在一个事务里，保障了业务和发消息的原子性，要么他们全都胜利，要么全都失败。

1. 当零碎 A 被其余零碎调用产生数据库表更操作，首先会更新数据库的业务表，其次会往雷同数据库的音讯表中插入一条数据，两个操作产生在同一个事务中
2. 零碎 A 的脚本定期轮询本地音讯往 mq 中写入一条音讯，如果音讯发送失败会进行重试
3. 零碎 B 生产 mq 中的音讯，并解决业务逻辑。如果本地事务处理失败，会在持续生产 mq 中的音讯进行重试，如果业务上的失败，能够告诉零碎 A 进行回滚操作

本地音讯表实现的条件：

• 消费者与生成者的接口都要反对幂等
• 生产者须要额定的创立音讯表
• 须要提供弥补逻辑，如果消费者业务失败，须要生产者反对回滚操作

容错机制：

• 步骤 1 失败时，事务间接回滚
• 步骤 2、3 写 mq 与生产 mq 失败会进行重试
• 步骤 3 业务失败零碎 B 向零碎 A 发动事务回滚操作

此计划的外围是将须要分布式解决的工作通过消息日志的形式来异步执行。

消息日志能够存储到本地文本、数据库或音讯队列，再通过业务规定主动或人工发动重试。人工重试更多的是利用于领取场景，通过对账系统对预先问题的解决。

可靠消息

1. A 零碎先向 mq 发送一条 prepare 音讯，如果 prepare 音讯发送失败，则间接勾销操作
2. 如果音讯发送胜利，则执行本地事务
3. 如果本地事务执行胜利，则 mq 发送一条 confirm 音讯，如果发送失败，则发送回滚音讯
4. B 零碎定期生产 mq 中的 confirm 音讯，执行本地事务，并发送 ack 音讯。如果 B 零碎中的本地事务失败，会始终一直重试，如果是业务失败，会向 A 零碎发动回滚申请
5. mq 会定期轮询所有 prepared 音讯调用零碎 A 提供的接口查问音讯的解决状况，如果该 prepare 音讯本地事务处理胜利，则从新发送 confirm 音讯，否则间接回滚该音讯

该计划与本地音讯最大的不同是 去掉了本地音讯表，本地音讯表依赖音讯表重试写入 mq 这一步由本计划中的轮询 prepare 音讯状态来重试或者回滚该音讯代替。其实现条件与余容错计划基本一致。

目前市面上实现该计划的有阿里的 RocketMq。

最大致力告诉

最大致力告诉是最简略的一种柔性事务，实用于一些最终一致性工夫敏感度低的业务，且被动方处理结果不影响被动方的处理结果。（须要重复告诉的状况）

这个计划的大抵意思就是：

• 零碎 A 本地事务执行完之后，发送个音讯到 MQ；
• 这里会有个专门生产 MQ 的服务，这个服务会生产 MQ 并调用零碎 B 的接口；
• 要是零碎 B 执行胜利就 ok 了；要是零碎 B 执行失败了，那么最大致力告诉服务就定时尝试从新调用零碎 B, 重复 N 次，最初还是不行就放弃。

Refenrence

分布式实践系列

架构设计之 CAP 定理

分布式事务解决方案（一）2 阶段提交 & 3 阶段提交 & TCC

分布式事务 - 最终一致性计划之 TCC

“ 分布式事务一致性 ” 看这一篇就够了

分布式事务最经典的七种解决方案

分布式事务：从实践到实际