TCC
执行阶段 根据准备阶段的结果，判断下面的执行方法，所有成功Confirm 否则 Cancel
cancel 预留资源释放
Confirm 执行的业务操作提交，要求Try 成功Confirm 一定要成功
Try 、Confirm、Cancel都是独立的事务 不接受其他的参与者影响，不会阻塞等待他人，都是程序员在业务层控制 ，锁的粒度有代码控制
缺陷
代码非常复杂，需要人来编写Try confirm 和cancel阶段
成本高 三个部分都得写代码
安全性的考量 cancel动作执行失败 资源 就无法释放 需要引入重试机制 重复执行还得考虑幂等问题
AT(无侵入的分布式事务解决方案Seata就是这种)
第二阶段由框架自动实现
第一阶段会有拦截的操作 看你的where条件是什么
stock 10<br> update tb stock set stock = stock -2 where id = 1---> before image 类似于undo 日志<br>select * fromtb stock where id = 1 ;<br>执行sql<br>再查询一次<br>select* from tb stock where id = 1;---> after image 类似 redolog<br>错误的时候 redolog 和数据库里不一致 就需要人工介入
常用的分布式事务解决方案
本地事务<br>
资源管理器（数据库）本地管理
单个数据库
全局事务DTP模型（标准分布式事务）
事务由全局事务管理器全局管理
事务管理器
管理全局事务状态与参与的资源，协助资源的一致提交/回滚
在该模型中，一个分布式事务 (全局事务)可以被拆分成许多个本地事务，运行在不同的AP和RM上。每个本地事务的ACID很好实现，但是全局事务必须保证其中包含的每一个本地事务都能同时成功，若有一个本地事务失败，则所有其它事务都必须回滚。但问题是，本地事务处理过程中，并不知道其它事务的运行状态。因此，就需要通过CRM来通知各个本地事务，同步事务执行的状态。
Base理论
S
柔性状态（状态允许短时间的不同步、异步）
可查型操作
单笔操作
批量查询
操作的是唯一的，确定时间的
幂等操作
f(f(s)) = f(x)
重复调用多次产生的业务结果与调用一次产生的业务结果都是一样的
方式一：通过业务操作本身实现幂等特性
方式二：系统缓存所有的请求和处理结果、检测到重复请求的话，自动返回之前的处理结果。
TCC操作
也是两阶段提交
try执行业务
confirm
cancel
它是位于业务层，没有准备阶段，灵活性选择业务资源（灵活锁定）
可补偿性操作
真正执行业务
业务补偿
约束
Tcc中的confirm和cancel也可以看作是一种可补偿性的操作
原子性和持久性必须保证，为了可用性和性能只能降低一定的一致性和隔离性的要求
CAP定理
分布式系统中，最重要的是满足业务需求，而不是追求抽象、绝对的系统特性。以下三个性质不可能全部做到
CAP原理指出在一个分布式系统中，最多只能同时满足其中两个属性，而无法同时满足三个属性。这是由于在面对网络分区时，为了保持系统的可用性，必须允许部分节点在分区后继续处理请求，这可能导致数据的不一致性，因此无法同时满足一致性和可用性。
一致性 Consistency
可用性 Availability
分区容错性 Partition tolerance
如何满足CP ？
对一致性要求高的场景。例如 我们的Zookeeper就是这样的，在服务节点见中间的数据同步时，服务对外不可用。
如何满足AP ？
对可用性要求较高的场景，例如：Eureka 必须保证注册中心随时可用，不然拉取不到服务器就可能出问题。
