C ：Consistency 强一致性
A ：Availability 高可用性
P ：Partition tolerance 分区容错性
CAP定理强调的各个部分都是强制的。
例如：
1.强一致性可以通过MySQL主从同步时，锁定从库，保证读取数据一定为最新
2.高可用性，允许读出旧数据，但是必须要及时返回
3.网络分区，必须容忍节点有无法通信的情况，而使得整个系统仍旧可以对外服务，实现：使用主从方案和异步方案。
我们称满足BASE理论的事务为柔性事务。
BASE理论特点：
1.基本可用性：核心功能正常响应
2.最终一致性
3.软状态：允许存在中间状态（支付中）
虽然seata四种都有实现，但是它首推AT模式
期间维护undo和redo用于回滚和入库
seata采用before image 和 after image
2PC的问题：
1.同步阻塞问题 ，一阶段，完成了一系列操作，但是仍需要TM的提交命令，这期间资源是被占用的，是阻塞的。
2.单点故障，一阶段结束，TM故障，导致二阶段无法进行，使得资源被一直阻塞。
3.数据不一致问题，一个事务提交，一个未提交
梳理好三者层级关系。(向下，向上的关系)
XA：各个数据库厂商遵循的2PC定义的统一接口
特点：
1.性能：低
2.模式：CP，强一致性（第二阶段等各个服务都完成才提交。其他方案是第一阶段先提交，之后通过补偿策略）
应用场景：
1.金融，并发量不大，但是数据重要的场景
特点：
1.性能：高（一阶段提交，减少同步阻塞）
2.模式：AP，存在中间数据不一致（因为第一阶段就提交事务了）
3.使用：需要自己能掌控数据库，因为要建立undo log表
RM和TM嵌入应用程序，以jar包形式存在
应用场景：
1.允许数据短时不一致，对账，补录保证最终一致性。
一阶段：
官方：
二阶段提交：
二阶段回滚：
特点：
1.性能：好（不加锁）
2.模式：AP，存在中间数据不一致（有中间状态）
3.使用：需要自己能掌控数据库，因为要自定义字段和规则
应用场景：
1.支持异构数据库，允许短时数据不一致
注意：
1.一般不用，比较复杂，一般采用下面MQ的TCC模式
gulimall 死信队列 实现
特点：
性能：不一定，取决于三方
模式：AP，有中间状态
1.在架构中引入状态机机制，类似工作流
场景：
1.三方交互考虑，如：调用支付宝接口–>库存扣减失败–>调用支付宝退款接口。
2.一般不用，状态机啥的不会啊
不保证数据一定能通知成功，但会提供可查询操作接口进行核对。这种
方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种方案也是结合 MQ 进行实现，例如：通过 MQ 发送 http 请求，设置最大通知次数。达到通知次数后即不再通知。
3PC基于2PC引入
1.超时重传机制
2.多引入准备阶段
由于3pc不方便实现，并且也不能完全保证一致性，就不细展开。
1.seata连接数据库。
1）创建库和三张表
2）数据源地址配置（在seata压缩包内）
2.seata注册进nacos，配置加载进nacos
3.各个服务引入undo表
