【分布式设计与开发3】什么是分布式架构设计中的CAP原理

分布式系统;CAP原理;架构设计
一､引言
在2000年7月ACM (美国计算机协会) 组织的PODC (PrinciplesofDistributedComputing分布式计算原理) 会议上,UCBerkeley大学的EricABrewer教授发表了题为TowardsRobustDistributedSystems[1]的演讲,以其本人参与的Inktomi搜索引擎､BerkeleyNinja网络课程等大型分布式项目为实践基础,在ACID和BASE之上提出了著名的Brewer猜想,即CAP原理①｡2002年麻省理工大学的SethGilbert和NancyLynch联合发表论文BrewersConjectureandtheFeasibilityofConsistent,Available,PartitionTolerantWebServices[2]对Brewer猜想进行了理论证明,就此确定了CAP原理｡

CAP原理在当时并没有引起强烈的关注,因为10年前大型网站及分布式架构的应用并不广泛｡而随着互联网的高速发展,2005年Web20大型网站逐渐兴起,并在2009年达到一个阶段性高潮,其特点是高访问量､高数据量､大交互量,传统关系型数据库在这样的网站设计中已经明显不能胜任｡为了突破数据瓶颈,架构设计者几乎同时把目光聚集在CAP原理上,并以其为重要理论基础在2010年开展了声势浩大的NoSQL运动,NoSQL技术迅速地推进了非关系型数据库在大并发､大数据量领域里的广泛应用｡越来越多的架构设计者开始意识到分布式系统CAP原理在数据库方面的价值和意义,并在系统架构设计中越来越多地验证了CAP原理｡

二､分布式系统CAP原理
CAP原理认为:分布式系统有三个核心需求,即数据一致性Consistency(以下简称C)､可用性Availability(以下简称A)和分区容忍性PartitionTolerance(以下简称P),且这三个需求最多只能同时满足两个(见图1)｡CAP原理是针对Web等各类分布式系统提出的,由于在数据库领域内的表现显著,现在人们大都围绕数据库对其讨论和应用(见图2①)｡


图1 CAP原理示意图图2 CAP原理的典型应用

CAP需求
在分布式的环境下，设计和部署系统时主要考虑下述3 个重要的核心系统需求：

● 一致性（Consistency）：所有节点在同一时间具有相同的数据。

● 可用性（Availability）：保证对于每个请求的成功或者失败都有响应。

● 分区容错性（Partition Tolerance）：系统中信息的丢失或失败并不影响系统的运行。
上述3 个重要的核心系统需求又简称为 CAP需求。

1.1 一致性
在分布式系统中，数据存在多个副本。一致性是指对某数据操作之后，存在各副本中的该数据始终保持一致。通常将这种操作称为一致性操作，一致性操作是原子性的操作，即对数据的操作（增、删、改）结果是对所有数据副本全部成功才算操作成功，否则为失败。如果操作失败，则回退到一致性操作前的状态。如果一个存储系统能够保证一致性，那么客户读取的数据可以保证是最新的数据，不会发生两个客户端在不同存储节点读取到不同的数据副本。
例1 ： N1、N2 为网络中的两个节点，共享同一数据V，即一个是主本，另一个是副本，其初始值为V0。N1 节点上有一个算法A， N2 上有一个类似的算法B，利用A算法可以将新值写入V，而利用B 算法可以读取V 的值。
1）数据保持一致性情况。
（1） A 写入新的V 值，称作V1。
（2） N1 发送信息给N2，更新N2 的V 值。
（3） B 读取N2 的V 值，读取到的值将是V1。

2）数据出现不一致性情况。
如果网络断开（分区），从N1 无法发送信息到N2，那么在第（3）步的时候，N2 就会包含一个与N1 中的不一致的V 值，即在N1 中的V=V1，在N2 中的V= V0。

1.2 可用性
可用性是指客户端访问数据时，可以得到响应，但系统可用并不代表存储系统的所有节点提供的数据一致。如客户端想要读取文章评论，存储系统可以返回客户端数据，但评论缺少最新的一条。在这种情况下，我们仍然可以说系统可用。往往可对不同的应用设定一个定长响应时间，超过这个定长响应时间的服务认为不可用。可用性只表明服务可用，主要标志是可以完成或不能完成上述操作。如当用户购书时希望得到反馈，而不是看到浏览器报告网站无法连接的信息。

1.3 分区容错性
在分布系统中，为了提高系统性能，可以将同一数据的副本分布地存放在不同地点。分区容错性是指分布系统的容错性。更确切地说，除非网络的全部节点都出现故障，否则所有子集合节点的故障都不能导致整个系统的不正确响应。显然，将数据分布在不同节点上，就有形成分区的风险。如果网线被切断，分区就形成，两节点之间无法进行通信。网络分区是指由于某种原因网络被分成若干个孤立的互不相通区域。分区容错性也可以理解为系统在存在网络分区的情况下仍然可以接受满足一致性或可用性的请求。

2 CAP 定理
CAP定理指出：在一个分布式系统构建中，不可能同时满足一致性、可用性和分区容错性三个系统需求，最多只能同时满足两个[2]。对所设计系统的强调点不同，采用的策略也不一样。分布系统在小规模、低压力、小延迟的情况下，CAP 定理还不足以对系统总体性能造成影响，但随着活动增加与吞吐量上升将凸显其重要性。对大型网站来说，可用性与分区容错性的优先级高于数据一致性，一般放弃一致性，尽量朝着可用性和分区容错性的方向设计，然后通过其他方法来保证一致性的商务需求。架构设计师不要将主要精力用在如何设计能同时满足三者的完美分布式系统，社交SNS 网站可以容忍相对较长时间的不一致性，但需要最终一致性。
CAP 的证明很简单，假设两个节点集{G1，G2}，由于网络分片导致G1 和G2 之间所有的通讯都断开了，如果在G1 中写，在G2 中读刚写入的数据， G2 中返回的值不可能是G1 中的写入值。由于可用性的要求，G2 一定要返回这次读请求，由于分区容错性的存在，导致不一致性。但由于一致性的要求，G2 一定要返回这次读请求的一致性结果，由于分区容错性的存在，导致了长期等待，出现了不可用性。

2.1 异步网络模型
在异步网络模型中，没有统一时钟，对于所有对等运算（包括消息可丢失或不丢失的对等运算），不能实现同时满足可用性、一致性和分区容错性。
一个算法无法判断一个消息是否丢失或者在传输通道中被延迟。

2.2 部分同步网络模型
对于一个部分同步的网络模型，假设所有的节点都有一个时钟，并且所有的时钟以一个相同的速度变化。然而，这些时钟并不同步，在相同的时间，它们显示不同的时间值。事实上，时钟扮演计时器的角色，处理器可以根据本地状态变量去衡量流逝了多少时间。一个本地的计时器可以用来确定调度某事件之后，经过多长时间间隔进行另一个操作。进而假设每一个消息要么在给定的时间内到达，要么丢失。并且所有节点在给定时间内处理完一个接收到的消息。在一个部分同步网络模型中，对于所有对等运算（包括消息可丢失的对等运算），不能实现同时满足可用性、一致性和分区容错性。在Google 使用廉价的PC 机搭建了强大的、高可靠的计算和存储平台之后，互联网公司一致性地选择使用PC 集群支撑全部的业务，这个理论指明了实现满足可用性、分区容错性的分布式系统可行，并且该分布式系统在没有故障的情况下可以提供良好的一致性读写。

2.3 三中取二原则
CAP 定理阐明分布系统构建中的3 个核心系统需求不能够全部同时满足，强调一致性就需要处理因为系统不可用而导致的写操作失败的情况；如果强调可用性，那么应该知道系统的读操作可能不能精确的读取到写操作写入的最新值。因此系统的强调点不同，相应采用的策略也不一样，只有真正理解了系统的需求，才有可能合理使用CAP 理论。目前互联网中的很多分布式系统是基于首要满足可用性和分区容错性而设计。当处理CAP的问题时，存在下述几个选择。

1）放弃可用性 。
如果选择分区容错性和一致性，放弃了可用性，那么即使节点损坏，为保证一致性，必须百分之百地保证所有节点之间有很好的连通性，这是很难做到的。最好的办法就是将所有数据放到同一个节点中，但显然这种设计一旦遇到分区事件，受影响的服务需要等待数据一致，在等待期间就无法对外提供服务。在多个节点上控制数据一致相当复杂，而且恢复的节点需要处理逻辑，以便平滑地返回服务状态。满足一致性与分区容错性的系统主要是一些键‘ —’值数据库， 典型代表为Google 的BigTable 等系统。

2）放弃分区容错性。
如果要满足一致性和可用性，必须要有回滚操作。这样，系统显然无法容忍分区，当同一数据的两个副本分配到了两个无法通信的分区上并需要回滚操作时，将会返回错误的数据。满足一致性和可用性的系统通常在可扩展性方面不太强，如传统的关系数据库系统MySQL 等。

3）放弃一致性。
如果选择分区容错性和可用性，放弃了一致性，当节点损坏时，遇到分区事件，受影响的服务不需要等待数据一致，就可以对外提供服务，保证了可用性。满足可用性与分区容错性的系统主要是一些面向文档的适用于分布式系统的数据库，如SimpleDB。
两个节点分处分区两侧，允许至少一个节点更新状态将导致数据不一致，即丧失了一致性。除非两个节点可以互相通信，才能既保证一致性又保证可用性，这又会导致丧失分区容错性。对于跨区域的系统，设计者无法舍弃分区容错性，那么就只能在数据一致性和可用性上做一个艰难选择。一般说来，NoSQL 的主题是创造可用性优先、数据一致性其次的方案；而传统关系数据库保持ACID 特性（原子性、一致性、隔离性和持久性）。

分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：

● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本），换句话就是说，任何时刻，所用的应用程序都能访问得到相同的数据。

● 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性），换句话就是说，任何时候，任何应用程序都可以读写数据。

● 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择，换句话说，系统可以跨网络分区线性的伸缩和扩展。

如上图所示意，不可能设计出既满足一致性，有满足可用性还同时满足分区容错性的系统。

分布式领域CAP理论：
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性

定理：任何分布式系统只可同时满足二点，没法三者兼顾。
忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区：
Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。
Consistency一致性. 在事务开始或结束时，数据库应该在一致状态。
Isolation隔离层. 事务将假定只有它自己在操作数据库，彼此不知晓。
Durability. 一旦事务完成，就不能返回。
跨数据库事务：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，JavaEE中的JTA事务可以支持2PC。因为2PC是反模式，尽量不要使用2PC，使用BASE来回避。

BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：
Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
Soft state软状态 状态可以有一段时间不同步，异步。
Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。

BASE思想的主要实现有
1.按功能划分数据库
2.sharding碎片 

BASE思想主要强调基本的可用性，如果你需要High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。

现在NOSQL运动丰富了拓展了BASE思想，可按照具体情况定制特别方案，比如忽视一致性，获得高可用性等等，NOSQL应该有下面两个流派：
1. Key-Value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。
2. 领域模型 + 分布式缓存 + 存储 （Qi4j和NoSql运动），可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。

这两者共同点：都是关系数据库SQL以外的可选方案，逻辑随着数据分布，任何模型都可以自己持久化，将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对一致性的要求程度。

不同点：NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX，可以适合非Java如PHP RUBY等领域，是一种可以拿来就用的产品，而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活，更应该是架构师必须掌握的。