分布式系统CAP理论

在单机的数据库系统之中，我们很容易实现一套满足ACID 特性的 事务处理系统， 事务的一致性不存在问题。 但是在分布式系统之中，由于数据分布在不同的主机结点上，如何对着些数据进行分布式的事务处理就具有非常大的挑战，CAP 理论的出现，让我们对于分布式事务的一致性有了另外一种看法。

什么是CAP 理论？

      在计算机科学理论，CAP 理论 （也称Brewer 定理） 又有称为 CAP原则，CAP定理，是由计算机科学家Eric Brewer 在 2000 年 提出的 ，其理论观点是， 在分布式计算机系统中，不可能存在同时提供 以下全部三个保证。

• Consistency（一致性）： 所有节点同一时间看到的是相同的数据。在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
•  Availability（可用性）：不管是否成功，确保每一个请求都能接收到响应。在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• Partition tolerance（分区容错性）：系统任意分区后，在网络故障时，仍能操作。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

　　 CAP原则是NOSQL数据库和分布式系统的基石。

 为什么说CAP 只能三选二？

举个栗子：

  下图 显示了在一个网络中,N1，N2 是两个节点，他们共享数据块V  其中一个 值V0， 运行在N1 的A 程序可以认为是安全的，无Bug，可预测的和可靠的，运行在N2 的是B 程序，在这个例子中，A 将写入V的新值。而B从V 中读取值。

系统预期执行下面的操作：

1. 写入一个V 的新值 V1 。
2. 然后消息（M） 从N1 更新V 的副本到N2.
3. 从B 处读取返回的V1 

 

如果网络是分区的，当N1到N2 的消息不能传递的时候，就会出现虽然N2 能访问到V 的值（可用性），但是实际上与N1 的V 值已经不一致了。  如下图：

CAP 常见模型：

既然 CAP 理论已经证明一致性，可用性和分区容错性三者不可能通知达成。 那么在实际应用中，我们可在其他某一方面来放松条件，从而达到妥协，下面是一些常用的模型。

1.    牺牲分区 (CA  模型)

 牺牲分区容错性意味着把所有机器搬到一台机器内部，或者放到一个“要死一起上死”的机架上面（机架也可能出现部分失效），这明显就违背了我们希望的可伸缩性。

  常见例子:

• 单站点数据库
• 集群数据库
• LDAP
• xFS 文件系统

实现方式：

  两阶段提交， 缓存验证协议。

      2. 牺牲可用性(CP 模型）

牺牲可用性意味着一旦系统出现分区这样的错误， 系统就直接停止服务。

 常见例子：

• 分布式数据库
• 分布式锁定
• 绝大部分协议

实现方式：

悲观锁， 少数分区不可用。

  3 . 牺牲一致性（AP 模型）

常见例子：

• Coda
• Web缓存
• DNS

实现方式：

到期/租赁， 解决冲突， 乐观。

CAP 的意义：

在系统架构时，应该是根据具体的业务场景来权衡CAP， 比如 对于大多数互联网应用来说（如门户网站），因为 机器数量庞大，部署结点分散，网络故障是常态的，所以可用性是必须的所以只有舍弃一致性来保证服务的AP 而对于银行等需要确保一致性的场景，通常会权衡CA， 和CP 模型。

CAP 的最新发展：

Eric Brewer 在2012 年发表文章指出了CAP里面三选二的做法存在一定的误差性，主要体现在：

• 由于分区很少发生，那么在系统中不存在分区的情况下，没有什么理由牺牲C或A 。
• C与A 之间的取舍可以在同一系统内以非常细小的粒度反复发生，而每一次的决策可能因为具体的操作，乃至因为牵涉特定的数据或用户而有所不同。
• 这三种性质都可以在一定程度上衡量，并不是非黑即白的有或无。可用性显然是在0% 到100% 之间连续变化的，一致性分很多级别，连分区也可以细分不同的含义，如系统内的不同部分对于是否存在分区可以有不一样的认知。

 理解CAP 理论最简单的方式 是想象两个节点分处于分区两侧，允许至少一个节点更新状态会导致数据不一致，即丧失了C 性质，如果为了保证数据的一致性，将分区一侧的节点设置为不可用， 那就丧失了A 性质，除非两个节点可以相互通讯，才能既保证A 又保证C ，但这又会丧失P 性质，一般来说 跨区域的系统，设计师无法舍弃P 性质，那么就只能在数据一致性和可用性上做一个艰难选择， 不确切的说，NoSQL 运动的主题其实是创造各种可用性优先，数据一致性其次的方案，而传统数据库坚守ACID 特性，做的是相反的事情。

BASE ：

BASE 来自于互联网的电子商务领域的实践，它是基于CAP 理论逐步演化而来的，核心思想是即便不能达到强一致性，但可以根据应用特点采用适当的方式来达到最终一致性的效果。BASE 是对CAP 中C和A 的延伸。 其含义如下 ： 

1. Basically Available  基本可用
2. Soft state 软状态/柔性事务，即状态可以有一段时间的不同步。
3. Eventual consistency  最终一致性。