白话CAP理论

• Consistency
• Availability
• Partition tolerance

C 和 A 比较好理解，一直没搞懂 P 是个什么玩意，今天翻了翻网页，记录一下自己的理解。

分布式是和单机相对的一个概念。IT行业刚兴起的时候，服务功能都比较单一，访问量也不大，部署在单台服务器上就足够使用了。

随着互联网的普及，单台服务器的性能出现了瓶颈。

中间有个时期的解决方案是不断研发高性能的服务器，到后来单台服务器性能也hold不住，而且高性能服务器越来越贵，这个时期对应的扩展方式叫纵向扩展。

后来发现用多台廉价的服务器能达到单台高性能服务器同样甚至更高的性能，而且还可以不断增加服务器的方式扩展服务性能，这是个近似线性的效果。这个时期对应的扩展方式叫横向扩展，分布式慢慢登上历史舞台。

后来随着业务复杂度的增加，服务的数量也不断增加，分布式的盘子也越来越大，系统的复杂性呈指数级上升。

0.999^100 = 0.9047921471
0.999^200 = 0.8186488295
0.999^300 = 0.7407070322
...

假设原来单个应用的可用性为99.9%，100个应用的分布式系统可用性直接下降到90%，这对用户来说是不能忍受的，工程师们就得想各种办法消除这10%的影响。

一致性：针对同一应用的多个实例而言，写操作只能由一个实例去执行，紧接着如果第二个请求去其他实例上执行查询操作，就会出现数据找不到或者状态不对的情况，这便是数据一致性的问题，我们的目标是同一时间访问任意一个实例得到的结果都是相同的。

可用性：我们去请求应用的时候，肯定是希望应用能够快速且准确的响应我们，如果你在浏览器数据https://www.baidu.com,过了一分钟才给你返回首页，你的心里肯定是崩溃的。这个就是可用性问题，我们的目标是每次请求都能够及时返回非错误的响应。

严格的说，一致性和可用性本身就互斥，要保证一致性，肯定要在单台实例上执行写操作的同时将数据写到其他实例上去，考虑并发的情况，必须对这个写过程加锁，然而加锁必然会导致可用性降低。然而我在这里BB的是理论情况，实际上对于可用性而言50ms返回和60ms返回对我们并没有什么太大的区别。所以一般情况下，我们认为这两个目标也是可以同时实现的。现在请再读一遍前一句话，那二般情况下呢？二般情况就是要解决的上面的10%，也就是各种异常情况：

• 应用实例宕机
• 增加/减少应用实例
• 实例间网络中断

上面列的各种异常情况就是所谓的分区，分区容忍性便是我们的第三个目标：如何在各种异常情况下保证一致性和可用性。

然而。。。。。CAP理论告诉我们，这三者不可能同时实现。

看到这个理论，我不知道你们，反正我是一脸懵逼状。我自己的困惑在于没有区分上面提到的一般情况和二般情况。一般情况也就是各种条件都正常的情况下，也就不存在所谓的分区，这时候AP是可以实现的；CAP作为一个分布式理论，就是为了解决分区的问题，这时候回过头再看，其实CAP讨论的是Partition（10%问题）为前提的情况下，AP如何保证。这一点其实从 Partition tolerance 也可以看出来，Partition 是前提，tolerance 是目标。

现在我们讨论下分区情况下，AP的问题。

我们假设应用A有10个服务实例，此时发生了网络分区，此时写操作的一致性必然不能保证了，要想达到

同一时间访问任意一个实例得到的结果都是相同的

这一目标，必须禁用应用的写功能，显然可用性受到了影响。如果目标改为可用性，要达到

每次请求都能够及时返回非错误的响应

这一目标，应用得正常，读写服务就都不能停，显然一致性又受到了影响。

以上是我理解的CAP理论，实际环境中，AP的选择要视业务而定，不能一概而论。

白话描述旨在理解，有描述不严谨的地方还请指正。