分布式理论：CAP是三选二吗?

本文转载自 分布式理论：CAP三选二

CAP是什么？

CAP理论，被戏称为[帽子理论]。CAP理论由Eric Brewer在ACM研讨会上提出，然后CAP被奉为分布式领域的重要理论[1] 。

分布式系统的CAP理论：首先把分布式系统中的三个特性进行了以下概括：

● 一致性（C）：在分布式系统中的全部数据备份，在同一时刻是否一样的值。（等同于全部节点访问同一份最新的数据副本）

● 可用性（A）：在集群中一部分节点故障后，集群总体是否还能响应客户端的读写请求。（对数据更新具有高可用性）

● 分区容忍性（P）：以实际效果而言，分区至关于对通讯的时限要求。系统若是不能在时限内达成数据一致性，就意味着发生了分区的状况，必须就当前操做在C和A之间作出选择。（分区状态能够理解为部分机器不连通了，好比机器挂了，繁忙失去响应，单机房故障等）

Partition字面意思是网络分区，即因网络因素将系统分隔为多个单独的部分，有人可能会说，网络分区的状况发生几率很是小啊，是否是不用考虑P，保证CA就好。要理解P，咱们看回CAP证实中P的定义： In order to model partition tolerance, the network will be allowed to losearbitrarily many messages sent from one node to another.

网络分区的状况符合该定义，网络丢包的状况也符合以上定义，另外节点宕机，其余节点发往宕机节点的包也将丢失，这种状况一样符合定义。现实状况下咱们面对的是一个不可靠的网络、有必定几率宕机的设备，这两个因素都会致使Partition，于是分布式系统实现中 P 是一个必须项，而不是可选项。

高可用、数据一致性是不少系统设计的目标，可是分区又是不可避免的事情。咱们来看一看分别拥有CA、CP和AP的状况。

CA without P：若是不要求P（不容许分区），则C（强一致性）和A（可用性）是能够保证的。但其实分区不是你想不想的问题，而是始终会存在，CA系统基本上是单机系统，好比单机数据库。2PC是实现强一致性的具体手段。

from http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

CP without A：若是不要求A（可用），至关于每一个请求都须要在Server之间强一致，而P（分区）会致使同步时间无限延长，如此CP也是能够保证的。不少传统的数据库分布式事务都属于这种模式。

from 同上

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

from 同上

CAP理论的证实

该理论由brewer提出，2年后就是2002年，Lynch与其余人证实了Brewer猜测，从而把CAP上升为一个定理。可是，它只是证实了CAP三者不可能同时知足，并无证实任意两者均可知足的问题，因此，该证实被认为是一个收窄的结果。

Lynch的证实相对比较简单：采用反证法，若是三者可同时知足，则由于容许P的存在，必定存在Server之间的丢包，如此则不能保证C，证实简洁而严谨。

在该证实中，对CAP的定义进行了更明确的声明：

· C：一致性被称为原子对象，任何的读写都应该看起来是“原子“的，或串行的。写后面的读必定能读到前面写的内容。全部的读写请求都好像被全局排序同样。

· A：对任何非失败节点都应该在有限时间内给出请求的回应。（请求的可终止性）

· P：容许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会彻底丢失。

对于CAP进一步的案例解释

2010年的这篇文章brewers-cap-theorem-on-distributed-systems/，用了三个例子来阐述CAP，分别是example1：单点的mysql；example2：两个mysql，但不一样的mysql存储不一样的数据子集,至关于sharding；example3：两个mysql，对A的一个insert操做，须要在B上执行成功才认为操做完成（相似复制集）。做者认为在example1和example2上 都能保证强一致性，但不能保证可用性；在example3这个例子，因为分区（partition）的存在，就须要在一致性与可用性之间权衡。对于复制而言，在不少场景下不追求强一致性。好比用户支付以后，交易记录落地了；但可能消费记录的消息同步存在延迟，好比消息阻塞了。在金融业务中，采起相似两地三中心架构，每每可能采起本地数据和异地机房数据同时写成功再返回的方式。这样付出了性能的损耗，响应时间变长。但发生机房故障后，能确保数据是彻底能够读写的，保障了一致性。

CAP理论澄清

[CAP理论十二年回顾：”规则”变了]一文首发于 Computer 杂志，后由InfoQ和IEEE联合呈现,很是精彩[2]，文章表达了几个观点。

“三选二”是一个伪命题

不是为了P（分区容忍性），要在A和C之间选择一个。分区不多出现，CAP在大多数时候容许完美的C和A。但当分区存在或可感知其影响的状况下，就要预备一种策略去探知分区并显式处理其影响。这样的策略应分为三个步骤：探知分区发生，进入显式的分区模式以限制某些操做，启动恢复过程以恢复数据一致性并补偿分区期间发生的错误。

“一致性的做用范围”其实反映了这样一种观念，即在必定的边界内状态是一致的，但超出了边界就无从谈起。好比在一个主分区内能够保证完备的一致性和可用性，而在分区外服务是不可用的。Paxos算法和原子性多播（atomic multicast）系统通常符合这样的场景。像Google的通常作法是将主分区归属在单个数据中内心面，而后交给Paxos算法去解决跨区域的问题，一方面保证全局协商一致（global consensus）如Chubby，一方面实现高可用的持久性存储如Megastore。

ACID、BASE、CAP

ACID和BASE 这两个术语都好记有余而精确不足，出现较晚的BASE硬凑的感受更明显，它是“Basically Available, Softstate, Eventually consistent（基本可用、软状态、最终一致性）”的首字母缩写。其中的软状态和最终一致性这两种技巧擅于对付存在分区的场合，并所以提升了可用性。

CAP与ACID的关系更复杂一些，也所以引发更多误解。其中一个缘由是ACID的C和A字母所表明的概念不一样于CAP的C和A。还有一个缘由是选择可用性只部分地影响ACID约束。

进一步看[分区]以后

用一下这张图[引用自 link 2]，在状态S的时候是非分区状态，而分区模式则演化出来了S1，S2，那么问题来了，分区恢复以后，状态到底是多少呢？有几种解决方案。

分区恢复策略：可交换多副本数据类型

注意，能支持此类处理的场景是有限的。

riak_dt 就是这样一种保障最终一致性实现的数据结构，它分为Operation-based CRDTs、State-based CRDTs 2种形态。

riak_dt link参见 link [3]。

State-based CRDTs

State-based CRDTs are called convergent replicated data types,or CvRDTs. In contrast to CmRDTs, CvRDTs send their full localstate to other replicas. CvRDTs have the following local interface:

· query – reads the state of the replica, with no sideeffects

· update – writes to the replica state in accordance withcertain restrictions

· merge – merges local state with the state of some remotereplica

The merge function must be commutative, associative, andidempotent. It provides a join for any pair of replica states, so theset of all states forms asemilattice. The update functionmust monotonically increase the internal state, according to thesame partial order rules as the semilattice.

from：https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type

分区恢复策略：回放合并

在分区恢复过程当中，设计师必须解决两个问题：

分区两侧的状态最终必须保持一致， 而且必须补偿分区期间产生的错误。 如上图所示，对于分区恢复的状态S*能够经过未分区时的状态S为起点，而后按顺序[回放]相应的变化事件[以特定方式推动分区两侧的一系列操做，并在过程当中一直保持一致的状态。]。Bayou[link 4]就是这个实现机制，它会回滚数据库到正确的时刻并按无歧义的、肯定性的顺序从新执行全部的操做，最终使全部的节点达到相同的状态。

对于有冲突的状况，好比版本管理软件cvs，存在人工介入、消除冲突的处理策略。

有限制处理

有限制处理：[link 2]提的自动柜员机补偿问题，比较形象说明了这个问题。此问题本质上是可用性和一致性的折衷处理。

以自动柜员机（ATM）的设计来讲，强一致性看似符合逻辑的选择，但现实状况是可用性远比一致性重要。理由很简单：高可用性意味着高收入。无论怎么样，讨论如何补偿分区期间被破坏的不变性约束，ATM的设计很适合做为例子。

ATM的基本操做是存款、取款、查看余额。关键的不变性约束是余额应大于或等于零。由于只有取款操做会触犯这项不变性约束，也就只有取款操做将受到特别对待，其余两种操做随时均可以执行。

ATM系统设计师能够选择在分区期间禁止取款操做，由于在那段时间里没办法知道真实的余额，固然这样会损害可用性。现代ATM的作法正相反，在stand-in模式下（即分区模式），ATM限制净取款额不得高于k，好比k为$200。低于限额的时候，取款彻底正常；当超过限额的时候，系统拒绝取款操做。这样，ATM成功将可用性限制在一个合理的水平上，既容许取款操做，又限制了风险。

分区结束的时候，必须有一些措施来恢复一致性和补偿分区期间系统所形成的错误。状态的恢复比较简单，由于操做都是符合交换率的，补偿就要分几种状况去考虑。最后的余额低于零违反了不变性约束。因为ATM已经把钱吐出去了，错误成了外部实在。银行的补偿办法是收取透支费并期望顾客偿还。由于风险已经受到限制，问题并不严重。还有一种状况是分区期间的某一刻余额已经小于零（但ATM不知道），此时一笔存款从新将余额变为正的。银行能够追溯产生透支费，也能够由于顾客已经缴付而忽略该违反状况。

总而言之，由于通讯延迟的存在，银行系统不依靠一致性来保证正确性，而更多地依靠审计和补偿。“空头支票诈骗”也是相似的例子，顾客赶在多家分行对帐以前分别取出钱来而后逃跑。透支的错误事后才会被发现，对错误的补偿也许体现为法律行动的形式。

此前，中行IBM大型机宕机，系统没有第一时间切换到热备或者异地容灾上，直接影响中行的信用卡支付相关业务，直到4小时以后才恢复服务。有对应的的缘由包括平常演练等问题，等更重要的是在[可用性和一致性]之间选择了一致性，4H以后提供服务，备库仍然主要起数据备份的做用。

有限制处理方案是须要冒险滴，为了保障可用性，没法保障数据100%精确，能够折衷提供部分有损服务。好比取款根据信用是否是能限制必定金额，而存款是Ok的等等。大额对公业务也能够采起具体办法，固然这将在精细化管理服务能力及配套能力上付出更多的IT成本。

有关中行IBM大型机宕机的报道link：

http://digi.tech.qq.com/zt2013/syibm/

http://www.infoq.com/cn/news/2013/04/BOC-Downtime/

超越CAP？

Nathan Marz：How to beat theCAP theorem

2011年11月Twitter的首席工程师Nathan Marz写了一篇文章，描述了他是如何试图战胜CAP定理的： How to beat the CAP theorem

做者表示不是要“击败”CAP，而是尝试对数据存储系统进行从新设计，以可控的复杂度来实现CAP。Marz认为一个分布式系统面临CAP难题的两大问题就是：在数据库中如何使用不断变化的数据，如何使用算法来更新数据库中的数据。

Marz提出了2个基本思路：

1. 数据不存在update，只存在append操做。这样就把对数据的处理由CRUD变为CR；一样的，delete操做也能够处理为add一条新记录：好比 友强取消了对山丘的关注，传统关系型数据库是在关系表删除一条记录，而Marz也能够新增一条关系为[取消]的记录。

2. 全部的数据的操做就只剩下Create和Read。把Read做为一个Query来处理，而一个Query就是一个对整个数据集执行一个函数操做。

总结，在有必定时序性，且对实时一致性要求不高的场景下能够选择使用，毕竟在问题解决域多了一把锤子。Query过程当中的跨分区函数仍然是一种合并的变种（Merge）！

OceanBase的另类之路

既然更新数据涉及到分区问题，那么能不能把更新放到一个服务器呢[脑洞大开]？而后经过强大的软件+硬件能力一块儿去保障它！同时已经不修改的数据自然具有可扩展性！这是我粗暴理解OceanBase的基本设计思想。

link[5] 写道：做为电子商务企业，淘宝和其余公司的业务对一致性和可用性的要求高于分区容错性，数据特征是数据总量庞大且逐步增长，单位时间内的数据更新量并不大，但实时性要求很高。这就要求咱们提供一套更加偏重于支持CA特性的系统，同时兼顾可分区性，而且在实时性、成本、性能等方面表现良好。

OceanBase的逻辑架构简图

关于UpdateServer的性能问题

其实大部分数据库天天的修改次数至关有限，只有少数修改比较频繁的数据库才有天天几亿次的修改次数。另外，数据库平均每次修改涉及的数据量不多，不少时候只有几十个字节到几百个字节。假设数据库天天更新1亿次，平均每次须要消耗100字节，天天插入1000万次，平均每次须要消耗1000字节，那么，一天的修改量为：1亿 * 100 + 1000万 *1000 = 20GB，若是内存数据结构膨胀2倍，占用内存只有40GB。而当前主流的服务器均可以配置96GB内存，一些高档的服务器甚至能够配置192GB、384GB乃至更多内存。

TiDB

TiDB 是国内 PingCAP 团队开发的一个分布式 SQL 数据库。其灵感来自于 Google 的 F1, TiDB 支持包括传统 RDBMS 和 NoSQL 的特性。从下面这篇访谈来看，分布式事务早期版本中，他们参考的是Google 的 Percolator 的模型。目前该项目逐步归入商用，有兴趣的朋友参考下面的link[6]。

[1] link：http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

[2] link：http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed/

[3] link：https://github.com/basho/riak_dt

[4] link：http://www.cs.berkeley.edu/~brewer/cs262b/update-conflicts.pdf

[5] link：http://code.taobao.org/p/OceanBase/wiki/intro/

[6] link：http://mt.sohu.com/20160122/n435472384.shtml

总结：CAP是分布式领域的重要理论，但不表明彻底不能有延展的解读和思考。另外[三选二]自己也是有条件成立的，不能简单误读，一切取决于应用场景。若是不加选择按照理论形式无异于刻舟求剑。

欲了解更多有关分布式缓存方面的内容，请阅读《深刻分布式缓存:从原理到实践》一书。