CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）。
三者不可兼得，只能满足3进2。
● 一致性Consistency（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。就是要求数据实时的精准。
● 可用性Availability（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）。部分节点出了故障，但是整体读写更新请求，是否仍能满足需求的状态高低。。
● 分区容错性 Partition Tolerance（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出取舍的选择。
对于分布式的NOSQL中，这个P分布式容错性 已经被占用。分区之后的数据一致性需要一个通信时间差，如果你要时间很短，就要从C和A中舍弃一个。
对于复杂的应用，比如SNS社交类型的FaceBook这样的网站，数据量很大。
又是分布式的数据，我们就用K/V键值对的存储形式，放在一张表中查询，避免了分布式上的多表的查询。
用一张多个字段的表来解决问题，但是当字段更多的时候Mysql也不能够支持了。那么必须要上redis 这种支持k/v 键值对的
nosql类型数据库挡在mysql前面来协助mysql。
衍生出来的BASE理论：放弃某一个时间段上的一致性的要求，采取的折中手段。
BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。
很好理解：
既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式[软状态：给予一定的时间弹性]来使系统达到最终一致性（Eventual consistency）。
1.Basically Available(基本可用性)：
节点部分机器出来故障导致出来的表现 如下 ↓
①响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的搜索引擎可以在 1 秒作用返回结果。
②功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
2.软状态指的是：
允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
3.最终一致性，即字面上的意思。
而在实际工程实践中，最终一致性分为 5 种：
1. 因果一致性（Causal consistency）
指的是：如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。
2. 读己之所写（Read your writes）
这种就很简单了，节点 A 更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。
3. 会话一致性（Session consistency）
会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
4. 单调读一致性（Monotonic read consistency）
单调读一致性是指如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
5. 单调写一致性（Monotonic write consistency）
指一个系统要能够保证来自同一个节点的写操作被顺序的执行。
然而，在实际的实践中，这 5 种系统往往会结合使用，以构建一个具有最终一致性的分布式系统。实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的，比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。