cap理论

CAP理论由Eric Brewer在ACM PODC会议上的主题报告中提出，这个理论是NoSQL数据管理系统构建的基础，如下图所示：

 

 

▲CAP理论

　　其中字母“C”、“A”、“P”分别代表以下三个特征：

　　·强一致性(Consistency)。系统在执行过某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读取到最新的值，这样的系统被认为具有强一致性。

 

　　·可用性(Availability)。每一个操作总是能够在一定的时间内返回结果，这里需要注意的是“一定时间内”和“返回结果”。

 

　　“一定时间内”是指，系统的结果必须在给定时间内返回，如果超时则被认为不可用。这是至关重要的。比如通过网上银行的网络支付功能购买物品。当等待了很长时间，如15分钟，系统还是没有返回任务操作结果，购买者一直处于等待状态，那么购买者就不知道现在是否支付成功，还是需要进行其他操作。这样当下次购买者再次使用网络支付功能时必将心有余悸。

 

　　“返回结果”同样非常重要。还是拿这个例子来说，假如购买者点击支付之后很快出现了结果，但是结果却是“java.lang.error……”之类的错误信息。这对于普通购买者来说相当于没有返回任何结果。因为他仍旧不知道系统处于什么状态，是支付成功还是失败，或者需要重新操作。

 

　　·分区容错性(Partition Tolerance)。分区容错性可以理解为系统在存在网络分区的情况下仍然可以接受请求(满足一致性和可用性)。这里网络分区是指由于某种原因网络被分成若干个孤立的区域，而区域之间互不相通。还有一些人将分区容错性理解为系统对节点动态加入和离开的处理能力，因为节点的加入和离开可以认为是集群内部的网络分区。

 

　　CAP是在分布式环境中设计和部署系统时所要考虑的三个重要的系统需求。根据CAP理论，数据共享系统只能满足这三个特性中的两个，而不能同时满足三个条件。因此系统设计者必须在这三个特性之间做出权衡。例如Amazon的Dynamo具有高可用性和分区容错性但不支持强一致性，也就是说用户不能立即看到其他用户更新的内容。

 

　　下面通过图示来解释数据共享系统为什么不能同时满足CAP理论三个条件。

 

　　如下图所示，在网络中有两个节点分别为G1和G2，这两个节点上存储着同一数据的不同副本，现在数据是一致的，两个副本的值都为V0，A、B分别是运行在G1、G2上与数据交互的应用程序。

 

 

▲网络节点及数据分布图

　　在正常情况下，操作过程如下(如下图所示)：

　　(1)A将V0更新，数据值为V1;

　　(2)G1发送消息m给G2，数据V0更新为V1;

　　(3)B读取到G2中的数据V1。

 

▲正常情况

　　如果发生网络分区故障，那么在操作的步骤(2)将发生错误：G1发送的消息不能传送到G2上。这样数据就处于不一致的状态，B读取到的就不是最新的数据，如图2-3所示。如果我们采用一些技术如阻塞、加锁、集中控制等来保证数据的一致，那么必然会影响到系统的可用性和分区容错性。

 

 

▲网络分区故障

　　CAP理论告诉我们如果系统具有较高的可用性和较小延迟，那么节点必须能够容忍网络分区，但这时候应用程序可能会得到不同的数据(B读取到的值为V1)。

 

　　有人可能会想，如果我们对步骤(2)的操作加一个同步消息，问题会不会解决呢(同时满足CAP理论三个特性)?答案是否定的。不加同步的情况下，G1到G2的更新是不可知的，也就是说，B读取到得数据可能是V1也可能是V2，但是服务是可用的。即同时满足了“A”和“P”，但是不保证“C”一定满足。加了同步消息之后，将能够保证B读取到数据V1。但是这个同步操作必定要消耗一定的时间，尤其是在网络规模较大的情况下，当节点规模成百上千的时候，不一定能保证此时的服务是可用的。这种情况下只能满足“C”和“P”，而不能保证“A”一定满足。

 

　　CAP理论不但对此网络和通信模型有效，对其他模型同样有效，有兴趣的读者可以换其他的网络和通信模型来验证CAP理论。

 

　　根据CAP理论，系统满足三个条件中不同的两个条件会具有不同的特点，见下表：处理CAP问题的选择。

 

序  号

选  择

特    点

例    子

1

C、A

两阶段提交、缓存验证协议

传统数据库、集群数据库、LDAP、GFS文件系统

2

C、P

悲观加锁

分布式数据库、分布式加锁

3

A、P

冲突处理、乐观

DNS、Coda

　　可以看出，三种不同的组合对应着放弃了CAP三个特性当中的一个。

 

　　·放弃P：如果想避免分区容错性问题的发生，一种做法是将所有的数据(与事务相关的)都放到一台机器上。虽然无法100%地保证系统不会出错，但不会碰到由分区带来的负面效果。当然，这个选择会严重影响系统的扩展性。

 

　　·放弃A：相对于放弃“分区容错性”来说，其反面就是放弃可用性。一旦遇到分区容错故障，那么受到影响的服务需要等待数据一致，因此在等待期间系统就无法对外提供服务。

 

　　·放弃C：这里所说的放弃一致性，并不是完全放弃数据的一致性，而是放弃数据的强一致性，而保留数据的最终一致性。以网络购物为例，对只剩最后一件库存的商品，如果同时接收到了两份订单，那么较晚的订单将被告知商品售罄。

 

　　·其他选择：引入BASE(Basically Available, Soft-state, Eventually consistent)，该方法支持最终一致性，其实是放弃C的一个特例，我们将在后文进行介绍。

 

　　传统关系型数据管理系统注重数据的强一致性，但是对于海量数据的分布式存储和处理其性能不能满足人们的需求，因此现在许多NoSQL数据库牺牲了强一致性来提高性能，CAP理论对于非关系性数据库的设计有很大的影响并被NoSQL阵营所认可。

 

　http://blog.csdn.net/wind520/article/details/45792499