- E(Eventually Consistent):最终一致性
这个理论的核心思想便是:如果我们如法做到强一致性,那么每个应用都应该根据自身的业务特点,采用适当的方式来使系统达到最终一致性。
出现场景
====
让我们回到分布式事务中来,什么时候会出现分布式事务呢?
场景1: 虽然时单体的架构服务,但由于在分库的情况下,依然会导致分布式事务的情况,因此单体服务不会出现分布式事务的这种说法,破~
场景2: 分布式架构下,两个服务之间相互调用,虽然使用的是同一个数据库,但是还是会出现分布式事务。谁让你使用的是分布式架构呢~
场景3: 分布式架构下,两个服务之间相互调用,使用的是不用的数据库,这种情况下肯定会出现分布式事务的问题,想都不用想!
解决方法
====
有问题的地方便会有方法,当然也不一定,但是在这里,分布式事务问题确实有解决的方法, 如果没有,小菜也不会写这篇文章来自讨苦吃了!
方法一:全局事务
========
不知道这里该说 全局事务 会让你比较熟悉,还是 两阶段提交(2PC) 会让你比较熟悉,还是说都不熟悉~,不熟悉也没关系,小菜带你熟悉熟悉!
全局事务是基于DTP模型实现的,它规定了要实现分布式事务需要三种角色:
-
AP(Application):应用系统(微服务)
-
TM(Transaction Manager):事务管理器(全局事务管理)
-
RM(Resource Manager):资源管理器(数据库)
除了 AP 这个角色,我们多认识了其他两个同学分别是事务管理器和资源管理器,那么他们起到什么作用呢,那我们就得看,这个两阶段提交是哪两阶段了!
阶段1 :表决阶段
=========
所有参与者都将自己的事务进行预提交,并将能否成功的信息反馈给协调者
-
事务管理器发一个 prepare 指令给 A 和 B 两个服务器
-
A 和 B 两个服务器收到消息后,根据自身情况,判断自己是否可以提交事务
-
将处理结果记录到资源管理器中
-
将处理结果返回给事务管理器
阶段2 :执行阶段
=========
协调者根据所有参与者的反馈,通知所有参与者,步调一致地执行提交或者回滚
-
事务管理器向 A 和 B 两个服务器发送提交指令
-
A 和 B 两个服务器收到指令后,将自己本身事务提交
-
将处理结果记录到资源管理器
-
将处理结果返回给事务管理器
这就是两阶段提交的大致过程,它提高了数据一致性的概率,实现成本较低。但是这种实现方式带来的缺点也是很明显的!
-
单点故障:如果事务管理器出现了故障,整个系统将不可