分布式事务

本文探讨了分布式事务中的刚性事务(满足ACID特性)与柔性事务(如BASE理论指导下的设计),比较了2PC和TCC/TCC模型,以及如何通过Saga模型实现分布式事务的最终一致性。重点阐述了在高可用性和性能需求下,BASE理论对强一致性妥协的策略。
摘要由CSDN通过智能技术生成

分布式事务

分布式事务分类:

A(原子性):原子性意味着事务的所有操作要么全部完成,要么全部不完成,不可部分完成。
C(一致性):一致性确保数据库从一个一致状态切换到另一个一致状态。
I(隔离性):隔离性保证事务的执行不会受到未完成事务的影响,即事务之间相互隔离
D(持久性):持久性意味着一旦事务完成,其结果将永久保存在数据库中。

刚性事务:满足ACID的就是刚性事务

C(一致性):指的是多个节点上的数据副本必须保持一致,即系统保证所有节点访问共享数据时都能看到同样的数据视图。
A(可用性):意味着系统必须在任何时候都能够响应客户端请求,即系统始终处于服务状态,能够处理用户的操作请求。
P(分区容错性):指的是系统必须能够容忍分布式系统中的某些节点或网络分区出现故障或延迟,即在网络分区的情况下,系统仍能保证一定程度的正常运行。

Base理论:是对分布式系统中一致性和可用性之间权衡的一种理论指导,它是在CAP定理的基础上发展起来的。BASE理论的核心思想是:由于强一致性难以实现或代价太高,系统可以在保证分区容错性的前提下,通过牺牲强一致性来提高可用性和性能,最终实现数据的一致性。

BASE理论包含三个基本要素:
1.基本可用性(Basically Available):指在系统出现故障或部分失效的情况下,系统仍然可以保证基本的可用性,允许系统在出现故障时不完全一致,但仍能提供基本服务。
2.软状态(Soft State):允许系统中的数据存在中间状态,这些中间状态的存在不会影响系统的整体可用性,允许系统在不同节点的数据副本之间进行数据同步的过程中存在延时。
3.最终一致性(Eventually Consistent):强调所有的数据副本在经过一段时间的同步之后,最终都能达到一个一致的状态,这意味着虽然某一时刻数据可能不一致,但系统会尽力保证最终所有节点达到一致性。

BASE理论与ACID事务模型(原子性、一致性、隔离性、持久性)形成对比,ACID要求数据在所有时刻保持一致性,而BASE则接受短暂的不一致以达到更高的可用性和性能。BASE理论适用于大型分布式系统和互联网应用,其中高可用性和可伸缩性比强一致性更为重要。

柔性事务:满足CAP或者Base理论的就是柔性事务

刚性事务


强一致性:各个业务操作必须在事务结束时全部成功,或者全部失败
XA模型
满足CAP理论的CP

满足传统事务特性
	ACID(原子性,一致性,隔离性,持久性)
	
满足XA模型
	应用程序(AP):定义事务边界(事务开始与结束),并且访问事务边界内的资源
	资源管理器(RM):管理计算机共享的资源,资源即数据库
	事务管理器(TM):负责管理全局事务,分配全局事务ID,监测事务的执行速度,并负责事务的提交,回滚,失败恢复等。
	
2PC(两阶段提交)是XA规范标准实现
实现过程:

AP发起一个全局事务,并且创建一个全局事务ID
TM发起prepare投票,RM对投票进行表决
RM都同意后,TM发起commit提交。其中任何一个prepare时不同意,TM都会发起rollback。
在commit过程中,发生宕机等异常,在服务重启后根据XA recover再次进行补偿,保证最终commit操作成功。
缺点:

同步阻塞模型
数据库资源锁定时间过程
全局锁(隔离级别串行化),并发能力低
不适合长事务
在一些异常情况下会有问题,在commit之后,回复给TM的ack丢失了,这时会导致TM不知道commit到底是否成功了,从而衍生出了三阶段提交来解决这个问题。

柔性事务


保证最终一致性,事务结束后在可接受的时间范围内,可能出现短暂的不一致,最终会达成一致性
满足CAP理论的AP,满足BASE理论

满足CAP模型的CP,柔性事务是对XA协议的妥协,它通过降低强一致性,从而减少数据库资源的锁定时间,提升系统可用性。
典型架构实现
	TCC模型
	Saga模型
1.TCC
TCC模型完全交由业务端实现,每个子业务都需要实现try-confirm-cancel接口,对业务侵入性很大。
资源锁定需要业务自主实现。

	Try:尝试执行事务,完成业务检查,预留必要的资源。
	confirm:真正执行业务,不做业务资源检查
	cancel:释放try阶段预留的业务资源
2.Saga
	Saga模型把一个分布式事务拆分成多个本地事务,每个本地事务都有对应的执行模块和补偿模块(对应TCC的confirm和cancel),当任何一个事务失败时,可以通过调用补偿模块来进行恢复,达到事务最终一致性。
	Saga事务隔离性,业务层自己处理,通过冻结资源或者应用层加锁
	
	Saga补偿方式:
	向后恢复:补偿所有已完成的事务,本质就是所有已完成的本地事务进行回滚操作
	向前恢复:重试失败的事务,假设每个子事务最终都会成功

1.分布式事务产生的背景是:一个业务功能涉及操作多个具有独立数据库和缓存的服务。
2.分布式事务分类:
	刚性事务:所有业务操作在事务结束是要么全部成功,要么全部失败,强一致性,并发低。
	柔性事务:可接受时间范围内,允许出现短暂的不一致性,最终达成一致性。
3.2PC两阶段提交:AP发起一个全局事务,TM发起一个prepare请求,RM在prepare阶段都执行成功,TM发起commit请求。在prepare阶段人意RM执行失败,TM发起rollback操作。
4.TCC主要涵盖try-confirm-cancel操作,这些操作都需要业务实现,堆业务侵入性比较大,而且比saga多一个提交阶段。
5.Saga是目前行业内落地较多的成功方案,由业务提供一个业务执行接口和一个补偿接口(需要满足幂等性)
	事务开启入口方法,开始一个aop环形切面,在方法调用前分配一个全局唯一事务ID,记录到数据库中并且初始化状态为开始。
	调用每个业务操作时,记录业务请求的参数,事务提交方法和回滚方法信息。
	所有业务操作正常执行完后,在aop环形切面的后置处理中把全局事务的状态修改为成功。
	业务操作中任何一个失败了时抛出异常,捕捉到异常后全局事务标示为失败,返回请求放失败。异步线程通过记录的补偿方法进行事务组向前回滚。
  • 10
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值