CAP理论

CAP理论指出在分布式系统中三个属性不可能同时满足。
Consistency 一致性：在分布式的多个节点（副本）的数据必须是一样的（强一致）
Availability 可用性：调用系统的每个都必须有正常的响应（即使请求到不正常的节点也要能响应）
Partition tolerance 分区容错：系统在遇到网络分区故障的时候 部分节点于集群失去联系形成了独立的分区；容错是指在分区的时候系统仍然可以提供服务。
首先P一定要保证的，要不然就是只能把所有的节点放在同一台服务器上，“所有的节点同生共死”，这显然就不是分布式了，也违背了分布式的初衷。
在保证分区容错的基础上 A和C能不能共存呢
假设我们首先保证一致性：
N1和N2两个节点，当数据写入N1节点的时候，数据还没同步到N2节点，这时N2节点就不能对外提供服务，请求N2节点需要等待或者超时这时N2就牺牲了可用性，必须等到N2和N1的数据完全同步后才可以对外提供服务
假设我们优先保证可用性：
N1和N2两个节点，当数据写入N1节点的时候，数据还没同步到N2节点,
请求N2节点，N2节点保证正常的影响，但是这时响应的数据就不是最新的数据，牺牲了一致性。
我们无法同时确保一致性和可用性达到理想状态。二者就像是天平的两端，提升一方就意味着另一方的妥协。要根据实际业务需求和容忍度来决定在 CAP 三要素中如何取舍

BASE 理论

base理论是cap理论的基础上演化出来的
Basically Available 基本可用
在发生分区容错的时候，系统保证基本可用，只是相比较正常的系统而言，可能会有响应时间上的损失，或者功能上的降级。
Soft State 软状态
允许数据在各个节点的数据在一定时间内可以不一致，存在中间状态，中间状态不影响服务整体的可用性。
Eventually Consistent 最终一致性
软状态可以出现，但是不能一直是软状态，最终数据还是要一致的。
分布式事务也是基于这个理论其前提来设计的。

seata解决分布式事务

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 XA 、AT、TCC、SAGA 事务模式.
官方网站 https://seata.apache.org/zh-cn

seata重要对象

TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM (Resource Manager) - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

XA模式

原理：XA规范是X/Open 组织针对二阶段提交协议的实现做的规范。目前几乎所有的主流数据库都对XA规范提供了支持。
seata的XA模式依赖数据库本身对XA模式的一种支持，在数据库的基础上做了一些封装。
优点：强一致性，简单对代码没有入侵
缺点：一阶段锁定资源一直持有数据库锁二阶段才能释放锁，性能比较差
数据库必须支持XA模式

AT模式

同样采用的是分阶段提交的事务模型，解决了XA模式中锁定资源时间过长的缺陷，使用的比较多。

AT模式于XA模式区别：
XA模式一阶段 锁定资源不提交事务，AT模式一阶段直接提交事务
XA模式依赖数据库的事务滚回，AT模式依赖的数据库快照回滚
XA模式是强一致性，AT模式是最终一致性。

AT模式的写隔离

优点：
一阶段完成直接提交事务，释放资源，性能比较好
利用全局事务实现读写隔离
没有代码入侵，框架自动进行数据的回滚
缺点：
两阶段之间是软状态，最终一致性
框架的快照回复功能会影响性能，但也比XA模式性能好很多

TCC模式

TCC模式与AT模式相似每个阶段都是独立的事务，不同的是TCC是通过人工编码来实现数据恢复的

1.try 资源的检测和预留
2.Confirm 执行业务操作，要求try成功 confirm一定也要成功
3.cancel 预留资源的释放，可以理解成try的反向操作
这种模式比较适合修改操作 修改余额 修改库存等 这种需要预留资源，如果是insert就不适用，类似保存订单这种就不适合用TCC
空回滚：其中一个分支事务的try阻塞没有执行，所以在执行回滚的cancel 没有预留的资源
业务悬挂：try阻塞没有执行,执行了回滚的cancel,回滚执行完成之后，try的阻塞消失了，又开始执 行try。
编写代码注意事项：允许空回滚，避免业务悬挂，在try之前判断没有回滚过才执行，在执行回滚之前要先判断该分支事务的try已经执行了。
优点：不需要全局锁性能好；不依赖数据库的事务机制，nosql数据库也支撑
缺点：有代码入侵

saga模式

是一种长事务的解决方案，也是分为两阶段提交
一阶段：直接提交本地事务
二阶段：成功则什么都不做，失败则通过手动的补偿来回滚
优点：事务的参与者可以基于事件的驱动实现异步调用，吞吐量高；
无锁性能好；不需要TCC编写那么多的代码
缺点：没有隔离性，可能会有脏写；软状态持续时间长，中间时间不确定