标签：
此文图和结构基本剽窃自infoq的一篇文章，还有wikipedia。文字倒是基本是自己的思路
从前...大家都在使用单机，单节点的数据库。例如：sql server, mysql , oracle...
我们如果想要提升整体性能，我们必须纵向提高单节点的能力。这虽然简单，但是很贵，而且很容易就会抵达上限。
后来...大家想出了各种办法：主从复制, 分表，分库，sharding
原本数据库都是单节点，不存在一致性的问题。当进入分布式的世界后，就会面临选择。
例如以上图的mysql的主从复制为例，当master节点写入后，直接返回成功，还是向slave节点复制完成后才算成功？
前者保证了可用性，但是损失了强一致性，但是异步复制也能保证最终一致性。
后者保证了一致性，但是很明显损失了些性能。
分布式系统中的CAP理论如火如荼，每个人都在说。是否真的理解呢？
让我们重新梳理一下。
关键的定义不能少：
在提出他的CAP理论的10年之后，Brewer博士发表了一份声明，澄清他最初的“三选二”的观点被极大地简化，是为了引起讨论，并有助于超越ACID。不过，这种极大的简化，引发了无数的曲解和误会。按照他的说法，CAP三个维度，不应该是0，1的取值，而应该是范围。
我们先来分析一下：AP，CP好理解。可是AC 是什么意思？ 那意味着就无法分区，那就意味着不是分布式系统。这显然不是我们讨论的范围了。
那么既然是分布式系统，那就意味着要么是AP 要么是CP。
当网络情况好，分区不存在的情况下: 实际并不是在可用性和 一致性之间选择，而是在一致性和性能之间选择
当网络情况不好，存在分区的情况下，将会在AP 或 CP之间选择一个。
举例来说: 当出现节点间网络中断的情况，
如果选择一致性，意味着在网络恢复 数据在节点间同步完之前是不可用的。CP
如果选择可用性，意味着我们放弃了各个节点直接的同步，我们选择了AP
在现实的世界里，没有人会放弃可用性，实际的解决方案是AP 然后在网络恢复后得到最终一致性
可以看出：
MongoDB,HBase,Redis选择的是强一致性，带来的肯定是整体的性能会打折扣
而Cassandra,DynamoDB选择的可用性+最终一致性。理论上说应该比前面的几种性能会好一些
关于Cassandra,MongoDB，HBase 后续将会在其他博文中逐一具体分析。
标签：
原文地址：http://blog.csdn.net/stewart/article/details/51240433
