【分布式】CAP理论，了解一下

　　一、前言

　　面试时，面试官说，你知道CAP理论吗?你知道Base理论吗?

　　当时只知道自己在做分布式系统，对这些理论方面一无所知。下来之后，回想起来，还是百度。写一篇博客来纪念一下。二、什么是CAP理论?

　　CAP理论在大多数开发人员心中都有一定的地位，在互联网行业也有广泛的知名度。稍有经验或知识的程序员将其用作衡量系统，特别是分布式系统的设计标准，即我们所说的CAP原则。每个人都很清楚，任何分布式系统都是可用性、一致性和分区在容错性方面，我们不能兼得，就像我们常说的“鱼和熊掌不能兼得”一样，最多值得第二。因此，任何分布式系统的设计都只是根据其实际应用场景和需求选择这三个维度。

　　说了这么多，大家可能还是很傻。CAP原则是什么?先知道它的定义:

　　CAP原理，又称CAP定理，是指在分布式系统中， Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)，三者不能兼得。换句话说，在一个系统中没有算法来满足某个数据 Consistency, Availability, Partition-tolerance。

　　定义就是定义。一句话，上面的一大段废话就清楚了!也许接下来，又有一个“三脸傻逼”。什么是一致性、可用性和分区容错性?同样，上面的定义：

　　● 一致性(C)：分布式系统中的所有数据备份在同一时间是否相同。一致性被称为原子对象，任何读写都应该看起来是“原子”或串行的。(相当于所有节点访问相同的最新数据副本)

　　● 可用性(A)：集群中部分节点出现故障后，集群能否响应客户端的读写请求。(数据更新可用性高)

　　● 分区容错性(P)：就实际效果而言，分区相当于通信的时限要求。如果系统不能在时限内达成数据一致性，则意味着分区必须在C和A之间选择当前操作。

　　现在我们应该对这些基本概念有一个清晰的认识。在深入了解CAP原则之前，我们应该先了解CAP原则的过去和现在。为什么会产生这种CAP理论?

　　1985年，Lynch证明了异步通信中没有一致性的分布式算法(FLP Impossibility)与此同时，人们开始寻找分布式系统设计的各种因素。由于一致性算法不存在，因此在当时找到一些设计因素并做出适当的选择，以最大限度地满足系统的需求已成为一个重要问题。例如，在CAP之前，研究人员发现低延迟和顺序一致性不能同时得到满足。

　　2000年，Eric Brewer教授在PODC研讨会上提出了一个猜测：一致性、可用性和分区在分布式系统中，容错性三者不能同时满足，最多只能满足其中两者!该猜想首次提取了三个因素：一致性、可用性和分区容错作为系统设计的重要特征，并断言这三个因素可以划分所有分布式系统，并指出这三个特征之间的不可能关系。brewer的猜测比简单的“低延迟和顺序一致性不能同时满足”的结论更具体，对实际系统的构建也更具可操作性!当时Brewer教授想象的分布式场景是webservice。一组websevrice后台运行了许多server。service的读写将反映在后台的server集群中，并定义CAP，即上述定义。高可用性和一致的数据是许多系统设计的目标，但分区是不可避免的。CAP的出现就像一盏明灯。它揭示了分布式系统的本质，并给出了设计标准，这是自1985年以来人们正在寻找的!所以当时CAP的影响力很大!

　　2002年，Lynch和其他人证明了Brewer猜想，从而将CAP提升为定理。

　　这么顺利吗?直到今天，对CAP理论的质疑还在继续。

　　当这些理论被踢出来，人们认为分布式系统设计终于有了指导原则时，一些工程师和研究人员对CAP提出了各种质疑，有用的反例证明了CAP在各种场合的不适用性，挑战了Lynch的证明结果!看了CAP的概念定义，还是觉得很模糊?如果是这样，你并不孤单，很多人都是这样!CAP不考虑不同的基础设施、不同的应用场景、不同的网络基础和用户需求，而CAP、A、P在这些不同场景中的含义可能完全不同，这种对差异化的忽视导致了一个非常大的概念模糊，但也成为CAP问题的来源!其中，这些问题主要集中在以下几个方面：

　　概念模糊混乱，废话堆，不能作为定理 不适用于数据库事务架构 应构建不可变模型，避免CAP的复杂性 分区误导了容错概念

　　事实上，经过很长一段时间，我对这些崇高的推论和证据并不太清楚，也不是我们应该担心的，因为CAP理论的提出者和证明者也对这些问题进行了相应的“反击”!四、反击和解释

　　面对大量的质疑，brewer和Lynch终于坐不住了，于是他们出来澄清。brewer于2012年重申了“三个中的两个”，在某些情况下是不准确的。分区在很少发生的情况下，三者可以顺利合作，CAP不仅发生在整个系统中，也可能发生在某个子系统或系统的某个阶段。

　　Lynch还在10年后的2012年重写了论文，缩小了CAP应用的定义，消除了问题，展示了非单一一致性结果下CAP的广泛研究结果!顺便说一句，这意味着CAP定理仍然是正确的!

　　多么精彩的“撕裂”过程啊!但对我们来说，真正有意义的是CAP理论本身。我们应该如何看待CAP理论本身?

　　首先，CAP不适合作为适应任何场景的定理，其正确性更适合基于原子读写的NoSQL场景。虽然质疑很多，但很多质疑者只是偷欢的概念，并没有解决各种因素之间的选择问题。无论如何，C、A、P的三个概念总是有任何分布式系统，但不同的模型会有不同的呈现，有些场景可能对三者之间的关系敏感，而其他场景可能不敏感。正如Lynch所说，分布式系统有很多特点，如扩展性、优雅降级等。随着时间的发展，这些可能会被纳入研究范畴。作为开发者，这些都是我们需要考虑的问题，而不仅仅是CAP!六、CAP三者的选择

　　在处理CAP问题时，你会有几个选择。最明显的是：

　　1.(CA)放弃Partition Tolerance：

　　如果你想避免partition问题，你必须阻止它发生。一种方法是把所有的东西(与事务有关)都放在一台机器上。或者放在像rack这样的atomically-failling单元上。不能100%保证，因为有可能部分失败，但是你不太可能遇到partition问题带来的负面影响。当然，这种选择会严重影响scale的限制。

　　2.(CP)放弃Availability：

　　相对于放弃partition 对于tolerance来说，相反的是放弃availability。一旦遇到partition， 在事件中，受影响的服务需要等待相同的数据，因此在等待期间无法提供外部服务。控制多个节点将相当复杂，恢复的节点需要处理逻辑，以便顺利返回服务状态。

　　3.(AP)Consistency放弃Consistency：

　　或者像Wernerner一样 Vogels提倡的接受会变得“最终一致”(Eventually Consistent)(2008年12月更新)。Vogels文章值得一读。他在这里讨论的操作细节比我多。许多不一致性并不比你想象的更需要工作(这意味着持续的复制可能不是我们需要的)。在购买书籍的例子中，如果一本库存书收到两个订单，第二个订单将成为备份订单。只要告诉客户这种情况(请记住，这是一种罕见的情况)，也许每个人都会很高兴。七、总结

　　在Consistency， AvailabilityPartition-在tolerance中，你只能保证2点，这是真的，而且已经被这个星球上最成功的网站证实了。假如对网站有效，我看不出在企业环境中，在日常工作中，不考虑同样的折衷设计理由。当然，CAP理论只对我们的分布式系统设计起到指导作用。在设计系统时，我们不仅要考虑这三个方面。正如上面提到的，扩展和降级也是我们需要考虑的内容。只有结合实际业务需求和使用场景，才能设计出更合适的系统。