• Consistency 一致性（节点或系统中所有可用数据）

  在分布式环境下，一致性是指数据在多个副本之间能否保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。

• Availability 可用性（每个请求会得到一个回应）

  可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里的重点是”有限时间内”和”返回结果”。

• Partition Tolerance 分区容错性（系统运作将不管可用性、分区、数据或通信的丢失）

  分区容错性约束了一个分布式系统具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

CAP 定理证明，一个分布式系统最多只能同时满足这三项中的两项，由于分布式系统中必然存在网络分区，所以对于分布式系统而言，一般分为 CP 系统和 AP 系统。

• Basically Available（基本可用）

  分布式系统在出现不可预知故障的时候，允许损失部分可用性。

• Soft state（软状态）

  软状态也称为弱状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

• Eventually consistent（最终一致性）

  最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

在分布式的数据系统中，BASE 专注于分区容错性（P）和可用性（A），而忽略一致性（C），也就是说 BASE 相当于 AP 系统。

• Atomicity 原子性

  一个事务必须被视为一个不可分割的最小工作单元。整个事务中的所有操作要么全部 commit 成功，要么全部失败 rollback，对于一个事务来说，不可能只执行其中的一部分 SQL 操作，这就是事务的原子性

• Consistency 一致性

  数据库总是从一个一致性的状态转换到另外一个一致性的状态。

• Isolation 隔离性

  通常来说，一个事务所做的修改在最终提交之前，对其他事物是不可见的。

• Durability 持久性

  一旦事务提交，则其所做的修改就会永久保存到数据库中。

假设银行的数据库有两张表：信用卡（credit）表和储蓄（savings）表。用户 XXX 要把信用卡里最后 100 块钱额度转到他 的储蓄账户用来吃饭，那么需要至少三个步骤：

1. 检査信用卡余额是否髙于 100 块钱；
2. 从信用卡账户余额中减去 100 块钱；
3. 在储蓄账户余额中增加 100 块钱。

上述三个步骤必须在同一个事务中执行，任何一个 SQL 失败，则必须回滚所有的 SQL。这里用 START TRANSACTION 语句开启事务，要么使用 COMMIT 提交事务将修改的数据持久保留，要么使用 ROLLBACK 销所有的修改。事务 SQL 的样本如下：

START TRANSACTION;
-- 检查信用卡账户额度
SELECT balance FROM credit WHERE customer_id = 'XXX';
-- 信用卡表扣钱
UPDATE credit SET balance = balance - 100.00 WHERE customer_id = 'XXX';
-- 储蓄表加钱
UPDATE savings SET balance = balance + 100.00 WHERE customer_id = 'XXX';
COMMIT;

从这个例子上理解：

• 一致性：一致性确保了，即使在执行第三、四条语句之间时系统崩潰，信用卡账户也不会损失 100 块，因为事务最终没有提交，所以事务中所做的修改也不会保存到数据库中，保证数据一致性。
• 隔离性：当执行完第三条语句、第四条语句还未开始时，此时有另外一个账户查询余额 SQL 开始运行，则其看到的信用卡账户的余额并没有被减去 100 元。

在分布式的数据系统中，ACID 注重分区容错性（P）和一致性（Consistency）。，也就是说 ACID 相当于 CP 系统。

• 刚性事务：遵循 ACID，对数据要求强一致性；（CP 系统）
• 柔性事务：遵循 BASE，允许一定时间内不同节点的数据不一致，但要求最终一致。（AP 系统）

• HBase、HyperTable 和 BigTable，满足 CP 性质。
• Cassandra、Dynamo 和 Voldemort，满足 AP 性质。

数据复制采用 Leaderless Replication 的数据库都是满足 AP 放弃 C 的，关于分布式复制，请查看：https://github.com/tenji/ks/wiki/Distributing-Data-Replication

HBase 作为分布式数据库，同样满足 CAP 理论，那它是 AP 系统，还是 CP 系统呢？

当某台 region server fail 的时候，它管理的 region failover 到其他 region server 时，需要根据 WAL log（Write-Ahead Logging）来 redo，这时候进行 redo 的 region 应该是不可用的，客户端请求对应 region 数据时，会抛出异常。（也就是说，HBase 的数据复制不是采用的 Leaderless Replication）

因此，HBase 属于 CP 型架构，降低了可用性，具备强一致性读/写。设想一下，如果 redo 过程中的 region 能够响应请求，那么可用性提高了，则必然返回不一致的数据(因为 redo 可能还没完成)，那么 HBase 的一致性就降低了。

• CAP定理与BASE理论