1、CAP原则

CAP原则是指：一致性©、可用性(A)、分区容错性§，分布式系统一般进行三选二，比如：

CA：保证一致性和可用性，在单机情况下实现；
CP：保证一致性和分区容错性；
AP：保证可用性和分区容错性；

CAP的选择性： 在分布式系统中，为了保证某个节点出现故障时不至于整个系统出现异常，所以至少需要满足分区容错性(‘P’)；比如场景如下：

场景一： 当用户在写入数据时，我们需要将数据同步到所有的节点，当某个节点出现了故障(导致数据无法完成同步)，此时要么直接提示用户"操作失败"或者"操作成功"；如果提示"操作失败"就表示保证数据的强一致性放弃可用性即CP原则，如果提示"操作成功"就表示保证了系统的可用性，放弃强一致性(后续通过定时任务等手段达到所有节点数据的最终一致性)即AP原则；
场景二： 秒杀系统中，为了防止超卖的情况，在更新库存时就必须要保证一致性如果更新不成功则购买失败，此处满足CP原则;

在分布式系统中是不存在同时满足CAP三者的，一般都是需要牺牲一致性来换取系统的高可用性，系统往往只需要保证最终一致性(AP)，这也更符合分布式带来的高可用机制 ；但是CAP原则并不是要求整个系统要么满足CP或AP；而是根据不同业务模块的场景设计使用CP还是AP；

常用中间件满足的CAP原则：

CA：mysql、Oracle等单机版关系型数据库；
CP：Zookeeper、Nacos
AP：Nacos、Eureka、Redis、Seata、Rabbit、Rocket

2、BASE理论

BASE理论是指基本可用、软状态、最终一致性，基于CAP原则强调核心思想是不做强一致性，通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

基本可用：允许系统在出现故障时损失一定的可用保证，比如：高并发情况下出现服务降级处理，服务器出现某些故障增加响应时间；
软状态：允许数据存在不影响系统可用性的中间状态；
最终一致性：在一段时间处理后数据达到最终的一致，而不需要实时保证系统的强一致性；

3、一致性协议

3.1 2PC

二阶段提交协议(2PC)：是基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法，其思路为事务参与者"将操作结果通知“协调者”，再通过“协调者”来处理事务是提交还是回滚；

二阶段分别是：

第一阶段：准备阶段（投票阶段）；
第二阶段：提交阶段（执行阶段）；

准备阶段：“协调者”给每个事务参与者"发送一个预处理消息；事务参与者"执行本地事务，将执行情况写入本地的redo和undo日志，但是不提交事务(日志资源一直被加锁，产生了阻塞)；最后向“协调者”反馈成功或者失败；

提交阶段：只要有一个事务参与者"反馈失败，“协调者”就会给每个事务参与者"发送回滚消息，反之发送提交消息；事务参与者"根据“协调者”的指令执行提交或者回滚操作，并且释放所有事务处理过程中产生的锁资源；

2PC的不足： 数据不一致(二阶段提交时只有一部分参与者接受到了commit请求)、同步阻塞(一阶段将日志资源一直被加锁，产生了阻塞)、单点故障(协调者挂机后事务参与者的资源都在阻塞状态无法释放)

3.2 3PC

三阶段提交协议(3PC)：是二阶段提交的改进版，其将二阶段提交协议的“准备阶段”分为二步，形成了CanCommit，PreCommit，DoCommit三个阶段，并且加入了超时机制。

CanCommit阶段： 协调者向事务参与者发送Commit请求，事务参与者如果可以提交事务就响应Yes(进入预备执行状态，不会执行事务)，反之响应No；

PreCommit阶段： 接受到PreCommit请求后，如果CanCommit阶段所有的事务参与者"都响应Yes，事务参与者执行事务操作，并将undo和redo信息记录到事务日志中，对资源进行加锁。反之有一个事务参与者响应No或者响应超时，将中断所有事务参与者"执行的事务；

DoCommit阶段： DoCommit阶段根据PreCommit阶段的结果分为提交和回滚两种情况；如果是提交事务参与者"接收到DoCommit请求后，执行正式的事务提交，并在完成事务提交之后释放所有事务资源。如果是回滚事务参与者"接受到abort请求后，利用日志中的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

3PC数据不一致场景： 由于在DoCommit阶段，如果事务参与者"无法及时接收到来自“协调者”的DoCommit或者abort请求时(“协调者”宕机或者网络波动)，会在等待超时之后，继续执行事务提交。也正是由于这个机制可能会导致数据不一致的情况，比如有一个abort请求由于网络问题没有被事务参与者及时接收,此时事务参与者"会执行提交操作；那么就会出现本应该回滚的数据进行了提交，导致数据不一致。

4、Seata分布式事务模型

以分布式事务中间件Seata，介绍四类分布式事务模型，四类模型都是使用了2PC协议，但是有超时机制；

4.1 XA

优点：XA模式下，所有的事务会相互等待，达到强一致性的效果。
缺点：会占用数据库锁，造成资源浪费，性能较差，需要数据库自身支持XA。

阶段一： 分支事务执行本地事务，但是不进行提交，向事务管理器报告执行状态；

阶段二： 事务管理器检测分支事务的执行情况，如果都成功则通知分支事务提交，如果有一个失败则通过分支事务回滚；

4.2 AT

优点：
- 一阶段完成直接提交事务，释放数据库资源，性能比较好。
- 利用全局锁实现读写隔离。
- 没有代码侵入，框架自动完成回滚和提交。
缺点：
- 两阶段之间属于软状态，无法保证数据强一致性，只能是数据最终一致性。
- 需要额外维护undo_log表，会略微消耗性能。

阶段一： 将事务执行前的数据快照写入undo_log中，分支执行本地事务并且提交，向事务管理器报告执行状态；

阶段二： 事务管理器检测分支事务的执行情况，如果都成功则删除undo_log中的数据，如果有一个失败则根据undo_log中的数据进行回复并且删除log数据；

4.3 TCC

TCC模式与AT模式非常相似，每阶段都是独立事务，TCC需要编码来实现数据恢复。需要实现三个方法：

Try：资源的检测和预留；
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。

优点：
- 一阶段完成直接提交事务，释放数据库资源，性能好。
- 相比AT模型，无需生成快照，无需使用全局锁，性能强。
- 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库。
缺点：
- 有代码侵入，需要人为编写try、Confirm和Cancel接口，比较麻烦。
- 软状态，事务是最终一致。
- 需要考虑Confirm和Cancel的失败情况，做好幂等处理。

阶段一： 执行本地事务并且进行提交，向事务管理器报告执行状态(分支事务预留业务资源，冻结数据[Try])；

阶段二： 事务管理器检测分支事务的执行情况，如果都成功(**Confirm)则使用冻结的数据完成业务，如果有一个失败(Cancel)**则把冻结的资源进行释放完成回滚；

TCC中的空回滚和业务悬挂：

当某个分支事务在执行Try操作时，因为阻塞导致全局获取状态超时，从而执行Cancel操作，在未执行Try操作时执行了Cancel操作这就是空回滚。当执行空回滚的业务如果没有了阻塞并且继续执行Try操作，会导致无法执行后续的Confirm或者Cancel操作，这就是业务悬挂。

4.4 SAGA

Saga模式是一种长事务解决方案，适用于业务流程长、业务流程多参与者包含其它公司或遗留系统服务；

优点
- 事务参与者可以基于事件驱动实现异步调用，吞吐高
- 一阶段直接提交事务，无锁，性能好
缺点：
- 软状态持续时间不确定，时效性差。
- 没有锁，没有事务隔离，会有脏写。

一阶段：执行本地事务并且进行提交，向事务管理器报告执行状态；
二阶段：事务管理器检测分支事务的执行情况，如果成功则什么都不做；失败则通过编写的补偿业务来回滚；

4.5 模式对比

XA AT TCC SAGA

一致性 强一致弱一致,最终一致弱一致,最终一致最终一致

隔离性 完全隔离基于全局锁隔离基于资源预留隔离无隔离

代码侵入 无无有，要编写三个接口有，要编写状态机和补偿业务

性能差好非常好非常好

场景对一致性、隔离性有高要求的业务基于关系型数据库的大多数分布式事务场景都可以对性能要求较高的事务。有非关系型数据库要参与的事务。业务流程长、业务流程多参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口

	XA	AT	TCC	SAGA
一致性	强一致	弱一致,最终一致	弱一致,最终一致	最终一致
隔离性	完全隔离	基于全局锁隔离	基于资源预留隔离	无隔离
代码侵入	无	无	有，要编写三个接口	有，要编写状态机和补偿业务
性能	差	好	非常好	非常好
场景	对一致性、隔离性有高要求的业务	基于关系型数据库的大多数分布式事务场景都可以	对性能要求较高的事务。有非关系型数据库要参与的事务。	业务流程长、业务流程多参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口

什么是分布式事务(CAP原则、BASE理论、2PC|3PC协议、XA|AT等模式)相关推荐

事务 | Spring Cloud 分布式事务管理（二）2pc/3pc
Spring Cloud 分布式事务管理(二)2pc/3pc 上一篇 Spring Cloud 分布式事务管理上一章,讲到了微服务带来的优点和缺点以及分布式事务的不确定性.这节说一下2pc/3pc ...
分布式之cap、base理论、flp不可能原理、一致性问题、共识算法
一.CAP理论 CAP理论:在一个分布式系统中,最多只能满足C.A.P中的2个. CAP含义: C:Consistency 一致性:同一数据的多个副本是否实时相同.all nodes see the ...
分布式事务中的Base理论
CAP理论告诉我们一个悲惨但不得不接受的事实--我们只能在C.A.P中选择两个条件.而对于业务系统而言,我们往往选择牺牲一致性来换取系统的可用性和分区容错性.不过这里要指出的是,所谓的"牺牲 ...
看《大明王朝1566》聊分布式中的CAP和BASE理论
概述 CAP 和 BASE 理论基本上接触过分布式系统的朋友都知道 CAP 和 BASE 理论,这两个理论对工程实践中的分布式架构设计具有重要的影响.CAP 理论是加州大学伯克利分校的 Eric B ...
学习分布式不得不会的BASE理论
转载自学习分布式不得不会的BASE理论 eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结,在ACM上发表文章提出BASE理论,BASE理论是对CAP理论的延伸,核心思想 ...
xa 全局锁_分布式事务如何实现？深入解读 Seata 的 XA 模式
原标题:分布式事务如何实现?深入解读 Seata 的 XA 模式作者简介:煊檍,GitHub ID:sharajava,阿里巴巴中件间 GTS 研发团队负责人,SEATA 开源项目发起人,曾在 Or ...
分布式事务讲解 - TX-LCN分布式事务框架（含LCN、TCC、TXC三种模式）
分布式事务讲解 - TX-LCN分布式事务框架(含LCN.TCC.TXC三种模式) 分布式事务系列博客: TX-LCN框架原理 LCN 原理及主要特点代码实现实现场景创建数据库及表(三个数据库, ...
事务原理：ACID,CAP和BASE理论及分布式事务一致性案例
分布式系统一致性的需求需求定义 Safety Only a value that has been proposed may be chosen. Only a single value is ch ...
【分布式】CAP原则和BASE理论
CAP原则概述 C=Consistency=一致性 A=Availability=可用性 P=Partition tolerance=分区容错性 1998年,加州大学的计算机科学家Eric Brewe ...

什么是分布式事务(CAP原则、BASE理论、2PC|3PC协议、XA|AT等模式)