分布式事务
1.概述
在分布式环境下,出现的事务问题
2.种类
多服务单数据库
3.分布式理论
1.CAP定理
-
Consistency(一致性) 用户访问分布式系统中的任意节点,得到的数据必须一致。
-
Availability(可用性) 用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝。
-
Partition tolerance (分区容错性)
Partition(分区):因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接,形成独立分区。
Tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务。容忍出现分区的问题
在分布式环境下,这三个指标不可能同时做到,且P是一定要保证的
为什么 P 一定要保证?
因为网络是不可靠的。客户因素,没办法避免
CP:在一定时间内,等待集群节点进行数据同步后,对外提供访问
AP:在任何时间内,都对外访问,但是得到的数据可能不一样
CA:反证法,不能同时出现,多个节点要想数据一致,需要时间同步。那么在这个时间内,一定不能对外访问,所以A不成立。如果可以对外访问,那么数据就不一致,所以C就不成立了,如果一定要满足CA,那就没有P,也就不是分布式环境了,是单节点。
2.BASE理论
对CAP的一种补充,放弃强一致性,追求最终一致性
三个思想:
Basically Available(基本可用)
分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。
Soft State(软状态)
在一定时间内,允许出现中间状态,比如临时的不一致状态。
Eventually Consistent(最终一致性):
虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。
分布式事务的解决思路:
AP模式:最终一致性
各子事务分别执行和提交,允许出现结果不一致,然后采用弥补措施恢复数据即可,实现最终一致。
CP模式:强一致性
各个子事务执行后互相等待,同时提交,同时回滚,达成强一致。但事务等待过程中,处于弱可用状态。
子事务:分支事务
全局事务:事务协调者,用来监控和通知各个分支事务
4.Seata
seata 中三个主要架构分别是:
-
TC (Transaction Coordinator):事务协调者。负责维护全局和分支事务的状态,协调全局事务提交或回滚。监控和通知各个事务,包括分支事务和全局事务。
-
TM (Transaction Manager) :是事务管理器。定义全局事务的范围、开始全局事务、提交或回滚全局事务。执行事务。
-
RM (Resource Manager):资源管理器。管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
XA模式
XA模型的优点是:事务是强一致性的,满足ACID的原则,实现比较简单,没有代码侵入
缺点是:必须要拿到所有数据源,而且数据源还要支持XA协议。目前MySQL中只有InnoDB存储引擎支持XA协议。因为一阶段需要锁定数据库资源,等待二阶段结束才释放,性能比较差,要把所有涉及到的数据都要锁定,是强一致性的,所以会产生长事务。
使用XA只需要导入依赖,加上配置信息以及加上@GlobalTransactional注解即可。
AT模式
TM会先告知TC开启全局事务,然后调用分支RM,RM将分支事务注册到TC。然后RM会执行sql并直接提交,这个时候就会记录更新前后的快照,并将快照保存到 undo log表中,接着会将事务状态报告给TC。到TM向TC发起提交或回滚全局事务时,TC会检查分支的事务状态,然后决定时提交还是回滚。如果是提交,就会删除undo log表中记录的这条快照,如果是回滚,就会去恢复undo log表中更新前的快照信息。
2PC
2PC就是标准的XA模型,它就是二阶段提交,是XA规范定义的 数据一致性协议。
二阶段提交协议将节点分为:
-
协调者角色(事务管理器)
-
参与者角色(资源管理器)
2PC角色中,事务管理器的角色,负责协调多个数据库(资源管理器)的事务,
协调者角色(事务管理器Coordinator),负责向参与者发送指令,收集参与者反馈,做出提交或者回滚决策 参与者角色(资源管理器Participant),接收协调者的指令执行事务操作,向协调者反馈操作结果,并继续执行协调者发送的最终指令
3PC
三阶段提交(3PC)协议对 2PC协议的一种扩展。
针对2PC的缺点,研究者提出了3PC,即Three-Phase Commit。
作为2PC的改进版,3PC将原有的两阶段过程,重新划分为CanCommit、PreCommit和do Commit三个阶段。
3PC 协议将 2PC 协议的准备阶段一分为二,从而形成了三个阶段:
所谓的三个阶段分别是:询问,然后再锁资源,最后真正提交

浙公网安备 33010602011771号