分布式服务的事务问题
在分布式系统下，一个业务跨越多个服务或数据源，每个服务都是一个分支事务，要保证所有分支事务最终状态一致，这样的事务就是分布式事务。
CAP定理-Consistency
Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。
为了保持数据一致性，发生变更的一方需要和其他的节点做数据同步。
Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
可用性：健康的，没有宕机。
分区：因为网络故障或者其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立分区。
Tolerance（容错）：在集群出现分区时，整个系统也要持续队外提供服务。
简述CAP定理内容？
分布式系统节点通过网络连接，一定会出现分区问题（P)
当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足
思考：elasticsearch集群是CP还是AP？
ES集群出现分区时，故障节点会被剔除集群，数据分片会重新分配到其他节点，保证数据一致。因此是低可用性，高一致，属于CP。
BASE理论是对CAP的一种解决思路，包含三个思想：
Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
而分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论：
AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。
分布式事务模型
解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。
这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务
简述BASE理论三个思想：
基本可用
软状态
最终一致
解决分布式事务的思想和模型：
全局事务：整个分布式事务
分支事务：分布式事务中包含的每个子系统的事务
最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据
强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚
seata是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。
Seata事务管理中有三个重要的角色：
TC-事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
TM-事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM-资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
nacos服务名称组成包括？
namespace+group+serviceName+cluster
seata客户端获取tc的cluster名称方式？
seata的XA模式做了一些调整，但大体相似：
RM一阶段的工作：
1.注册分支事务到TC
2.执行分支事务到sql但不提交
3.报告执行状态到TC
TC二阶段的工作：
TC检测各分支事务执行状态
如果都成功，通知所有RM提交事务
如果有失败，通知所有RM回滚事务
RM二阶段的工作：
接收TC指令，提交或回滚事务
AT模式原理
AT模式同样是分阶段提交的事务模型，不过弥补了XA模型中资源锁定周期过长的缺陷。
阶段一RM的工作：
注册分支事务
记录undo-log（数据快照）
执行业务sql并提交
报告事务状态
简述AT模式与XA模式最大的区别是什么？
XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
XA模式强一致；AT模式最终一致。
全局锁：由TC记录当前正在操作某行数据的事务，该事务持有全局锁，具备执行权。
AT模式的优点：
一阶段完成直接提交事务，释放数据库资源，性能较好
利用全局锁实现读写隔离
没有代码侵入，框架自动完成回滚和提交
AT模式的缺点：
两阶段之间属于软状态，属于最终一致
框架的快照功能会影响性能，但比XA模式要好很多
AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。
AT是直接提交，它在提交之前和提交之后都会生成快照，如果提交失败，它就恢复之前的快照。
TCC模式原理
TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：
Try：资源的检测和预留。
Confirm：完成资源操作业务；要求Try成功Confirm一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。
举例，一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。
阶段一（Try）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30元
阶段二：假如要提交，则冻结金额扣减30
阶段二：如果要回滚，则冻结金额扣减30，可用余额增加30
TCC模式的每个阶段是做什么的？
Try：资源检查和预留
Confirm：业务执行和提交
Cancel：预留资源的释放
TCC的优点是什么？
一阶段完成直接提交事务，释放数据库资源，性能好
相比AT模型，无需生成快照，无需使用全局锁，性能最强
不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
TCC的缺点是什么？
TCC的缺点是什么？
有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
软状态，事务是最终一致
需要考虑Confirm和Cancel的失败情况，做好幂等处理
当某事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。
对于已经空回滚的业务，如果以后继续执行try，就永远不可能confirm或cancel，这就是业务悬挂。应当阻止执行空回滚后的try操作，避免悬挂。
业务分析
为了实现空回滚、防止业务悬挂，以及幂等性要求。我们必须在数据库记录冻结金额的同时，记录当前事务id和执行状态，为此我们设计了一张表：
Try业务
预留资源，锁定一部分资源
Confirm
saga模式
saga模式是SEATA提供的长事务解决方案。也分为两个阶段：
一阶段：直接提交本地事务
二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
saga模式优点：
事务参与者可以基于事件驱动实现异步调用，吞吐高
一阶段直接提交事务，无锁，性能好
不用编写TCC中的三个阶段，实现简单
缺点：
软状态持续时间不确定，时效性差
没有锁，没有事务隔离，会有脏写
TC的异地多机房容灾架构
TC服务作为Seata的核心服务，一定要保证高可用和异地容灾。
