ACID

• Atomicity(原子性)

是指一个事务要么全部执行，要么不执行，也就是说一个事务不可能只执行了一半就停止了。比如你从取款机取钱，这个事务可以分成两个步骤：1划卡，2出钱。不可能划了卡，而钱却没出来。这两步必须同时完成，要么就不完成。

• Consistency(一致性)

是指事务的运行并不改变数据库中数据的一致性。例如，完整性约束了a+b=10，一个事务改变了a，那么b也应该随之改变。

• Isolation(隔离性)

事务的独立性也有称作隔离性，是指两个以上的事务不会出现交错执行的状态。因为这样可能会导致数据不一致。

事务的隔离性是指在并发环境中，并发的事务时相互隔离的，一个事务的执行不能不被其他事务干扰。不同的事务并发操作相同的数据时，每个事务都有各自完成的数据空间，即一个事务内部的操作及使用的数据对其他并发事务时隔离的，并发执行的各个事务之间不能相互干扰。

• Durability(持久性)

事务的持久性是指事务执行成功以后，该事务对数据库所作的更改便是持久的保存在数据库之中，不会无缘无故的回滚。

BASE

• Basically Available（基本可用）

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。

电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

• Soft State（软状态）

软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

• Eventual Consistency（最终一致性）

最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

BASE模型是传统ACID模型的反面，不同与ACID，BASE强调牺牲高一致性，从而获得可用性，数据允许在一段时间内的不一致，只要保证最终一致就可以了。

CAP

一个分布式系统最多只能同时满足

• Consistency(一致性)

指在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

• Availability(可用性)

在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

• Partition tolerance(分区容错性)

即当节点之间无法正常通信时，就产生了分区，而分区产生后，依然能够保证服务可用，那么我们就说系统是分区容忍的。显然如果节点越多，且备份越多，分区容忍度就越高（因为即便是其中一个或多个节点挂了，仍然有其它节点和备份可用）。

这三项中的两项。

那么，为什么说三个特性无法全部保证呢？首先，假如我们要保证分区容忍性，必然要做多个副本节点，而这必然会带来一致性的问题，即保证多个节点的数据是相同的，但是，要让多个节点数据相同，就必须要花时间去复制数据，这还是能够正常通信的情况下，那么在数据复制的过程中为了保持一致性，就不能对外提供服务，所以这段时间就无法满足可用性的问题。

实际工程通常会采取一些折中措施，比如并不保证强一致性，只保证最终一致性，什么意思呢？比如，有三个数据节点互为备份，某份数据在节点A更改后，需要将更改复制到节点B和C，假设复制过程中，有客户访问该数据，那么此时不保证是一致的，即访问A节点的用户得到的是最新数据，而访问B和C节点的用户得到是老数据，但是最终，数据会复制完成，所以最终A、B、C三个节点的数据是一致的。（比如像文章点赞这种数据，延迟下也没有关系啦）

TCC

• try-尝试执行业务

完成所有业务检查(一致性)

预留必须业务资源(准隔离性)

• confirm-确认执行业务

真正执行业务

不作任何业务检查

只使用Try阶段预留的业务资源

Confirm操作必须保证幂等性

• cancel-取消执行业务

释放Try阶段预留的业务资源

Cancel操作必须保证幂等性

TCC事务其实主要包含两个阶段：Try阶段、Confirm/Cancel阶段。

从TCC的逻辑模型上我们可以看到，TCC的核心思想是，try阶段检查并预留资源，确保在confirm阶段有资源可用，这样可以最大程度的确保confirm阶段能够执行成功。