dockercentos镜像

常见的分布式事务场景

分布式事务其实就在我们身边&＃xff0c;你一直在用&＃xff0c;但是你却一直不注意它。

转账

扣你账户的余额&＃xff0c;增加别人账户余额&＃xff0c;如果只扣了你的&＃xff0c;别人没增加这是失败&＃xff1b;如果没扣你的钱别人也增加了那银行的赔钱。

下订单/扣库存

电商系统中这是很常见的一个场景&＃xff0c;用户下单成功了&＃xff0c;店家没收到单&＃xff0c;不发货&＃xff1b;用户取消了订单&＃xff0c;但是店家却看到了订单&＃xff0c;发了货。

分库分表场景

当我们的数据量大了之后&＃xff0c;我们可能会部署很多独立的数据库&＃xff0c;但是你的一个逻辑可能会同时操作很多个数据库的表&＃xff0c;这时候该如何保证所有的操作要么成功&＃xff0c;要么失败。

分布式系统调用问题

微服务的拆分让各个系统各司其职&＃xff0c;但是带来的也有很多痛苦&＃xff0c;一个操作可能会伴随很多的外部请求&＃xff0c;如果某一个外部系统挂掉了&＃xff0c;之前操作已完成的这些是否需要回滚。

针对上面这些问题&＃xff0c;我们前面学过的数据库4大特性&＃xff1a;ACID 似乎在这里想要达到就变得很困难&＃xff0c;单机情况下你还可以通过锁和日志机制来控制数据&＃xff0c;在分布式场景又该如何实现呢&＃xff1f;在不同的分布式应用架构下&＃xff0c;实现一个分布式事务要考虑的问题并不完全一样&＃xff0c;比如对多资源的协调、事务的跨服务传播等&＃xff0c;实现机制也是复杂多变。尽管有这么多工程细节需要考虑&＃xff0c;但分布式事务最核心的还是其 ACID 特性&＃xff0c;只是这种 ACID 变换了场景。

分布式理论

CAP 定理

传统的 ACID 模型肯定无法解决分布式环境下的挑战&＃xff0c;基于此加州大学伯克利分校 Eric Brewer教授提出 CAP 定理&＃xff0c;他指出 现代 WEB 服务无法同时满足以下 3 个属性&＃xff1a;

• 一致性(Consistency) &＃xff1a; 所有的客户端都能返回最新的操作。
• 可用性(Availability) &＃xff1a; 非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。
• 分区容错性(Partition tolerance) &＃xff1a; 即使出现单个组件无法可用&＃xff0c;操作依然可以完成。

关于一致性的理解后面分出来三个方向&＃xff1a;

• 强一致&＃xff1a;任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程&＃xff0c;看到的操作顺序&＃xff0c;都和全局时钟下的顺序一致。简言之&＃xff0c;在任意时刻&＃xff0c;所有节点中的数据是一样的。
• 弱一致&＃xff1a;数据更新后&＃xff0c;如果能容忍后续的访问只能访问到部分或者全部访问不到&＃xff0c;则是弱一致性。
• 最终一致&＃xff1a;不保证在任意时刻任意节点上的同一份数据都是相同的&＃xff0c;但是随着时间的迁移&＃xff0c;不同节点上的同一份数据总是在向趋同的方向变化。简单说&＃xff0c;就是在一段时间后&＃xff0c;节点间的数据会最终达到一致状态。

关于一致性的理解不同&＃xff0c;后面对于 CAP 理论的实现就有所不同。

另外 Eric Brewer教授指出现代 WEB 服务无法同时满足这 3 个属性&＃xff0c;说的是无法同时满足&＃xff0c;那这是为什么呢&＃xff1f;

如果在某个分布式系统中无副本&＃xff0c;那么必然满足强一致性&＃xff0c;同时也满足可用性&＃xff0c;但是如果这个数据宕机了&＃xff0c;那么可用性就得不到保证。

如果一个系统满足 AP&＃xff0c;那么一致性又得不到保证。所以 CAP 原则的精髓就是要么 AP&＃xff0c;要么 CP&＃xff0c;要么 AC&＃xff0c;但是不存在 CAP。

BASE 定理

基于前面提到的 CAP&＃xff0c;反正我们都无法同时满足CAP&＃xff0c;设计系统的最高目的就是让他跑下去不出错&＃xff0c;那么是不是可以不要求强一致性&＃xff0c;最终让他一致即可。所以后面又提出来了 BASE 定理&＃xff1a;

• Basically Available&＃xff08;基本可用&＃xff09;
• Soft state&＃xff08;软状态&＃xff09;
• Eventually consistent&＃xff08;最终一致性&＃xff09;

基于现在大型分布式系统的复杂性&＃xff0c;我们无法保证服务永远达到999&＃xff0c;那么是否可以取舍&＃xff0c;核心服务达到999&＃xff0c;非核心服务允许挂为了保全核心服务。另外在非核心服务 down 机过程中允许系统暂时出现不一致但是这个不一致并不影响系统的核心功能使用。

最终系统恢复&＃xff0c;所有服务一起修复数据&＃xff0c;最终达到一致的状态。

业内通常把严格遵循 ACID 的事务称为刚性事务&＃xff0c;而基于 BASE 思想实现的事务称为柔性事务。柔性事务并不是完全放弃了 ACID&＃xff0c;仅仅是放宽了一致性要求&＃xff1a;事务完成后的一致性严格遵循&＃xff0c;事务中的一致性可适当放宽。

常见的分布式事务实现方案

分布式事务实现方案从类型上去分刚性事务、柔型事务。刚性事务&＃xff1a;通常无业务改造&＃xff0c;强一致性&＃xff0c;原生支持回滚/隔离性&＃xff0c;低并发&＃xff0c;适合短事务。柔性事务&＃xff1a;有业务改造&＃xff0c;最终一致性&＃xff0c;实现补偿接口&＃xff0c;实现资源锁定接口&＃xff0c;高并发&＃xff0c;适合长事务。

• 刚性事务&＃xff1a;XA 协议&＃xff08;2PC、JTA、JTS&＃xff09;、3PC
• 柔型事务&＃xff1a;TCC/FMT、Saga&＃xff08;状态机模式、Aop模式&＃xff09;、本地事务消息、消息事务&＃xff08;半消息&＃xff09;、最多努力通知型事务

两阶段提交(XA)

与本地事务一样&＃xff0c;分布式事务场景下也可以采用两阶段提交的方案来实现。XA 的全称是 eXtended Architecture&＃xff0c;它是一个分布式事务协议&＃xff0c;通过二阶段提交协议保证强一致性。

XA 规范中定义了分布式事务处理模型&＃xff0c;这个模型中包含四个核心角色&＃xff1a;

• RM (Resource Managers)&＃xff1a;资源管理器&＃xff0c;提供数据资源的操作、管理接口&＃xff0c;保证数据的一致性和完整性。最有代表性的就是数据库管理系统&＃xff0c;当然有的文件系统、MQ 系统也可以看作 RM。
• TM (Transaction Managers)&＃xff1a;事务管理器&＃xff0c;是一个协调者的角色&＃xff0c;协调跨库事务关联的所有 RM 的行为。
• AP (Application Program)&＃xff1a;应用程序&＃xff0c;按照业务规则调用 RM 接口来完成对业务模型数据的变更&＃xff0c;当数据的变更涉及多个 RM 且要保证事务时&＃xff0c;AP 就会通过 TM 来定义事务的边界&＃xff0c;TM 负责协调参与事务的各个 RM 一同完成一个全局事务。
• CRMs (Communication Resource Managers)&＃xff1a;主要用来进行跨服务的事务的传播。

XA 协议大概的两个流程为&＃xff1a;

1. 第一阶段&＃xff08;prepare&＃xff09;&＃xff1a;事务管理器向所有本地资源管理器发起请求&＃xff0c;询问是否是 ready 状态&＃xff0c;所有参与者都将本事务能否成功的信息反馈发给协调者&＃xff1b;
2. 第二阶段 (commit/rollback)&＃xff1a;事务管理器根据所有本地资源管理器的反馈&＃xff0c;通知所有本地资源管理器&＃xff0c;步调一致地在所有分支上提交或者回滚。

XA 协议是如何满足 ACID 的呢&＃xff1f;

原子性和持久性我们就不用说&＃xff0c;我们看看隔离性和一致性。

隔离性

XA 协议中没有描述如何实现分布式事务的隔离性&＃xff0c;但是 XA 协议要求每个资源管理器都要实现本地事务&＃xff0c;也就是说基于 XA 协议实现的分布式事务的隔离性是由每个资源管理器本地事务的隔离性来保证的&＃xff0c;当一个分布式事务的所有子事务都是隔离的&＃xff0c;那么这个分布式事务天然的就实现了隔离性。

一致性

在单机环境下的一致性就是保证当前服务器数据一致即可。事务执行完毕数据最终一致&＃xff0c;不同的隔离级别下事务执行过程的中间状态不能被别的事务观察到。

事务执行完毕最终一致这个好保证&＃xff0c;但是在RR 隔离级别下不可见一个未提交事务的中间态在分布式情况该如何做到呢&＃xff1f;单机上 MySQL 提供了MVCC机制&＃xff0c;采用多版本控制来处理&＃xff0c;那分布式事务场景也是否也可以提供这样的机制呢&＃xff1f;XA 协议并没有定义怎么实现全局的快照&＃xff0c;一个基本思路是用一个集中式或者逻辑上单调递增的东西来控制生成全局 Snapshot&＃xff0c;每个事务或者每条 SQL 执行时都去获取一次&＃xff0c;从而实现不同隔离级别下的一致性。当然开发的难度还是挺大。

存在的问题&＃xff1a;

• 同步阻塞&＃xff1a;当参与事务者存在占用公共资源的情况&＃xff0c;其中一个占用了资源&＃xff0c;其他事务参与者就只能阻塞等待资源释放&＃xff0c;处于阻塞状态。

• 单点故障&＃xff1a;一旦事务管理器出现故障&＃xff0c;整个系统不可用。

• 数据不一致&＃xff1a;在阶段二&＃xff0c;如果事务管理器只发送了部分 commit 消息&＃xff0c;此时网络发生异常&＃xff0c;那么只有部分参与者接收到 commit 消息&＃xff0c;也就是说只有部分参与者提交了事务&＃xff0c;使得系统数据不一致。

• 不确定性&＃xff1a;当事务管理器发送 commit 之后&＃xff0c;并且此时只有一个参与者收到了 commit&＃xff0c;那么当该参与者与事务管理器同时宕机之后&＃xff0c;重新选举的事务管理器无法确定该条消息是否提交成功。

总体来说 XA 方案实现简单&＃xff0c;但是带来的问题如果放在数据一致性要求严格的场景是无法保证数据正确性的。另外事务管理器单点会带来隐患&＃xff0c;同步阻塞模型也致使并发能力弱。

TCC

关于 TCC&＃xff08;Try-Confirm-Cancel&＃xff09;的概念&＃xff0c;最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。 TCC 事务机制相比于上面介绍的 XA&＃xff0c;解决了其几个缺点&＃xff1a;

1. 解决了协调者单点&＃xff0c;由主业务方发起并完成这个业务活动。业务活动管理器也变成多点&＃xff0c;引入集群。
2. 同步阻塞&＃xff1a;引入超时&＃xff0c;超时后进行补偿&＃xff0c;并且不会锁定整个资源&＃xff0c;将资源转换为业务逻辑形式&＃xff0c;粒度变小。
3. 数据一致性&＃xff0c;有了补偿机制之后&＃xff0c;由业务活动管理器控制一致性。

TCC 其实就是采用的补偿机制&＃xff0c;其核心思想是&＃xff1a;针对每个操作&＃xff0c;都要注册一个与其对应的确认和补偿&＃xff08;撤销&＃xff09;操作。TCC 模型完全交由业务实现&＃xff0c;每个子业务都需要实现 Try-Confirm-Cancel 三个接口&＃xff0c;对业务侵入大&＃xff0c;资源锁定交由业务方。

• Try 阶段&＃xff1a;尝试执行&＃xff0c;完成所有业务检查&＃xff08;一致性&＃xff09;, 预留必须业务资源&＃xff08;准隔离性&＃xff09;。
• Confirm 阶段&＃xff1a;确认执行真正执行业务&＃xff0c;不作任何业务检查&＃xff0c;只使用 Try 阶段预留的业务资源&＃xff0c;Confirm 操作满足幂等性。要求具备幂等设计&＃xff0c;Confirm 失败后需要进行重试。
• Cancel 阶段&＃xff1a;取消执行&＃xff0c;释放 Try 阶段预留的业务资源 Cancel 操作满足幂等性 Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致。

一个完整的业务活动由一个主业务服务与若干子业务服务组成&＃xff1a;

1. 主业务服务负责发起并完成整个业务活动&＃xff1b;
2. 业务服务提供 TCC 型业务操作&＃xff1b;
3. 业务活动管理器控制业务活动的一致性&＃xff0c;它登记业务活动中的操作&＃xff0c;并在业务活动提交时确认所有的TCC 型操作的 Confirm 操作&＃xff0c;在业务活动取消时调用所有 TCC 型操作的 Cancel 操作。

比如一个转账操作&＃xff1a;

1. 首先在 Try 阶段先把转账者的钱包冻结起来。
2. 在 Confirm 阶段&＃xff0c;调用转账接口操作转账&＃xff0c;转账成功后解冻。
3. 如果 Confirm 阶段成功那么就转账成功&＃xff0c;否则执行转账失败确认逻辑。

基于 TCC 实现分布式事务&＃xff0c;会将原来只需要一个接口就可以实现的逻辑拆分为 Try、Confirm、Cancel 三个接口&＃xff0c;所以代码实现复杂度相对较高&＃xff0c;需要在业务中写很多的补偿机制代码。

TCC将事务提交划分成两个阶段&＃xff0c;Try即为一阶段&＃xff0c;Confirm 和 Cancel 是二阶段并行的两个分支&＃xff0c;二选一。从阶段划分上非常像2PC&＃xff0c;我们是否可以说TCC是一种2PC或者2PC变种呢&＃xff1f;

对比一下 XA 事务模型&＃xff0c;TCC 的两阶段提交与 XA 还是有一些区别&＃xff1a;

1. 2PC 的操作对象在于资源层&＃xff0c;对于开发人员无感知&＃xff1b;而 TCC 的操作在于业务层&＃xff0c;具有较高开发成本。
2. 2PC 是一个整体的长事务&＃xff0c;也是刚性事务&＃xff1b;而 TCC 是一组的本地短事务&＃xff0c;是柔性事务。
3. 2PC 的 Prepare (表决阶段)进行了操作表决&＃xff1b;而 TCC 的 Try 并没有表决准备&＃xff0c;直接兼备资源操作与准备能力。
4. 2PC 是全局锁定资源&＃xff0c;所有参与者阻塞 交互等待 TM 通知&＃xff1b;而 TCC 的资源锁定在于 Try 操作&＃xff0c;业务方可以灵活选择业务资源的锁定粒度。

本地消息表#

方案通过在事务主动发起方额外新建事务消息表&＃xff0c;事务发起方处理业务和记录事务消息在本地事务中完成&＃xff0c;轮询事务消息表的数据发送事务消息&＃xff0c;事务被动方基于消息中间件消费事务消息表中的事务。

基于本地消息表的方案&＃xff0c;每个事务发起方都需要额外新建事务消息记录表&＃xff0c;用于记录分布式事务的消息的发生、处理状态。

事务发起方在处理完业务逻辑之后需要将当前事务保存在消息表中&＃xff0c;之后将消息发送到消息中间件中&＃xff0c;并将消息的状态设置为 “发送中”。

如果消息在投递过程中丢失怎么办呢&＃xff1f;事务发起方可以设置一个定时任务主动扫描状态为 “发送中” 的消息重新投送。只有消息被业务方消费完毕返回消费成功的结果才确认成功并将消息状态改为“已发送”。

这里因为网络异常或者发送异常导致一个消息可能会被重复发送&＃xff0c;所以要求接收方要做到幂等性&＃xff0c;允许重复消费。

这种方案的好处就是方案简单&＃xff0c;成本较低&＃xff0c;实现也不复杂。

但是坏处也有很多&＃xff0c;比如通过消息的方式延迟不好控制&＃xff1b;本地消息表与业务耦合在一起没有做到通用性&＃xff1b;本地消息表基于数据库来实现&＃xff0c;有一定的瓶颈。

事务消息