CAP
又被叫做布鲁尔定理，对于共享数据系统，最多只能同时拥有CAP其中的两个，任意两个都有其适用的场景
BASE
最终一致性，核心思想是即使无法做到强一致性，但应用可以采用适合的方式达到最终一致性
2PC
强一致性
事务的发起者称为协调者，事务的执行者称为参与者
两阶段提交，将事务的提交过程分为两个阶段来进行处理
准备阶段
提交阶段
XA
强一致性
XA是由X/Open组织提出的分布式事务的规范，基于2PC
XA主要定义了全局事务管理器（TM）和局部资源管理器（RM）之间的接口
目前主流的关系型数据库产品都是实现了XA接口
之所以需要引入TM，是因为在分布式系统中，从理论上讲两台机器理论上无法达到一致的状态，需要引入一个单点进行协调
由TM管理和协调的事务，可以跨越多个资源（数据库）和进程
TM用来保证所有事务参与者都完成了准备工作
如果TM收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了
MySQL在XA事务中扮演的是参与者，而不是TM
TCC
最终一致性
Try-Confirm-Cancel，是服务化的两阶段编程模型
其3个方法均由业务编码实现
Confirm
操作作为二阶段提交操作，执行真正的业务
相比XA，解决了
协调者单点
由主业务方发起并完成业务活动
业务活动管理器可以变成多点，引入集群
同步阻塞
引入超时机制，超时后进行补偿，并且不会锁定整个资源
将资源转换为业务逻辑形式，粒度变小
数据一致性
有了补偿机制之后，由业务活动管理器控制一致性
消息队列模式
最终一致性
最初由eBay提出，基于TCC模式，消息中间件可以基于Kafka、RocketMQ等消息队列
核心是将分布式事务拆分成本地事务进行处理，将需要分布式处理的任务通过消息日志的方式来异步执行
消息日志可以存储到本地文本、数据库或MQ中间件，再通过业务规则自动或人工发起重试
事务处理流程
1. 事务主动方处理本地事务
2.事务主动方通过消息中间件，通过事务被动方处理事务通知事务待消息
事务主动方主动写消息到MQ
事务被动方接口并处理MQ中的消息
3.事务被动方通过MQ中间件，通知事务主动方事务已处理的消息，事务主动方根据反馈结果提交或回滚事务
为了数据一致性，流程中遇到错误需要重试，容错处理规则如下
步骤1处理出错，事务回滚，相当于什么都没有发生
步骤2处理出错，由于未处理的事务消息还是保存在发送方，可以重试或撤销本地业务操作
如果事务被动方消费消息异常，需要不断重试，业务处理逻辑需要保证幂等
如果事务被动方业务上处理失败，可以通过MQ通知事务主动方进行补偿或事务回滚
如果多个事务被动方已经消费消息，事务主动方需要回滚事务时需要通知事务被动方回滚
基于Saga模式
最终一致性
一个Saga事务是一个有多个短时事务组成的长时的事务
在分布式事务场景下，一个Saga分布式事务可以看作是由多个本地事务组成的事务，每个本地事务都有一个与之对应的补偿事务
Saga事务执行过程中，如果某一步执行出现异常，Saga事务会被终止，同时调用对应的补偿事务完成相关的恢复操作
这样保证Saga相关的本地事务要么都是执行成功，要么通过补偿恢复成为事务执行之前的状态
基本协议
每个Saga事务由一系列幂等的有序子事务Ti组成
每个Ti都有对应的幂等补偿动作Ci，补偿动作用于撤销Ti造成的结果
Saga是一种补偿模式，它定义了两种补偿策略
向前恢复
发生失败进行重试，适用于必须要成功的场景
向后恢复
发生错误后撤销掉之前所有成功的子事务，使得整个Saga的执行结果撤销
Seata框架AT模式
Seata：Simple Extensible Autonomous Transaction Architecture
它是一套一站式分布式事务解决方案，是阿里集团和蚂蚁金服联合打造的分布式事务框架
目前的事务模式有AI、TCC、Saga，默认AT模式（本质上是2PC的一种实现）
AT模式
模型
包含TM、RM、TC（事务协调器）
TC是一个独立的服务需要单独部署
TM和RM以Jar包的方式同业务应用部署在一起，它们同TC建立长连接，在整个事务生命周期内，保持RPC通信
机制
全局事务的发起方作为TM，全局事务的参与者作为RM
TM负责全局事务的begin和commit/rollback
RM负责分支事务的执行结果上报，并通过TC的协调进行commit/rollback
阶段
一、各个阶段本地提交操作
二、根据第一阶段情况决定是进行全局提交/回滚
执行流程
RM通过TC协调进行commit/rollback
RM向TC汇报资源准备状态
RM分支事务结束，一阶段结束
根据TC汇总事务信息，由TM发起commit/rollback操作
TC通知所有RM commit/rollback，二阶段结束
