数据库中的CAP原理

去年在参加盒子科技秋招笔试题中遇到过，印象深刻，一直想要查资料总结下来。

这个理论是由美国著名科学家，同时也是著名互联网企业Inktomi的创始人Eric Brewer在2000年PODC(Symposium on Principles of Distributed Computing)大会上提出的，后来Seth Gilbert 和 Nancy lynch两人也证明了CAP理论的正确性，虽然在后来近十年的时间很多人对CAP理论提出了很多异议，但是在NoSQL的世界中，它还是非常有参考价值的。它的意思是，一个分布式系统不能同时满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。

CAP概述

---

C：Consistency 一致性

A:   Availability 可用性

P：Partition Tolerance 区分容错性

CAP 理论核心是：一个分布式系统不可能同时很好的满足一致性，一致性和区分容错性这三个需求，最多只能同时较好的满足两个。

因此，根据CAP原理，将NoSQL数据库分成满足CA原则、CP原则和AP原则 三大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。 （传统数据库）
CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。 （Redis、MongoDB）
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。 （大多数网站架构的选择）

CAP的定义 

---

Consistency 一致性

对于一致性这个特点，可以分为客户端和服务端两个不同的视角。对于客户端而言，一致性主要指的是多并发访问同时更新过的数据如何获取的问题。从服务端而言，则是更新如何复制到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题上时，一定要结合考虑并发读写的场景。

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

Availability 可用性

对于一个可用的分布式系统，每一个非故障节点必须对每一个请求做出响应。也就是，该系统使用的任何算法必须最终终止。当同时要求分区容忍时，这是一个很强的定义：即使是严重的网络错误，每个请求必须终止。

好的可用性主要指的是系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。可用性通常指的是可用性和分布式数据冗余，负载均衡等有着很大的关联。

Partition Tolerance 区分容错性

区分容错性和扩展性紧密相关，在分布式应用中，可能因为一些分布式原因导致系统无法正常运行，好的分区容错性要求能够使应用虽然是一个分布式系统，而看上去确好像在一个可以运转正常的整体，比如现在分布式系统中有一个或者几个宕机了，其他剩余的机器能够正常运转；或者是机器之间网络异常，将分布式系统分隔未独立的几个部分，几个部分还能维持分布式系统的运作，这样就具有好的分区容错性。