base cap 分布式_分布式理论之CAP和BASE

分布式理论

一、分布式基本概述

分布式系统是一个内涵极度丰富的领域，单就应用层次而言就设计分布式缓存，分布式存储，分布式文件系统，分布式锁，分布式事务，分布式调度任务，分布式调度计算，分布式消息，分布式采集等。

二、CAP理论

在一个分布式系统(指互相连接并共享数据的节点的集合)中，当涉及读写操作时，只能保证一致性(Consistence)、可用性(Availability)、 分区容错性(Partition Tolerance)三者中的两个，另外一个必须被牺牲。

可以注意上述描述中着重强调了两点：互相连接和共享数据。因为分布式系统并不一定会互联和共享数据，只有满足这两点的系统才符合CAP理论。

另外一点，还强调了读写操作，也就是说CAP关注的是对数据的读写操作，而不是分布式系统的所有功能。

所以我们在理解CAP理论的时候，需要从其本质出发去真正理解它的一些内在要求。

2.1 一致性(Consistency)

对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。

在分布式系统中的所有数据备份，在同一时刻是否有同样的值。

2.2 可用性(Availability)

非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。

在集群中一部分节点故障后，集群整体是否还能响应客户端的读写要求。

2.3 分区容忍性(Partition Tolerance)

当出现网络分区后，系统能够继续'履行职责'。

系统如果不能在一定时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

三、CAP应用

高可用、数据一致是很多系统设计的目标，但是分区又是不可避免的事情，由此引出了以下几种选择：

3.1 CP(Consistency/Partition Tolerance)

如果不要求A(可用性)，相当于每个请求都需要在Server之间强一致，而P(分区)会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式，分布式锁也属于此种情况。

也就是说分布式事务以及分布式锁都需要保证强一致性。

3.2 AP(Availability/Partition Tolerance)

要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

3.3 CAP关注的点

3.3.1 CAP关注的粒度是数据，而不是整个系统

在实际设计过程中，每个系统不可能只处理一种数据，而是包含多种类型的数据，有的数据必须选择CP，有的数据必须选择AP。

以银行交易系统为例，交易过程必须选择CP，因为这块业务处理过程必须保证强一致性；但是交易之后通知用户的信息，可以选择AP，因为延迟通知用户并不会对用户有很大的影响。

所以在CAP理论落地实践时，我们需要将系统内的数据按照不同的应用场景和 要求进行分类，每类数据选择不同的策略(CP还是AP)，而不是直接限定整个系统所有的护具都是同一策略。

3.3.2 CAP是忽略网络延迟的

这是一个非常隐含的假设，布鲁尔在定义一致性时，并没有将延迟考虑进去。也就是说，当事务提交时，数据能够瞬间复制到所有节点。但实际情况下，从节点A复制数据到节点B，总是需要花费一定时间的。 如果是相同机房，耗费时间可能是几毫秒；如果是跨不同地点的机房，例如，北京机房同步到广州机房，耗费的时间就可能是几十毫秒。这就意味着，CAP理论中的C在实践中是不可能完美实现的， 在数据复制的过程中，节点A和节点B的数据并不一致。

3.3.3 正常运行情况下，不存在CP和AP的选择，可以同时满足CA

CAP理论告诉我们分布式系统只能选择CP或AP，但其实这里的前提是系统发生了“分区”现象。如果系统没有发生分区现象，也就是说P不存在的时候(节点间的网络连接一切正常)，我们没有必要放弃C或A, 应该C和A都可以保证，这就要求架构设计的时候既要考虑分区发生时，选择CP还是AP，也要考虑分区 没有发生时如何保证CA。

3.3.4 放弃并不等于什么都不做，需要为分区恢复后做准备

CAP理论告诉我们三者只能取两个，需要“牺牲(sacrificed)”另外一个，这里的“牺牲”是有一定误导作用的，因为“牺牲”让很多人理解为什么都不做。实际上，CAP理论的“牺牲”只是说在分区过程中我们无法保证C或A，但并不意味着我们什么都不做。 因为在系统整个运行周期中，大部分时间都是正常的，发生分区现象的时间并不长。

四、一致性理论

当谈到数据一致性时，CAP、ACID、BASE难免都会被拿出来进行讨论的，原因在于这三者都是和数据一致性相关的理论。

ACID，数据库事务的特性

CAP，分布式系统设计理论

BASE，也是分布式系统设计理论，延伸了CAP理论中AP方案

4.1 ACID

ACID是数据库管理系统为了保证事务的正确性而提出来的一个理论，ACID包含四个约束，基本解释如下。

Atomicity(原子性)

指事务作为整体来执行，要么全部执行，要么全不执行。

Consistency(一致性)

指事务应确保数据从一个一致的状态转变为另一个一致的状态。也就是说在事务开始之前和事务结束以后，数据库的完整性没有被破坏。

isolation(隔离性)

指多个事务并发执行时，一个事务的执行不应影响其他事务的执行。也就是说数据库允许多个并发事务同时对数据进行读写和修改的能力。 隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

Durability(持久性)

指已提交的事务修改数据会被持久保存。也就是说事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

五、BASE

BASE是Basically Available(基本可用)、SofState(软状态)和Eventually Consistency(最终一致性)三个短语的缩写，其核心思想是即使无法做到强一致性(CAP的一致性就是强一致性)，但应用可以采用适合的方式达到最终一致性(Eventual Consistency)。

基本可用(Basically Available)

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

软状态(Soft State)

允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是CAP理论中的数据不一致。

最终一致性(Eventual Consistency)

系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

这里的关键词是“一定时间”和“最终”，“一定时间”和数据的特性是强关联的，不同的数据能够容忍的不一致时间是不同的。“最终”的含义就是不管多长时间，最终还是要达到一致性的状态。

六、总结

BASE理论本质上是对CAP的延伸和补充，更具体地说，是对CAP中AP方案的一个补充。之前在讲解CAP理论时，提到了其实和BASE相关的两点：

CAP理论是忽略延时的，而实际应用中延时是无法避免的。

这一点就意味着完美的CP场景是不存在的，即使是几毫秒的数据复制延迟。因此CAP中的CP方案，实际上也是实现了最终一致性，只是“一定时间”是指几毫秒而已。

AP方案中牺牲一致性只是指分区期间，而不是永远放弃一致性

这一点其实就是BASE理论延伸的地方，分区期间牺牲一致性，但分区故障恢复后，系统应该达到最终一致性。