分布式CAP中情侣的纠缠故事，真是剪不断 理还乱！

-     CAP的前世今生     -

1.1 起源

CAP理论，被戏称为“帽子理论”，CAP是Eric Brewer在2000年ACM研讨会上出了一个想法：“一致性、可用性和分区容错性三者无法在分布式系统中被同时满足，并且最多只能满足其中两个！”

2002年，Seth Gilbert和Nancy Lynch采用反正法证明了猜想：“如果三者可同时满足，则因为允许P的存在，一定存在Server之间的丢包，如此则不能保证C。” 在该证明中，对CAP的定义进行了更明确的声明。

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

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

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

但是只证明了CAP三者不可能同时满足，并没有证明任意二者都可满足的问题；所以该证明被认为是一个收窄的结果，在之后10年里受到各种质疑。

1.2 重新诠释

2012年，Brewer和Lynch针对所有的质疑进行了回应，重新诠释CAP。“3个中的2个”表述是不准确的，在某些分区极少发生的情况下，三者也能顺畅地配合。CAP不仅仅是发生在整个系统中，可能是发生在某个子系统或系统的某个阶段。把CAP理论的证明局限在原子读写的场景，并申明不支持数据库事务之类的场景。一致性场景不会引入用户agent，只是发生在后台集群之内。把分区容错归结为一个对网络环境的陈述，而非之前一个独立条件。引入了活(liveness)和安全属性(safety)，在一个更抽象的概念下研究分布式系统，并认为CAP是活性与安全属性之间权衡的一个特例。其中的一致性属于liveness，可用性属safety。

网络存在同步、部分同步；一致性性的结果也从仅存在一个到存在N个（部分一致）；引入了通信周期round，保证N个一致性结果。

总结：缩小CAP适用的定义，消除质疑的场景；展示了CAP在非单一一致性结果下的广阔的研究结果。

-     CAP的分析     -

2.1 组成

Consistency：一致性

Availability：可用性

Partition tolerance：分区容忍性

2.2 Consistency

从论文上看：操作之后的读操作，必须返回该值。

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

总结：在分布式系统中，C代表任何人在任何地点、任何时间，访问任何数据 结果都是一致的。

2.3 Availability

从论文上看：只要收到用户的请求，服务器就必须给出回应。

从百科上看：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。

总结：在分布式系统中，A代表服务在任何时候都要是可用的、可访问。

2.4 Partition tolerance

从论文上看：直译叫“分区容错”，意思是区间通信可能失败。

从百科上看：分区相当于对通信的时限要求。

总结：分区容错=分区+容错。分布式系统因为多实例部署，面临多个子网络，多个子网络存在网络通讯的需求；因为网络通讯的不可靠性造成分区的存在。而分区的存在，不可避免出现数据和可用性问题，需要有容错机制来处理。

-     实践分析     -

3.1 A与P的差异

从上述的描述中，因为两者都有容错可用的描述，我们很容易将A 跟 P 混淆在一起。接下去，咱们从各个维度去分析C 与P的差异。

1、从关注点来说，A关注的是用户对分布式系统的可用要求；P关注的是分布式系统实例间的网络连通性。

2、从要求上来看，A从外部的视角，要求分布式系统在正常响应时间内一直可用；P从实例节点的视角出发，在遇到某节点或节点间通信故障的时候，要求分布式系统整体对节点的容错及恢复性。

3、从受众上分析，A针对的是用户，P针对的是服务实例。

3.2 CP与AP

三者的组合，产生了AC、AP、CP三个组合。但在分布式环境中，多实例部署是基本条件，因为网络的不可靠性，造成了P成了硬性条件。所以结果就转化成了CP、AP两个分支。

CP、AP分支代表的是硬性条件，在这个基础上去追求利益化才是这个分支的本质问题。如果是粗暴的对另外一个选项直接放弃，那这个世界就太simple、easy了，而且也不符合咱们对系统的期望和基本使用。这就是2012年重新诠释后CAP的最终状态意义，“三选二”是一个伪命题。

基于这个2012年CAP的最终意义，咱们发现CP不是简单的放弃A，而是保障CP的硬性条件去追求A。所以产生了过半写入这样非常经典的使用方式:过半写入后，分布式节点可以根据少数服从多数完成数据的一致性要求。因此产生了最大的效益

1、分布式实例的更高可用性，对所有实例不在全部写入成功才认为是成功。

2、分布式实例的更快响应性，使用广播快速获取过半结果后直接认定结果。依靠补充手段实现数据的一致性。

说完CP的改变，再说说AP的对应调整升级。咱们为了高可用放弃数据的一致性，其实这个说法是不严谨，也是错误的。数据一致性是系统的基本要求。那么要怎么理解AP，应该从脏读、幻读来说，场景允许数据的短暂不一致，接受数据的最终一致性。

1、数据的严谨性是系统的一个要求，但允许数据的一定延迟是AP存在的意义。

2、系统的高可用可以满足更多的群体，从这个的目标上，所以AP是比较友好的

因为分布式系统，系统是多层面的组合型存在，所以我们并不会说一个系统是AP还是CP。我们是根据系统的业务场景去选择CP和AP，但是高可用是互联网分布式应用的特性，所以我们绝大部分情况是追求AP，尽量让系统满足更多的用户。然后基于某些场景数据的强一致性必要性去选择CP。

总结

在分布式环境下，对cap的要求。不管cp 还是ap，并不是完全丢弃另一个，而是优先级问题；在满足C或者A的基础上去追求另外一个，结论如下：

1、CP--在强一致性的底线上追求可用性 (案例-过半写入)。

2、AP—在高可用的基础上追求数据的一致性(案例-最终一致性)。

3、系统以AP为基调，在一些数据高即时、一致性场景使用CP进行补充。

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：

长按订阅更多精彩▼
如有收获，点个在看，诚挚感谢