目录
一、分布式事务的问题
- 复习本地事务
- 了解分布式事务问题
1. 本地事务
事务概念：即传统的单机事务，是数据库的概念，表示由一个或多个操作组成的一个业务。比如：银行转账
事务作用：组成事务的多个操作单元，在操作数据库时，要成功都成功，要失败都失败
事务特性：ACID
事务操作，底层会对数据加锁，会影响操作性能
如果多个数据库操作要想属于同一个事务进行管理：就必须使用同一个数据库连接Connection对象
2. 分布式事务
介绍
在分布式环境上同样需要事务来保证数据的一致性。而因为跨数据源或跨服务环境所导致的传统事务不可用，形成的新的事务需求，这样的事务叫分布式事务。
传统事务中，要想让多个操作属于同一事务，就需要使用同一个数据库连接
Connection对象。但是在分布式环境下，通常是做不到这一点的，必须使用分布式事务。比如：
跨数据源的分布式事务：程序要操作不同服务器上的数据库
跨服务的分布式事务：程序要调用多个服务，每个服务都要操作数据库
综合情况
示例场景
电商行业中比较常见的下单付款案例，包括下面几个行为：
创建新订单
扣减商品库存
从用户账户余额扣除金额
要完成上面的操作，需要访问三个不同的微服务和三个不同的数据库，如图：
订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。
但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务要解决的问题了
3. 分布式事务的问题演示
准备数据库
使用SQLyog执行SQL脚本《seata-demo.sql》，初始化数据库
导入演示项目
资料里提供了《seata-demo》项目，把这个项目拷贝到你的工作空间目录里
用idea打开这个项目
启动服务
启动nacos
启动所有微服务
测试下单功能
使用Postman发请求下单
请求路径是：http://localhost:8082/order
请求方式是：POST
表单参数是：
userId：user202103032042012
commodityCode：100202003032041
count：20
money：200
最终结果是：因为库存量不够，导致扣减库存失败，但是用户的帐户余额已经扣减了。已经出现了分布式事务问题
4. 小结
分布式事务：
跨数据源的事务
跨服务的事务
以上综合
分布式事务要求：
无论是跨数据源还是跨服务，都要做到：要么一起成功，要么一起失败
二、CAP定理和BASE理论【面试】
- 能描述CAP定理
- 理解BASE理论
分布式事务问题的处理，其实就是在数据的一致性与服务的可用性之间做一个权衡：
如果要保证所有子事务的数据一致性：就要舍弃一些服务的可用性。因为数据库事务会对数据行加锁
如果要保证所有服务的可用性：就要考虑一下数据的一致性如何处理
解决分布式事务问题，需要一些分布式系统的基础知识作为理论指导
CAP定理
1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。 Eric Brewer 说，这三个指标不可能同时做到，这个结论就叫做 CAP 定理。
CAP三指标介绍
1.C一致性
一致性Consitency，即 用户访问分布式系统中的任意节点，得到的数据必须一致(业务上的一致）。这就要求节点之间必须要及时同步数据。
比如：集群中有两个节点，初始数据是一致的；当修改了其中一个节点的数据时，要把数据变更立即同步到另外一个节点，保证所有节点的数据是一致的。
2.A可用性
可用性Availability，即 用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
3.P分区容错性
分区Partition：因为网络故障或者其它原因，导致分布式系统中的部分节点与其它节点失联，形成独立分区。
分区容错性Partition Tolerance，即 集群出现分区时，整个系统也要持续对外提供服务
CAP的矛盾
在分布式系统中，分区容错性(P)是必须要保证的。但C和A两个指标就互相矛盾
以上图为例：
因为网络原因形成了两个分区：node01和node02一个分区；node03一个分区
如果我们要修改node02上的数据：
如果要追求一致性：必须等到node02把数据同步到node01、node03，才返回响应。但因为分区了，等待时间不确定，可能要长时间等待==>追求一致性C，舍弃了可用性A
如果要追求可用性：修改了node02的数据就立即返回响应；不能保证数据同步到了node01和node03
追求了可用性A，舍弃了一致性C
所以CAP定理中，P必须保证，而C和A相互矛盾，只能保证一个。即：
CP模式：舍弃可用性，追求一致性
AP模式：舍弃一致性，追求可用性
但是，难道这个AC矛盾就不可调和的吗？并不是，BASE理论就提出了完善和弥补的方案
BASE理论BASE理论，是对CAP定理中的CA矛盾进行权衡之后，提供的一种解决思路。这是指：
采用CP模式，追求一致性，舍弃一定的可用性：
BA (Basically Available)，基本可用：分布式系统在出现故障时，允许损失部分可用性，要保证核心可用
响应时间的损失：比如原本要求0.5秒内响应，现在允许5秒内响应
系统功能的损失：出现某些故障时，核心功能保证可用，部分非核心功能允许不可用
采用AP模式，追求可用性，对一致性采用一些补偿措施
S (Soft State)，软状态：在一定时间内，允许出现中间状态，比如 数据临时不一致
E (Eventually Consistent)，最终一致性：虽然无法保证强一致性，但是在软状态之后，最终达到数据一致
分布式事务的解决思路解决思路
分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论。有两种解决思路：
AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。
几个概念
分支事务RM：在整个业务中，每一个子系统的事务，称为一个分支事务。对应@Transactional
全局事务TM：一个完整的业务，需要众多分支事务共同组成一个全局事务。对应@GlobalTransactional
事务协调者TC：用于在整个全局事务里，管理、协调各个分支事务的状态。对应Seata软件
小结
什么是CAP定理：
理解CAP
C：一致性。访问系统里任意一个节点，得到的数据必须是一致的
A：可用性。访问系统里任意一个健康节点，都要立即返回响应，不能阻塞、不能拒绝
P：分区容错性。如果系统出现分区（某些节点失联），整个系统必须仍然能够正常提供服务
CAP定理：
一个分布式系统最多只能做到CAP三个指标里的两个指标
通常情况下，P是必须要满足的；然后A和C是矛盾的
如果要追求A可用性：访问任意节点立即必须返回响应，就不能保证数据已经同步完成了。一致性不保证
如果要追求C一致性：访问任意节点必须得到相同数据，就必须等待数据同步完成才能响应。可用性低了
什么是BASE理论：
BASE理论是对CAP矛盾提出的一种解决思路
BA：追求CP一致性，允许舍弃一定的可用性，只要做到基本可用BA即可
允许响应时间稍有延长，允许非核心功能暂不可用
SE：追求AP可用性，允许存在临时不一致的状态，只要做到最终一致即可
S：软状态，表示数据临时不一致的状态
E：最终一致，在一定时间内最终达到了数据的一致
分布式事务的解决思路：
借鉴Base理论
相关的一些概念：
RM：Resource Manager，分支事务。对应代码里的@Transactional
TM：Transaction Manager，全局事务。对应代码里的@GlobalTransactional
TC：Transaction Coordinater，事务协调者，对所有分支事务进行协调管理的。对应软件Seata
三、Seata入门与整合
- 了解Seata架构相关的角色
- 能够安装部署Seata
- 能够将微服务与Seata集成
1.Seata简介
Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。
官网地址：http://seata.io/，其中的文档、博客中提供了大量的使用说明、源码分析。
2.Seata架构
Seata事务管理中有三个重要的角色：
TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
是Seata本身
TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开启全局事务、提交或回滚全局事务。
负责事务的边界。@GlobalTransactional
RM (Resource Manager) - 资源管理器：处理分支事务的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。@Transactional
分支事务
最低0.47元/天 解锁文章
扫一扫
2145
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
