分布式基础--CAP原理

上图是CAP原理图，看到之后，不禁引入下面几个问题，让我们一一带着问题去了解CAP。

1.什么是CAP？

2.什么是分区？

3.为什么只有3选2？

4.可用的抉择？

1. 什么是 CAP 定理

CAP原理指：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。这三个要素，最多只能实现其中俩点，三者不能兼得。

一致性(C)：在分布式系统中，访问所有节点中的数据是一致的（严格一致性）。

可用性(A)：在集群中某一节点出现故障后，集群整体是否能响应，客户端的读写请求。

分区容错性(P)：分区相当于系统时限要求，系统如果不能在时限内达成数据的一致性，就意味着出现了分区情况；当前操作，就需要在C和A中2选一，进行抉择。

2. 什么是分区

数据的复制是冗余的过程，冗余会增加可用性，可以有效负载均衡读取。而数据的分区是一个整体转换为局部的过程。将整体拆分,局部存储在多个较小空间内。这种思想映射到计算机上，当数据量过大,单个存储节点不足与存储这些数据时，就需要将数据集拆解并规整。数据分区的意义，它是用来提高数据系统的可扩展性而引入的技术方法。

3. 为什么只能 3 选 2

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP，有如下结果。

4.可用的抉择

CAP理论在分布式存储系统中，最多只能实现上面的两点。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地。

数据库事务一致性需求
　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。允许实现最终一致性。
数据库的写实时性和读实时性需求
　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
对复杂的SQL查询，特别是多表关联查询的需求
　　任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。