【分布式事务及方案】

分布式事务及方案

一. 概述

在微服务架构下，系统被拆分为很多很多的服务，所以在进行一个业务流程时，比如商品下单逻辑，不可避免的会出现，同时调用多个服务的现象，同时过多个服务之间存在依赖关系，并且还要保证最终的数据一致性。这种场景我们如果在一个单体应用中，其实很好解决，直接将该业务的相关操作放在一个事务中即可。但在分布式框架之下，我们就需要一个全新的概念去实现它，这里我们就引出了一个问题：为什么需要分布式事务？

在单一数据节点中，事务仅限于对单一数据库资源的访问控制，称之为本地事务。事务具有ACID特性即：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），通俗来说就是同一个事务中对于数据库的更新操作来说要么都成功，要么都失败。几乎所有的成熟的关系型数据库都提供了对本地事务的原生支持。

但在基于微服务的分布式应用环境下，越来越多的应用场景要求对多个服务的访问及其相对应的多个数据库资源能纳入到同一个事务当中，关系型数据库虽然对本地事务提供了完美的ACID原生支持，但是在多数据源场景下，这种本地事务无法发挥原有作用，当需要保证分布式系统多数据源数据一致性时，就引出了分布式事务。

二. 分布式理论基础

该Part主要包含两个主流理论：CAP理论和BASE理论

1. CAP理论

CAP定理同时又被称作布鲁尔定理（Brewer‘s theorem），是指在分布式系统中Consistency（一致性）、Availability（可用性）、Partition（分区容错性），这个三个不可兼得。

一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

分区容错性：当节点之间的网络出现丢包或延迟时（出现网络分区），系统仍能继续运行。

2. BASE理论

**BASE：Basically Available（基本可用），Soft state（软状态），和Eventually consistent（最终一致性）**三个短语的缩写，来自ebay的架构师提出。BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

a. 基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。包括响应时间上的损失，正常情况下，处理用户请求需要0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为3s；系统功能上的损失，正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。

b. 软状态：指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

c. 最终一致性：系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

其实BASE理论就是对CAP理论中的AP的补充，他的核心点事关注最终一致性。

三. 分布式事务理论模型

常见的分布式事务解决方案
2PC 和 3PC：两阶段提交, 基于XA协议
TCC： Try、Confirm、Cancel
事务消息：最大努力通知型
Saga：补偿事务

分布式事务分类
刚性事务：遵循ACID
柔性事务：遵循BASE理论

1. 2PC模型

一阶段：准备阶段（投票阶段），由事务的协调者发起询问参与者是否可以提交事务，参与者开启事务

二阶段：提交阶段，根据一阶段结果提交（所有参与者同意）或回滚（任意参与者拒绝或超时）事务

2PC的缺点

•性能问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

•可靠性问题：参与者发生故障。协调者需要给每个参与者额外指定超时机制，超时后整个事务失败。协调者发生故障。参与者会一直阻塞下去，需要额外的备机进行容错。

•数据一致性问题：二阶段无法解决的问题，协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

•实现复杂：牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

2PC的优点

•尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）

2. 3PC模型

三阶段提交包括CanCommit、PreCommit、DoCommit三个阶段，它是二阶段提交协议的改进版本，三阶段提交有两个改动点。一是在协调者和参与者中都引入超时机制（二阶段协调者超时参与者自动终止事务，三阶段协调者超时参与者自动提交事务），二是在第一阶段和第二阶段中插入一个准备阶段、降低了阻塞范围（一阶段不开启事务，二阶段采开启事务，防止参与者宕机造成的等待超时长时间阻塞）。

•缺点：并没有解决数据一致性问题，当在参与者收到preCommit请求后等待doCommit指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

3. TCC模型

TCC（Try Confirm Cancel）方案是一种应用层面侵入业务的两阶段提交。其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。

第一阶段：Try（尝试），主要是对业务系统做检测及资源预留(加锁，锁住资源)

第二阶段：本阶段根据第一阶段的结果，决定是执行confirm还是cancel。Confirm执行真正的业务（执行业务，释放锁），Cancle取消预留资源（出问题，释放锁）

TCC优点：

•性能提升：具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。

•数据最终一致性：基于Confirm 和Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。

•可靠性：由主业务方发起并控制整个业务活动，业务活动管理器也变成多点、集群。

•可将非事务性资源纳入事务管理

TCC缺点：

•TCC 的Try、Confirm 和Cancel 操作功能要按具体业务来实现，业务耦合度较高，开发成本高。

•需要解决接口幂等、空回滚、资源悬挂问题。

4. MQ事务模型

基于MQ 的分布式事务方案其实是对本地消息表的封装，将本地消息表存在了MQ内部，而不是业务数据库中。在本地消息表方案中，保证事务主动方发写业务表数据和写消息表数据的一致性是基于数据库事务，RocketMQ的事务消息相对于普通MQ提供了2PC 的提交接口。

MQ事务方案优点

•消息数据独立存储，降低业务系统与消息系统之间的耦合。

•吞吐量大于使用本地消息表方案。

MQ事务方案缺点

•一次消息发送需要两次网络请求(half 消息+ commit/rollback 消息) 。

•业务处理服务需要实现消息状态回查接口。

•业务场景局限性：需要引入具备该功能的MQ，适用于分布式事务的提交或回滚只取决于事务发起方的业务需求，其他数据源的数据变更跟随发起方进行的业务场景。

5. Saga事务模型

Saga 事务核心思想是将长事务拆分为多个本地短事务，由Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。每个Saga 事务由一系列幂等的有序子事务(sub-transaction) Ti组成。每个Ti都有对应的幂等补偿动作Ci，补偿动作用于撤销Ti造成的结果。

Saga实现方式包括：

•命令协调（Order Orchestrator）：中央协调器（Orchestrator，简称OSO）以命令/回复的方式与每项服务进行通信，全权负责告诉每个参与者该做什么以及什么时候该做什么

•事件编排（Event Choreographyo）：没有中央协调器（没有单点风险）时，每个服务产生并观察其他服务的事件，并决定是否应采取行动。在事件编排方法中，第一个服务执行一个事务，然后发布一个事件。该事件被一个或多个服务进行监听，这些服务再执行本地事务并发布（或不发布）新的事件。当最后一个服务执行本地事务并且不发布任何事件时，意味着分布式事务结束，或者它发布的事件没有被任何Saga 参与者听到都意味着事务结束。

Saga优点

•长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统。

•Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统，如其它公司的服务或者是遗留系统的服务。

Saga缺点

•中央协调器模式存在协调器单点故障风险。

•事件/编排模式服务之间存在循环依赖的风险。当涉及的步骤较多，服务间关系混乱，难以追踪调测。

•存在脏读问题，由于Saga 模型中没有Prepare 阶段，因此事务间不能保证隔离性。当多个事务操作同一资源时，就会产生更新丢失、脏数据读取等问题。

四. 总结

•2PC/3PC：依赖于数据库，能够很好的提供强一致性和强事务性，但相对来说延迟比较高，比较适合传统的单体应用在同一个方法中存在跨库操作的情况，不适合高并发和高性能要求的场景。

•TCC：适用于执行时间确定且较短、实时性要求高、对数据一致性要求高的场景，比如交易、支付、账务；适用于需要管理非事务性资源场景。

•MQ 事务：适用于事务中参与方支持操作幂等、对一致性要求不高、业务上能容忍数据不一致到一个人工检查周期的场景，需要业务上有对账/校验系统兜底。适用于分布式事务的提交或回滚只取决于事务发起方的业务需求，其他数据源的数据变更跟随发起方进行的业务场景。

•Saga 事务：由于Saga 事务不能保证隔离性，需要在业务层控制并发，适合于业务场景事务并发操作同一资源较少的情况。Saga 相比缺少预提交动作，导致补偿动作的实现比较麻烦，例如业务是发送短信，补偿动作则得再发送一次短信说明撤销，用户体验比较差。Saga 事务较适用于补偿动作容易处理的场景。