再次理解CAP

此文图和结构基本剽窃自infoq的一篇文章，还有wikipedia。文字倒是基本是自己的思路

从单机RDMS到分布式数据库

从前...大家都在使用单机，单节点的数据库。例如：sql server, mysql , oracle...

我们如果想要提升整体性能，我们必须纵向提高单节点的能力。这虽然简单，但是很贵，而且很容易就会抵达上限。

后来...大家想出了各种办法：主从复制, 分表，分库，sharding

一种选择（可用还是一致?）

原本数据库都是单节点，不存在一致性的问题。当进入分布式的世界后，就会面临选择。

例如以上图的mysql的主从复制为例，当master节点写入后，直接返回成功，还是向slave节点复制完成后才算成功？

前者保证了可用性，但是损失了强一致性，但是异步复制也能保证最终一致性。

后者保证了一致性，但是很明显损失了些性能。

CAP理论

分布式系统中的CAP理论如火如荼，每个人都在说。是否真的理解呢？

让我们重新梳理一下。

关键的定义不能少：

• C --- Consistency  一致性
• A --- Availability 可用性
• P --- Partition Tolerance 分区容忍性

这个定理起源于柏克莱加州大学（University of California, Berkeley）的计算机科学家埃里克·布鲁尔在2000年的分布式计算原则研讨会（Symposium on Principles of Distributed Computing（PODC））上提出的一个猜想。[5] 在2002年，麻省理工学院（MIT）的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明，使之成为一个定理。

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项[4]。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。

CAP理论的澄清

在提出他的CAP理论的10年之后，Brewer博士发表了一份声明，澄清他最初的“三选二”的观点被极大地简化，是为了引起讨论，并有助于超越ACID。不过，这种极大的简化，引发了无数的曲解和误会。按照他的说法，CAP三个维度，不应该是0，1的取值，而应该是范围。

我们先来分析一下：AP，CP好理解。可是AC 是什么意思？ 那意味着就无法分区，那就意味着不是分布式系统。这显然不是我们讨论的范围了。

那么既然是分布式系统，那就意味着要么是AP 要么是CP。

当网络情况好，分区不存在的情况下: 实际并不是在可用性和 一致性之间选择，而是在一致性和性能之间选择

当网络情况不好，存在分区的情况下，将会在AP 或 CP之间选择一个。 

举例来说: 当出现节点间网络中断的情况，

如果选择一致性，意味着在网络恢复 数据在节点间同步完之前是不可用的。CP

如果选择可用性，意味着我们放弃了各个节点直接的同步，我们选择了AP

在现实的世界里，没有人会放弃可用性，实际的解决方案是AP 然后在网络恢复后得到最终一致性

几种NO-SQL方案的选择

可以看出：

MongoDB,HBase,Redis选择的是强一致性，带来的肯定是整体的性能会打折扣

而Cassandra,DynamoDB选择的可用性+最终一致性。理论上说应该比前面的几种性能会好一些

关于Cassandra,MongoDB，HBase 后续将会在其他博文中逐一具体分析。

总结CAP

根据前面的描述，我们可以看出:

1. CAP 三者确实只能选2

2. 分布式系统中我们只能选择CP 或者 AP

3. 网络不断的分布式系统，我们选择的是一致性或者性能