103:分布式事务基础设施理论
1 分布式基础设施理论基本的概述
课题内容
- 如何理解分布式事务产生的背景
- 如何理解Base与CAP分布式理论
- 分布式事务常用框架
2 传统项目分布式事务产生的背景
案例:顺丰上门取件/点外卖
下单–订单表
派单—派单表 orderId 对应userId
分布式事务产生的背景
- 如果在传统项目中,使用同一个数据源,数据库用同一个事务管理器的情况下,不存在分布式事务问题,因为有事务的传播行为帮助实现。
- 如果在单体项目中,存在多个不同的数据源,每个数据源都有自己独立的事务管理器,每个事务管理器互不影响,也会存在分布式事务问题。
解决:jta+atomikos,将每个独立的事务管理器统一交给atomikos全局事务管理。
3 RPC通讯的分布式事务产生的背景
- 在分布式系统中采用rpc远程通讯也会存在分布式事务问题。
Rpc通讯中产生的分布式事务问题的原因
1.调用方(订单服务)调用完rpc接口之后,突然程序抛出异常,调用方的事务回滚了,但是被调用方接口没有回滚,即订单服务回滚了,而派单成功。
在每个jvm中都有自己的本地事务,每个事务都互不影响。
2.被调用方(派单服务)的接口失败的话,调用方可以根据返回的结果,手动回滚调用方本地事务。
4 CAP与Base的基本设施理论
Base理论和CAP理论
CAP理论
针对分布式系统的CAP原理包含如下三个元素:
C:Consistency,一致性。在分布式系统中的所有数据备份,在同一时刻具有同样的值,所有节点在同一时刻读取的数据都是最新的数据副本。
A:Availability,可用性,好的响应性能。完全的可用性指的是在任何故障模型下,服务都会在有限的时间内处理完成并进行响应。
P:Partition tolerance,分区容忍性。尽管网络上有部分消息丢失,但系统仍然可继续工作。
**CAP原理指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。**对于分布式数据系统,分区容忍性是基本要求,否则就失去了价值。因此设计分布式数据系统,就是在一致性和可用性之间取一个平衡。对于大多数web应用,其实并不需要强一致性,因此牺牲一致性而换取高可用性,是目前多数分布式数据库产品的方向。不再要求关系型数据库中的强一致性,而是只要系统能达到最终一致性即可。
CAP总结:CAP三者无法兼顾,在分布式系统当中可以容忍网络之间出现的通讯故障P; 采用CP或者AP形式。
CP:当网络出现故障之后,只能保证数据一致性,但是不能保证可用性;zk
AP:当网络出现故障之后,不能保证数据一致性,但是能够保证可用性;eureka
BASE理论
Basically Available(基本可用)、Soft-state(软状态/柔性事务)、Eventual Consistency(最终一致性)。是基于CAP定理演化而来,是对CAP中一致性和可用性权衡的结果。
核心思想:即使无法做到强一致性,但每个业务根据自身的特点,采用适当的方式来使系统达到最终一致性。
1、基本可用:指分布式系统在出现故障的时候,允许损失部分可用性,保证核心可用。但不等价于不可用。
2、软状态:软状态是指允许系统存在中间状态,并且该中间状态不会影响系统整体可用性。
3、最终一致性:
系统中的所有数据副本经过一定时间后,最终能够达到一致的状态,不需要实时保证系统数据的强一致性。
5 分布式事务最终一致性的概念
事务特性ACID
原子性(Atomicity)
原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚。
一致性(Consistency)
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态。
隔离性(Isolation)
隔离性是当多个用户并发访问数据库时,比如操作同一张表时,数据库为每一个用户开启的事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离。
持久性(Durability)
持久性是指一个事务一旦被提交了,那么对数据库中的数据的改变就是永久性的。
begin—调用数据库层,对该数据上行锁,其他的线程不能够对该行数据做操作
commit/rollback—删除行锁
注意:在分布式系统中无法保证强一致性,因为数据短暂不一致是允许的,但是最终数据一定要保证一致性。
6 分布式事务流行的解决框架
目前主流分布式解决框架
- 单体项目多数据源 使用jta+atomikos
- 基于rabbitmq的形式解决 最终一致性的思想
- 基于rocketmq解决分布式事务 核心采用自带事务消息
- 基于LCN模式解决分布式事务 tcc/txc/lcn模式 核心思想:假关闭连接(目前已经被淘汰)
- 基于Alibaba的Seata 背景非常强大,未来可能是主流