CAP 理论的理解

谈到互联网架构，就会谈到分布式，谈到分布式我们就应该了解CAP理论。那就谈谈CAP的历史吧：如下

1.CAP的历史

1985年Lynch证明了异步通信中不存在任何一致性的分布式算法（FLP Impossibility）的同时，人们就开始寻找分布式系统设计的各种因素。一致性算法既然不存在，但若能找到一些设计因素，并进行适当的取舍以最大限度满足实现系统需求成为当时的重要议题。比如，在CAP之前研究者就已经发现低延迟和顺序一致性不可能同时被满足【8】。

2000年，Eric Brewer教授在PODC的研讨会上提出了一个猜想：一致性、可用性和分区容错性三者无法在分布式系统中被同时满足，并且最多只能满足其中两个！

这个猜想首次把一致性、可用性和分区容错三个因素提炼出来作为系统设计的重要特征，断言用此三者可以划分所有的分布式系统，并指明这三个特征之间的不可能性关系。Brewer猜想比单纯的“低延迟和顺序一致性不能被同时满足”的结论更具体，对实际系统的构建也更具有可操作性！

Brewer教授当时想象的分布式场景是webservice，一组websevrice后台运行着众多的server，对service的读写会反应到后台的server集群，并对CAP进行了定义：

• C（一致性）：所有的节点上的数据时刻保持同步
• A（可用性）：每个请求都能接受到一个响应，无论响应成功或失败
• P（分区容错）：系统应该能持续提供服务，即使系统内部有消息丢失（分区）

高可用、数据一致是很多系统设计的目标，但是分区又是不可避免的事情：

• CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。
• CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
• AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

CAP的出现仿佛是一盏明灯，它揭露了分布式系统的本质，并给出了设计的准则，而这正是1985年以来人们正在寻找的东西！所以CAP在当时的影响力是非常大的！

其实一个定理也好，真理也好都是需呀经过验证的，CAP理论无非是告诉我们在设计分布式的时候 就要考虑到CAP中不能满足3个方面 即：

• C（一致性）：所有的节点上的数据时刻保持同步
• A（可用性）：每个请求都能接受到一个响应，无论响应成功或失败
• P（分区容错）：系统应该能持续提供服务，即使系统内部有消息丢失（分区）

这三个场景 只能满足其中的两点 如：CA ,CP,AP 三种组合。其实谈到CAP我们就应该考虑下数据库，因为数据库方面的分布式设计是现代互联网广泛应用的，那么谈到数据库我们就要谈谈现在两大数据库阵营，关系型数据库和NOSQL类数据库。根据CAP原理我们可以把数据库做个分离

如图所示：各个数据库的分类

关注一致性和可用性的 (CA)

这些数据库对于分区容忍性方面比较不感冒，主要采用复制(Replication)这种方式来保证数据的安全性，常见的CA系统有：

1. 传统关系型数据库，比如Postgres和MySQL等(Relational) ;

关注一致性和分区容忍性的(CP)

这种系统将数据分布在多个网络分区的节点上，并保证这些数据的一致性，但是对于可用性的支持方面有问题，比如当集群出现问题的话，节点有可能因无法确保数据是一致性的而拒绝提供服务，主要的CP系统有：

1. BigTable (Column-oriented) ;
2. Hypertable (Column-oriented);
3. HBase (Column-oriented) ;
4. MongoDB (Document) ;

关于可用性和分区容忍性的(AP)

这类系统主要以实现"最终一致性(Eventual Consistency)"来确保可用性和分区容忍性，AP的系统有：

1. Dynamo (Key-value);
2. Cassandra (Column-oriented) ;

我们在来分析下这些数据库的特点，

大部分关系型数据库 都是CA的 也就是说白了，基本是单点的 这样才能符合CA的要求即：一致性，可用性但不分区。

大部分NOSQL数据库都是符合CP,和AP的，而这两个又有什么区别呢。其实可以去对比下这些数据库 对于落在AP类的数据库都有一个特点就是需要各个节点的数据是要互相复制的，因为只有这样才能保证A 即：A（可用性）：每个请求都能接受到一个响应，无论响应成功或失败。

因此经过上面分类实例理解，对于以后我们设计分布式架构无非要考虑下

• C（一致性）：单点，只有读，写都在一个节点上才能完全保证数据的一致性。（因为网络通讯是不确定的，也就是最终一致性）
• A（可用性）：为了保证服务的可用即：一个节点出问题，服务还是可用的，所以可多节点复制数据
• P（分区容错）：分区无非就是跨区域了。

所以 CA 无非考虑单点，主被。（如：mysql 的主被方案），CP无非考虑分片，主被，如：redis的分片方案 Hbase的region方案等  AP 无非是考虑 分片 数据复制 如：cassandra 分片和各个节点的数据复制。