1.分布式事务问题
1.1.本地事务
本地事务，也就是传统的单机事务。在传统数据库事务中，必须要满足四个原则：A C I D
1.2.分布式事务
分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如：
- 跨数据源的分布式事务 - 跨服务的分布式事务 - 综合情况
在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例，包括下面几个行为：
- 创建新订单 - 扣减商品库存 - 从用户账户余额扣除金额
完成上面的操作需要访问三个不同的微服务和三个不同的数据库。
订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。
但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。
此时ACID难以满足，这是分布式事务要解决的问题
1.3.演示分布式事务问题
我们通过一个案例来演示分布式事务的问题：
微服务结构如下：
其中：
seata-demo：父工程，负责管理项目依赖
account-service：账户服务，负责管理用户的资金账户。提供扣减余额的接口
storage-service：库存服务，负责管理商品库存。提供扣减库存的接口
order-service：订单服务，负责管理订单。创建订单时，需要调用 account-service和storage-service
3）启动nacos、所有微服务
4）测试下单功能，发出Post请求：
请求如下：
http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=20&money=200
如图：
测试发现，当库存不足时，如果余额已经扣减，并不会回滚，出现了分布式事务问题。
2.理论基础
解决分布式事务问题，需要一些分布式系统的基础知识作为理论指导。
2.1.CAP定理
Consistency(一致性): 用户访问分布式系统中的任意节点，得到的数据必须一致 Availability（可用性）: 用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。 Partition(分区): 因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。 tolerance(容错): 在集群出现分区时，整个系统也要持续对外提供服务 ================结论: CP : 强一致性,弱可用性(牺牲部分机器的可用性,保证数据一致性) AP : 强可用性,弱一致性(牺牲一致性,保证可用性)
CAP详情跳转
2.2.BASE理论
BASE 理论是对 CAP 的一种解决思路，包含三个思想：
Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态） 在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
2.3.解决分布式事务的思路
分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：
AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。
但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：
这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。
3.初识Seata
Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。
官网中的文档、播客中提供了大量的使用说明、源码分析。
3.1.Seata的架构
Seata事务管理中有三个重要的角色：
TC (Transaction Coordinator) - 事务协调者维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
整体的架构如图：
Seata基于上述架构提供了四种不同的分布式事务解决方案：
XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
TCC模式：最终一致的分阶段事务模式，有业务侵入
AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
SAGA模式：长事务模式，有业务侵入
无论哪种方案，都离不开TC，也就是事务的协调者。
3.2.部署TC服务
部署Seata 详情
3.3.微服务集成Seata
我们以order-service为例来演示。
3.3.1.引入依赖
首先，在order-service中引入依赖：
<!--seata--> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-seata</artifactId> <exclusions> <!--版本较低，1.3.0，因此排除--> <exclusion> <artifactId>seata-spring-boot-starter</artifactId> <groupId>io.seata</groupId> </exclusion> </exclusions> </dependency> <dependency> <groupId>io.seata</groupId> <artifactId>seata-spring-boot-starter</artifactId> <!--seata starter 采用1.4.2版本--> <version>${seata.version}</version> </dependency>
3.3.2.配置TC地址
在order-service中的application.yml中，配置TC服务信息，通过注册中心nacos，结合服务名称获取TC地址：
seata: registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址 type: nacos # 注册中心类型 nacos nacos: server-addr: 127.0.0.1:8848 # nacos地址 namespace: "" # namespace，默认为空 group: DEFAULT_GROUP # 分组，默认是DEFAULT_GROUP application: seata-tc-server # seata服务名称 username: nacos password: nacos tx-service-group: seata-demo # 事务组名称 service: vgroup-mapping: # 事务组与cluster的映射关系 seata-demo: SH
微服务如何根据这些配置寻找TC的地址呢？
我们知道注册到Nacos中的微服务，确定一个具体实例需要四个信息：
- namespace：命名空间
- group：分组
- application：服务名
- cluster：集群名
以上四个信息，在刚才的yaml文件中都能找到：
namespace为空，就是默认的public
结合起来，TC服务的信息就是：public@DEFAULT_GROUP@seata-tc-server@SH，这样就能确定TC服务集群了。然后就可以去Nacos拉取对应的实例信息了。
3.3.3.其它服务
其它两个微服务也都参考order-service的步骤来做，完全一样。
