🍬博主介绍
👨🎓 博主主页:喵的主页
✨主攻领域:【大数据】【java】【python】【面试分析】
分布式事务
只用你能听懂的方式来讲
1. 分布式事务介绍
对一个数据库进行操作。但是当业务越来越复杂,数据量越来越大的时候,将会进行分库分表。特别是在微服务的场景下,每个服务都有自己的数据库。之前的单体事务无法处理跨库事务,这需要分布式事务来处理。
2. 分布式事务的重要性
案例流程演示
画图介绍
1)上图为下订单的一个流程,下订单成功后,从账户扣余额,从库存扣除商品数量
2)模拟在下单后,从账户扣除余额,但是在到减除库存时由于某种原因抛出异常
3)订单创建成功,账户余额扣除成功,但是库存回滚了没有扣除成功,发现管理单体事务的 @Transactional 在当前分布式事务中场景下并没有生效。没有让各个操作一起完成或一起失败。
所以分布式事务很重要
3. 分布式事务的 CAP 定理
CAP 原则又称 CAP 定理,又被称为布鲁尔定理(Brewer’s theorem),指的是在一个分布式系统中,不可能同时满足以下三点:
一致性(Consistency)
在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
可用性(Availability)
在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
分区容错性(Partition tolerance)
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区(partition)。 分区容错的意思是,区间通信可能失败。比如,一台服务器放在中国,另一台服务 器放在美国,这就是两个区,它们之间可能无法通信。
一般来说,分区容错无法避免,因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们, 剩下的 C 和 A 无法同时做到。
为什么P是总成立的呢? 又为什么C 和 A 无法同时做到呢?
- 假设你公司有两个数据中心,北京一个,纽约一个,这个就是P,它是总成立的;
- 满足了C(一致性),就没法保证A(可用性),假如 北京 和 纽约网络出现了异常,数据不能同步了,那为了保证我的数据一致性,我必须停掉我一个中心对外提供服务,那就是要牺牲掉我一个中心的可用性了。
- 同样的道理,如果出现了第2点的情况,我要保障我的A(可用性)那必然数据是C(不一致)的。
补充知识:
现在大部分公司都要求服务可用性达到 99.9999%好多9啊,那必然要舍弃了C(一致性)了。
为了在C(一致性)和A(可用性)之间做权衡,就诞生了BASE理论。
3. BASE介绍
BASE模型包含个三个元素:
BA:Basically Available,基本可用
系统出现了不可预知的故障,但还是能用,相比较正常的系统而言会有响应时间上的损失和功能上的损失。
S:Soft State,软状态,状态可以有一段时间不同步
什么是软状态呢?相对于原子性而言,要求多个节点的数据副本都是一致的,这是一种“硬状态”。
软状态指的是:允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延时。
E:Eventually Consistent,最终一致,最终数据是一致的就可以了,而不是时时保持强一致。
上面说软状态,然后不可能一直是软状态,必须有个时间期限。在期限过后,应当保证所有副本保持数据一致性,从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。
5. 分布式事务两种方案
5.1 XA模式
数据库支持的 2PC【2 phase commit 二阶提交】,又叫做 XA Transactions。
MySQL 从 5.5 版本开始支持,SQL Server 2005 开始支持,Oracle 7 开始支持。 其中,XA 是一个两阶段提交协议,该协议分为以下两个阶段:
第一阶段:事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作,并反映是 否可以提交。
第二阶段:事务协调器要求每个数据库提交数据。 其中,如果有任何一个数据库否决此次提交,那么所有数据库都会被要求回滚它们在此事务 中的那部分信息。
优势
XA 模式比较简单,而且一旦商业数据库实现了 XA 协议,使用分布式事务的成本也比较低。
劣势
XA 性能不理想,特别是在交易下单链路,往往并发量很高,XA 无法满足高并发场景。
XA 目前在商业数据库支持的比较理想,在 mysql 数据库中支持的不太理想,mysql 的 XA 实现,没有记录 prepare 阶段日志,主备切换回导致主库与备库数据不一致。
许多 nosql 也没有支持 XA,这让 XA 的应用场景变得非常狭隘。
5.2 柔性事务-TCC 事务补偿型方案
TCC 的基本概念
TCC是Try-Confirm-Cancel 的简称:
Try阶段:
完成所有业务检查(一致性),预留业务资源(准隔离性)
Confirm阶段:
确认执行业务操作,不做任何业务检查, 只使用Try阶段预留的业务资源。
Cancel阶段:
取消Try阶段预留的业务资源。
5.3 XA和TCC的区别
XA是资源层面的分布式事务,强一致性,在两阶段提交的整个过程中,一直会持有资源的锁。
XA事务中的两阶段提交内部过程是对开发者屏蔽的,回顾我们之前讲解JTA规范时,通过UserTransaction的commit方法来提交全局事务,这只是一次方法调用,其内部会委派给TransactionManager进行真正的两阶段提交,因此开发者从代码层面是感知不到这个过程的。而事务管理器在两阶段提交过程中,从prepare到commit/rollback过程中,资源实际上一直都是被加锁的。如果有其他人需要更新这两条记录,那么就必须等待锁释放。
TCC是业务层面的分布式事务,最终一致性,不会一直持有资源的锁。
TCC中的两阶段提交并没有对开发者完全屏蔽,也就是说从代码层面,开发者是可以感受到两阶段提交的存在。开发者明显的感知到了两阶段提交过程的存在。try、confirm/cancel在执行过程中,一般都会开启各自的本地事务,来保证方法内部业务逻辑的ACID特性。