跳至主要內容

MySQL-高可用篇-⑥分布式事务

holic-x2024年7月12日39大约 49 分钟JAVAMySQL

MySQL-高可用篇-⑥分布式事务

学习核心

学习资料

分布式事务概念核心

什么是分布式事务?(All or nothing)

​ 对于网上购物的每一笔订单来说,电商平台一般都会有两个核心步骤:一是订单业务采取下订单操作,二是库存业务采取减库存操作。

​ 通常,这两个业务会运行在不同的机器上,甚至是运行在不同区域的机器上。针对同一笔订单,当且仅当订单操作和减库存操作一致时,才能保证交易的正确性。也就是说一笔订单,只有这两个操作都完成,才能算做处理成功,否则处理失败,充分体现了“All or nothing”的思想。在分布式领域中,这个问题就是分布式事务问题。

​ 传统的事务一般指的是本地事务(单机事务),具备ACID 4个基本特性。而分布式事务(分布式系统中运行的事务)是由多个本地事务组合而成的,在分布式场景下,对事务的处理操作可能来自不同的机器,甚至是来自不同的操作系统。分布式事务由多个事务组成,因此基本满足ACID,其中的C是强一致性,也就是所有操作均执行成功,才提交最终结果,以保证数据一致性或完整性。但随着分布式系统规模不断扩大,复杂度急剧上升,达成强一致性所需时间周期较长,限定了复杂业务的处理。为了适应复杂业务,出现了BASE理论,该理论的一个关键点就是采用最终一致性代替强一致性

分布式事务场景

​ 微服务和DDD领域驱动设计是在业界非常流行。DDD是一种拆分微服务的方法,它从业务流程的视角从上往下拆分领域,通过聚合根关联多个领域,将多个流程聚合在一起,形成独立的服务。相比由数据表结构设计出的微服务,DDD这种方式更加合理,但也加大了分布式事务的实现难度。

​ 在传统的分布式事务实现方式中,一般会将一个完整的事务放在一个独立的项目中统一维护,并在一个数据库中统一处理所有的操作。这样在出现问题时,直接一起回滚,即可保证数据的互斥和统一性。

​ 不过,**这种方式的服务复用性和隔离性较差,很多核心业务为了事务的一致性只能聚合在一起。**为了保证一致性,事务在执行期间会互斥锁定大量的数据,导致服务整体性能存在瓶颈。**而非核心业务要想在隔离要求高的系统架构中,实现跨微服务的事务,难度更大,**因为核心业务基本不会配合非核心业务做改造,再加上核心业务经常随业务需求改动(聚合的业务过多),结果就是非核心业务没法做事务,核心业务也无法做个性化改造。

​ 也正因为如此,多个系统要想在互动的同时保持事务一致性,是一个令人头疼的问题,业内很多非核心业务无法和核心模块一起开启事务,经常出现操作出错,需要人工补偿修复的情况。尤其在微服务架构或用DDD方式实现的系统中,服务被拆分得更细,并且都是独立部署,拥有独立的数据库,这就导致要想保持事务一致性实现就更难了,因此跨越多个服务实现分布式事务已成为刚需。

如何实现分布式事务?

实际上并没有一种分布式事务的服务或者组件,能够很简单地解决分布式系统下的数据一致性问题。在使用分布式事务时,更多的情况是,用分布式事务的理论来指导设计和开发,自行来解决数据一致性问题

​ 分布式事务主要是解决在分布式环境下组合事务的一致性问题。实现分布式事务有以下3种基本方法:

​ 其中,基于XA协议的二阶段提交协议方法和三阶段提交协议方法,采用了强一致性,遵从ACID。基于消息的最终一致性方法,采用了最终一致性,遵从BASE理论。

分布式事务解决方案

1.基于XA协议的二阶段提交协议(2PC)方法

XA协议

​ XA协议是一个很流行的分布式事务协议,可以很好地支撑分布式事务的实现,比如常见的2PC、3PC等。这个协议适合在多个数据库中,协调分布式事务,目前Oracle、DB2、MySQL 5.7.7以上版本都支持它(虽然有很多bug)。理解XA协议对深入了解分布式事务的本质很有帮助。

​ 支持XA协议的数据库可以在客户端断开的情况下,将执行好的业务结果暂存起来,直到另外一个进程确认才会最终提交或回滚事务,这样就能轻松实现多个数据库的事务一致性。

​ 在XA协议里有三个主要的角色:

​ 另外,XA还对分布式事务规定了两个阶段:Prepare阶段和Commit阶段。

在Prepare阶段事务协调器会通过xid(事务唯一标识,由业务或事务协调器生成)协调多个资源管理器执行子事务,所有子事务执行成功后会向事务协调器汇报。这时的子事务执行成功是指事务内SQL执行成功,并没有执行事务的最终commit(提交),所有子事务是提交还是回滚,需要等事务协调器做最终决策。

​ 接着分布式事务进入Commit阶段:当事务协调器收到所有资源管理器成功执行子事务的消息后,会记录事务执行成功,并对子事务做真正提交。如果Prepare阶段有子事务失败,或者事务协调器在一段时间内没有收到所有子事务执行成功的消息,就会通知所有资源管理器对子事务执行回滚的操作。

子事务状态

​ 每个子事务都有多个状态,每个状态的流转情况如下所示:

image-20240715081536439

(1)MySQL如何实现XA规范?

​ MySQL 中 XA 事务有两种情况,内部 XA 和外部 XA,其区别是事务发生在 MySQL 服务器单机上,还是发生在多个外部节点间上。

内部 XA:在 MySQL 的 InnoDB 存储引擎中,开启 binlog 的情况下,MySQL 会同时维护 binlog 日志与 InnoDB 的 redo log,为了保证这两个日志的一致性,MySQL 使用了 XA 事务,由于是在 MySQL 单机上工作,所以被称为内部 XA内部 XA 事务由 binlog 作为协调者,在事务提交时,则需要将提交信息写入二进制日志,也就是说,binlog 的参与者是 MySQL 本身。

外部 XA:外部 XA 就是典型的分布式事务,MySQL 支持 XA START/END/PREPARE/Commit 这些 SQL 语句,通过使用这些命令,可以完成分布式事务。MySQL 外部 XA 主要应用在数据库代理层,实现对 MySQL 数据库的分布式事务支持,例如开源的数据库中间层,比如淘宝的 TDDL、阿里巴巴 B2B 的 Cobar 等。外部 XA 一般是针对跨多 MySQL 实例的分布式事务,需要应用层作为协调者,比如在写业务代码,在代码中决定提交还是回滚,并且在崩溃时进行恢复。

实现思路

​ XA是一个分布式事务协议,规定了事务管理器TM和资源管理器RM接口。因此,XA协议包括事务管理器和本地资源管理器两个部分。

XA实现分布式事务的原理,类似于集中式算法:事务管理器相当于协调者,负责各个本地资源的提交和回滚;而资源管理器就是分布式事务的参与者,通常由数据库实现,比如Oracle、DB2等商业数据库都实现了XA接口。

​ 基于 XA协议的二阶段提交方法中,二阶段提交协议(Two-phase Commit Protocol,2PC)用于保证分布式系统中事务提交时的数据一致性,是XA在全局事务中用于协调多个资源的机制。

两阶段提交协议如何保证分布在不同节点上的分布式事务的一致性?

​ 为了保证它们的一致性,需要引入一个协调者来管理所有的节点,并确保这些节点正确提交操作结果,若提交失败则放弃事务。下述分析两阶段提交的执行过程:两阶段提交协议的执行过程,分为投票(Voting)和提交(Commit)两个阶段

image-20240712144531278

​ 以订单系统和促销系统(事务:下订单使用优惠券)这一案例为参考,其时序图分析如下:

image-20240715093020157

二阶段提交具体执行流程

image-20240715082151348

​ 结合流程图分析,2PC的概念理解和实现相对简单,但是其也有相应的缺点:

​ 在Prepare阶段,很多操作的数据需要做行锁定以确保数据一致性,且存在同步阻塞问题(应用和每个子事务的过程需要阻塞,需要等整个事务全部完成才能释放资源,就会导致资源锁定时间较长,无法支持高并发场景,常有大量事务排队)

​ 在Commit阶段,如果事务协调器的提交操作被打断,XA事务就会被遗留在MySQL中,且2PC整体设计没有超时机制,如果长时间不提交遗留在MySQL中的XA子事务,就会导致数据库长期被锁表。在很多开源的实现中,2PC的事务协调器会自动回滚或强制提交长时间没有提交的事务,但是如果进程重启或宕机,这个操作就会丢失,则需要人工介入修复

案例分析

​ 以用户A要在网上下单购买100件T恤为例,结合下单操作和减库存操作这两个操作进行理解

​ 第一阶段(投票阶段):订单系统中将与用户A有关的订单数据库锁住,准备好增加一条关于用户A购买100件T恤的信息,并将同意消息“Yes”回复给协调者。而库存系统由于T恤库存不足,出货失败,因此向协调者回复了一个终止消息“No”。

​ 第二阶段:由于库存系统操作不成功,因此,协调者就会向订单系统和库存系统发送“DoAbort”消息。订单系统接收到“DoAbort”消息后,将系统内的数据退回到没有用户A购买100件T恤的版本,并释放锁住的数据库资源。订单系统和库存系统完成操作后,向协调者发送“HaveCommitted”消息,表示完成了事务的撤销操作。

​ 至此,用户A购买100件T恤这一事务已经结束,用户A购买失败。

image-20240712152436336

存在问题

​ 结合上述分析,二阶段提交的算法思路概括为:协调者向参与者下发请求事务操作,参与者接收到请求后进行相关操作并将操作结果通知协调者,协调者根据所有参与者的反馈结果决定各参与者是要提交操作还是撤销操作。

​ 虽然基于XA的二阶段提交算法尽量保证了数据的强一致性,而且实现成本低,但依然有些不足。主要有以下三个问题:

image-20240715100225874

2.基于XA协议的三阶段提交协议(3PC)方法

实现思路

​ 三阶段提交协议(Three-phase Commit Protocol,3PC),是对二阶段提交(2PC)的改进。为了更好地处理两阶段提交的同步阻塞和数据不一致问题(仅是优化不是完全消灭问题),三阶段提交引入了超时机制和准备阶段

三阶段提交协议就有CanCommitPreCommitDoCommit三个阶段:

CanCommit阶段

​ 协调者向参与者发送请求操作(CanCommit请求),询问参与者是否可以执行事务提交操作,然后等待参与者的响应;参与者收到CanCommit请求之后,回复Yes,表示可以顺利执行事务;否则回复No。

3PC的CanCommit阶段与2PC的Voting阶段相比:

当协调者接收到所有参与者回复的消息后,进入预提交阶段(PreCommit阶段)

PreCommit阶段

协调者根据参与者的回复情况,来决定是否可以进行PreCommit操作(预提交阶段)

预提交阶段保证了在最后提交阶段(DoCmmit阶段)之前所有参与者的状态是一致的

DoCommit阶段

DoCmmit阶段进行真正的事务提交,根据PreCommit阶段协调者发送的消息,进入执行提交阶段或事务中断阶段。

​ 每个阶段不同节点之间的事务请求成功和失败的流程简化说明如下所示

image-20240712174901821

存在问题

​ 3PC的引入是基于对2PC的优化,其还是会存在同步执行性能问题和数据不一致问题

引入超时机制优化同步阻塞问题,但同步性能问题依然存在:3PC协议在协调者和参与者均引入了超时机制。即当参与者在预提交阶段向协调者发送 Ack消息后,如果长时间没有得到协调者的响应,在默认情况下,参与者会自动将超时的事务进行提交,从而减少整个集群的阻塞时间,在一定程度上减少或减弱了2PC中出现的同步阻塞问题。

第三阶段提交存在因网络延迟导致ACK消息接受异常引发的存在数据不一致问题:但三阶段提交仍然存在数据不一致的情况,比如在PreCommit阶段,部分参与者已经接受到ACK消息进入执行阶段,但部分参与者与协调者网络不通,导致接收不到ACK消息,此时接收到ACK消息的参与者会执行任务,未接收到ACK消息且网络不通的参与者无法执行任务,最终导致数据不一致

​ 3PC步骤过多,过程较2PC复杂,且因其确认步骤过多,很多业务的互斥排队时间会很长,因此3PC的事务失败率会比2PC的高很多,整体执行更加缓慢,实际分布式生产环境中比较少用。

image-20240715100335095

场景应用

MySQL 的主从复制

​ 在 MySQL 中,二进制日志是 server 层,主要用来做主从复制即时点恢复时使用的;而事务日志(Redo Log)是 InnoDB 存储引擎层,用来保证事务安全的。

在数据库运行中,需要保证 Binlog 和 Redo Log 的一致性,如果顺序不一致, 则意味着 Master-Slave 可能不一致。

​ 在开启 Binlog 后,如何保证 Binlog 和 InnoDB redo 日志的一致性呢?MySQL 使用的就是二阶段提交,内部会自动将普通事务当做一个 XA 事务(内部分布式事务)来处理:

3.基于TCC协议的分段提交

实现思路

​ TCC是Try-Confirm-Cancel的缩写,从流程上来看,它比2PC多了一个阶段,也就是将Prepare阶段又拆分成了两个阶段:Try阶段和Confirm阶段。TCC可以不使用XA,只使用普通事务就能实现分布式事务。

​ 在 Try阶段,业务代码会预留业务所需的全部资源,比如冻结用户账户100元、提前扣除一个商品库存、提前创建一个没有开始交易的订单等,这样可以减少各个子事务锁定的数据量。业务拿到这些资源后,后续两个阶段操作就可以无锁进行了。

​ 在 Confirm阶段,业务确认所需的资源都拿到后,子事务会并行执行这些业务。执行时可以不做任何锁互斥和检查,直接执行Try阶段准备的所有资源。

​ 在 Cancel阶段:如果子事务在Try阶段或Confirm阶段多次执行重试后仍旧失败,TM就会执行Cancel阶段的代码,并释放Try预留的资源,同时回滚Confirm期间的内容。

​ 此处需注意,协议要求所有操作都是幂等的(尤其是Confirm、Cancel阶段)以支持失败时重试,如果重试失败则需要人工介入进行恢复和处理。因为在一些特殊情况下,比如资源锁争抢超时、网络不稳定等,操作要尝试执行多次才会成功。所谓幂等操作:指的是其任意多次执行所产生的影响均与一次执行的影响相同

image-20240715101623585

TCC执行流程分析

image-20240715084208376

TCC事务的优缺点

优点:

缺点:

案例分析

案例场景:支付业务

​ 以一个电商中的支付业务来演示,用户在支付以后,需要进行更新订单状态、扣减账户余额、增加账户积分和扣减商品操作。

​ 在实际业务中为了防止超卖,有下单减库存和付款减库存的区别,支付除了账户余额,还有各种第三方支付等,此处为了描述方便,统一使用扣款减库存,扣款来源是用户账户余额

用户支付
更新订单状态
第三方支付/扣减余额
增加账户积分
扣减商品库存

​ 如果不使用事务,上面的几个步骤都可能出现失败,最终会造成大量的数据不一致,比如订单状态更新失败,扣款却成功了;或者扣款失败,库存却扣减了等情况,这个在业务上是不能接受的,会出现大量的客诉。

​ 如果直接应用事务,不使用分布式事务,比如在代码中添加 Spring 的声明式事务 @Transactional 注解,这样做实际上是在事务中嵌套了远程服务调用,一旦服务调用出现超时,事务无法提交,就会导致数据库连接被占用,出现大量的阻塞和失败,会导致服务宕机。另一方面,如果没有定义额外的回滚操作,比如遇到异常,非 DB 的服务调用失败时,则无法正确执行回滚。

【1】业务系统改造(TCC)

​ 应用 TCC 事务,需要对业务代码改造,抽象 Try、Confirm 和 Cancel 阶段。

​ Try 操作一般都是锁定某个资源,设置一个预备的状态,冻结部分数据。例如此处对每个服务中要用到的资源通过设定一个状态进行锁定

​ 订单服务添加一个预备状态,修改为 UPDATING(更新中),冻结当前订单的操作,而不是直接修改为支付成功;

​ 库存服务设置冻结库存,可以扩展字段,也可以额外添加新的库存冻结表;

​ 积分服务和库存一样,添加一个预增加积分,比如本次订单积分是 100,添加一个额外的存储表示等待增加的积分;

​ 账户余额服务等也是类似的操作;

​ Confirm 操作就是把前边的 Try 操作锁定的资源提交,类比数据库事务中的 Commit 操作

​ 在支付的场景中,包括订单状态从准备中更新为支付成功;库存数据扣减冻结库存,积分数据增加预增加积分。

​ Cancel 操作执行的是业务上的回滚处理,类比数据库事务中的 Rollback 操作

​ 首先订单服务,撤销预备状态,还原为待支付状态或者已取消状态,库存服务删除冻结库存,添加到可销售库存中,积分服务也是一样,将预增加积分扣减掉。

【2】执行业务操作

​ 业务请求过来,开始执行 Try 操作,如果 TCC 分布式事务框架感知到各个服务的 Try 阶段都成功了以后,就会执行各个服务的 Confirm 逻辑。如果 Try 阶段有操作不能正确执行,比如订单失效、库存不足等,就会执行 Cancel 的逻辑,取消事务提交

存在问题

​ 由于TCC的业务侵入性比较高,需要开发编码配合,在一定程度上增加了不少工作量,存在一些使用上的弊端,需要投入更高的开发成本和更换事务实现方案的替换成本。通常并不会完全靠裸编码来实现TCC,而是会基于某些分布式事务中间件(如阿里开源的Seataopen in new window)来完成,以尽量减轻一些编码工作量

​ 假设将上述TCC案例场景调整一下限制条件,现系统需要扩展支付方式,支付形式不再单纯由系统进行管理,而是将用户、商家的账户余额由银行进行托管的话,其操作权限和数据结构就不可能再随心所欲地自行定义了,通常也就无法完成冻结款项、解冻、扣减这样的操作,因为银行一般不会配合你的操作。所以,在TCC的执行过程中,第一步Try阶段往往就已经无法施行了。因此此处只能考虑另一种柔性事务方案:SAGA事务

(1)SAGA事务基于数据补偿代替回滚的解决思路

​ SAGA事务模式的历史十分悠久,比分布式事务的概念提出还要更早。SAGA的意思是“长篇故事、长篇记叙、一长串事件”,它起源于1987年普林斯顿大学的赫克托 · 加西亚 · 莫利纳(Hector Garcia Molina)和肯尼斯 · 麦克米伦(Kenneth Salem)在ACM发表的一篇论文《SAGASopen in new window》(这就是论文的全名)。文中提出了一种如何提升“长时间事务”(Long Lived Transaction)运作效率的方法,大致思路是把一个大事务分解为可以交错运行的一系列子事务的集合。原本提出SAGA的目的,是为了避免大事务长时间锁定数据库的资源,后来才逐渐发展成将一个分布式环境中的大事务,分解为一系列本地事务的设计模式。

SAGA由两部分操作组成

​ 一部分是把大事务拆分成若干个小事务,将整个分布式事务T分解为n个子事务,我们命名为T1,T2,…,Ti,…,Tn。每个子事务都应该、或者能被看作是原子行为。如果分布式事务T能够正常提交,那么它对数据的影响(最终一致性)就应该与连续按顺序成功提交子事务Ti等价。

​ 另一部分是为每一个子事务设计对应的补偿动作,我们命名为C1,C2,…,Ci,…,Cn。Ti与Ci必须满足以下条件:

如果T1到Tn均成功提交,那么事务就可以顺利完成。否则,就要采取以下两种恢复策略之一:

​ 与TCC相比,SAGA不需要为资源设计冻结状态和撤销冻结的操作,补偿操作往往要比冻结操作容易实现得多。

​ 以在前面提到的账户余额直接在银行维护的场景,从银行划转货款到业务系统中,这步是经由用户支付操作(扫码或U盾)来促使银行提供服务;如果后续业务操作失败,尽管无法要求银行撤销掉之前的用户转账操作,但是作为补偿措施,可以让业务系统将货款转回到用户账上,却是完全可行的。

​ SAGA必须保证所有子事务都能够提交或者补偿,但SAGA系统本身也有可能会崩溃,所以它必须设计成与数据库类似的日志机制(被称为SAGA Log),以保证系统恢复后可以追踪到子事务的执行情况,比如执行都到哪一步或者补偿到哪一步了。

​ 另外还要注意,尽管补偿操作通常比冻结/撤销更容易实现,但要保证正向、反向恢复过程能严谨地进行,也需要花费不少的工夫。比如,可能需要通过服务编排、可靠事件队列等方式来完成。所以,SAGA事务通常也不会直接靠裸编码来实现,一般也是在事务中间件的基础上完成。例如Seata就同样支持SAGA事务模式。

​ SAGA基于数据补偿来代替回滚的思路,也可以应用在其他事务方案上。举个例子,阿里的GTS(Global Transaction Service,Seata由GTS开源而来)所提出的“AT事务模式open in new window”就是这样的一种应用

(2)AT事务

​ 从整体上看,AT事务是参照了XA两段提交协议来实现的,但针对XA 2PC的缺陷,即在准备阶段,必须等待所有数据源都返回成功后,协调者才能统一发出Commit命令而导致的木桶效应(所有涉及到的锁和资源,都需要等到最慢的事务完成后才能统一释放),AT事务也设计了针对性的解决方案open in new window

​ 它大致的做法是在业务数据提交时,自动拦截所有SQL,分别保存SQL对数据修改前后结果的快照,生成行锁,通过本地事务一起提交到操作的数据源中,这就相当于自动记录了重做和回滚日志。

​ 如果分布式事务成功提交了,那么我们只需清理每个数据源中对应的日志数据即可;而如果分布式事务需要回滚,就要根据日志数据自动产生用于补偿的“逆向SQL”。

​ 所以,基于这种补偿方式,分布式事务中所涉及的每一个数据源都可以单独提交,然后立刻释放锁和资源。AT事务这种异步提交的模式,相比2PC极大地提升了系统的吞吐量水平。**而使用的代价就是大幅度地牺牲了隔离性,甚至直接影响到了原子性。**因为在缺乏隔离性的前提下,以补偿代替回滚不一定总能成功。

​ 比如,当在本地事务提交之后、分布式事务完成之前,该数据被补偿之前又被其他操作修改过,即出现了脏写(Dirty Wirte),而这个时候一旦出现分布式事务需要回滚,就不可能再通过自动的逆向SQL来实现补偿,只能由人工介入处理了。一般来说,对于脏写是一定要避免的,所有传统关系数据库在最低的隔离级别上,都仍然要加锁以避免脏写。因为脏写情况一旦发生,人工其实也很难进行有效处理。

​ 所以,GTS增加了一个“全局锁”(Global Lock)的机制来实现写隔离,要求本地事务提交之前,一定要先拿到针对修改记录的全局锁后才允许提交,而在没有获得全局锁之前就必须一直等待。这种设计以牺牲一定性能为代价,避免了在两个分布式事务中,数据被同一个本地事务改写的情况,从而避免了脏写。

​ 另外,在读隔离方面,AT事务默认的隔离级别是读未提交(Read Uncommitted),这意味着可能会产生脏读(Dirty Read)。读隔离也可以采用全局锁的方案来解决,但直接阻塞读取的话,要付出的代价就非常大了,一般并不会这样做。

​ 至此,分布式事务中并没有能一揽子包治百病的解决办法,只有因地制宜地选用合适的事务处理方案,才是唯一有效的做法。

4.基于消息补偿的最终一致方案

实现思路

​ 2PC和3PC核心思想均是以集中式的方式实现分布式事务,这两种方法都存在两个共同的缺点:1.同步执行性能差(执行缓慢、并发低);2.存在数据不一致问题。为了解决这两个问题,引入分布式消息来确保事务最终一致性的方案。

​ 在eBay的分布式系统架构中,架构师解决一致性问题的核心思想就是:将需要分布式处理的事务通过消息或者日志的方式异步执行,消息或日志可以存到本地文件、数据库或消息队列中,再通过业务规则进行失败重试。这个案例,就是使用基于分布式消息的最终一致性方案解决了分布式事务的问题。基于分布式消息的最终一致性方案的事务处理,引入了一个消息中间件(在本案例中,例如采用Message Queue,MQ,消息队列),用于在多个应用之间进行消息传递。实际使用中,阿里就是采用RocketMQ 机制来支持消息事务。

image-20240712190624852

​ 以网上购物为例。假设用户A在某电商平台下了一个订单,需要支付50元,发现自己的账户余额共150元,就使用余额支付,支付成功之后,订单状态修改为支付成功,然后通知仓库发货。在该事务中,涉及到了订单系统、支付系统、仓库系统,这三个系统是相互独立的应用,通过远程服务进行调用

​ 像是下订单和是使用优惠券的场景中,它要求数据强一致,在同一个操作时限中要么都成功要么都不成功。而在这个分布式事务场景中,创建订单、支付、仓库系统这三个数据操作对数据的一致性要求并没有那么高,例如订单创建成功后一些支付和物流信息可以晚点再更新,只要确保经过一段时间的延迟之后,最终订单数据和其他支付、仓库数据保持一致即可。

image-20240712190720572

​ 基于分布式消息的最终一致性方案,用户A通过终端手机首先在订单系统上操作,通过消息队列完成整个购物流程,整个购物的流程如下所示

image-20240712190944981

在上述过程中,可能会产生如下异常情况,其对应的解决方案为:

​ 基于分布式消息的最终一致性方案采用消息传递机制,并使用异步通信的方式,避免了通信阻塞,从而增加系统的吞吐量。同时,这种方案还可以屏蔽不同系统的协议规范,使其可以直接交互。

​ 在不需要请求立即返回结果的场景下, 这些特性就带来了明显的通信优势,并且通过引入消息中间件,实现了消息生成方(如上述的订单系统)本地事务和消息发送的原子性,采用最终一致性的方式,只需保证数据最终一致即可,一定程度上解决了二阶段和三阶段方法要保证强一致性而在某些情况导致的数据不一致问题。

​ 可以看出,分布式事务中,当且仅当所有的事务均成功时整个流程才成功。所以,分布式事务的一致性是实现分布式事务的关键问题,目前来看还没有一种很简单、完美的方案可以应对所有场景。

案例分析

​ 以下单减库存为例分析基于消息补偿的最终一致方案的实现思路:

image-20240715100046547

(1)系统收到下单请求,将订单业务数据存入到订单库中,并且同时存储该订单对应的消息数据,比如购买商品的 ID 和数量,消息数据与订单库为同一库,更新订单和存储消息为一个本地事务,要么都成功,要么都失败。

(2)库存服务通过消息中间件收到库存更新消息,调用库存服务进行业务操作,同时返回业务处理结果。

(3)消息生产方,也就是订单服务收到处理结果后,将本地消息表的数据删除或者设置为已完成。

(4)设置异步任务,定时去扫描本地消息表,发现有未完成的任务则重试,保证最终一致性。

分布式事务实现对比

​ 无论是哪种分布式事务方法,其实都是把一个分布式事务,拆分成多个本地事务。**本地事务可以用数据库事务来解决,分布式事务则专注于解决如何让这些本地事务保持一致的问题。**在遇到分布式一致性问题的时候,也要基于这个思想来考虑问题,再结合实际的情况选择分布式事务的方法

2PC:

​ 2PC方式实现的事务概念简单易懂且容易实现,使用的是强一致的设计,可以保证原子性和隔离性。但存在同步性能阻塞问题和数据不一致问题适用于对数据一致性要求较高、但并发量不大的场景

3PC:

​ 3PC的实现方式是基于2PC的优化版本,但仍然存在同步性能阻塞问题和数据不一致问题

TCC:

​ TCC可以提前预定事务执行需锁定的资源,较少业务锁定的粒度。它可以使用普通事务即可完成分布式事务协调,因此相对地TCC的性能很好。但是,提交最终事务和回滚逻辑都需要支持幂等,为此需要人工要投入的精力也更多。它适用于需要强隔离性的分布式事务中

​ 对比2PC实现方式,参考如下图所示。其核心区别在于:

image-20240715103657100

​ TCC 的核心思想是针对每个业务操作,都要添加一个与其对应的确认和补偿操作,同时把相关的处理,从数据库转移到业务中,以此实现跨数据库的事务

三种实现方式对比

image-20240712191446792

分布式事务扩展

刚性事务和柔性事务

总结来讲,与刚性事务不同,柔性事务允许一定时间内,数据不一致,但要求最终一致。而柔性事务的最终一致性,遵循的是BASE理论

​ eBay 公司的工程师 Dan Pritchett曾提出了一种分布式存储系统的设计模式——BASE理论。 BASE理论包括基本可用(Basically Available)、柔性状态(Soft State)和最终一致性(Eventual Consistency)。

BASE理论为了支持大型分布式系统,通过牺牲强一致性,保证最终一致性,来获得高可用性,是对ACID原则的弱化。ACID 与 BASE 是对一致性和可用性的权衡所产生的不同结果,但二者都保证了数据的持久性。ACID 选择了强一致性而放弃了系统的可用性。与ACID原则不同的是,BASE理论保证了系统的可用性,允许数据在一段时间内可以不一致,最终达到一致状态即可,也即牺牲了部分的数据一致性,选择了最终一致性。

具体到今天的三种分布式事务实现方式,二阶段提交、三阶段提交方法,遵循的是ACID原则,而消息最终一致性方案遵循的就是BASE理论。

海量并发场景中分布式事务一致性问题

​ 在互联网分布式场景中,原本一个系统被拆分成多个子系统,要想完成一次写入操作,需要同时协调多个系统,这就带来了分布式事务的问题(分布式事务是指:一次大的操作由多个小操作组成,这些小的操作分布在不同的服务器上,分布式事务需要保证这些小操作要么全部成功,要么全部失败)。那怎么设计才能实现系统之间的事务一致性呢? =》先从解决分布式事务问题出发剖析解决方案,再结合高并发业务场景拆解实际应用,而不局限于纸上谈兵

​ 以京东旅行系统为例,早期的交易系统是通过 .NET 实现的,所有的交易下单逻辑都写在一个独立的系统中。随着技术改造,用 Java 重写了核心系统,原本的系统也被拆分成多个子系统,如商品系统、促销系统、订单系统等。当用户下单时,订单系统生成订单,商品系统扣减库存,促销系统扣减优惠券,只有当三个系统的事务都提交之后,才认为此次下单成功,否则失败。

​ 可以先介绍目前主流实现分布式系统事务一致性的方案(也就是基于 MQ 的可靠消息投递的机制)然后回答出可实现方案和关键知识点。为进一步交流,可以扩展提出 2PC 或 TCC 。因为 2PC 或 TCC 在工业界落地代价很大,不适合互联网场景,所以只有少部分的强一致性业务场景(如金融支付领域)会基于这两种方案实现,可以进一步围绕它们的解决思路和方案弊端去引申问题

评论
  • 按正序
  • 按倒序
  • 按热度
Powered by Waline v3.1.3