NoSql中的CAP原则
C：一致性 。A：可用性。P：分区容错性
Partition tolerance(分区容错性)：
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。下图中，G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息，G2 可能无法收到。系统设计的时候，必须考虑到这种情况。一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。
Consistency(一致性)
任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的。问题是，用户有可能向 G2 发起读操作，由于 G2 的值没有发生变化，因此返回的是 v0。G1 和 G2 读操作的结果不一致，这就不满足一致性了。
为了让 G2 也能变为 v1，就要在 G1 写操作的时候，让 G1 向 G2 发送一条消息，要求 G2 也改成 v1。
Availability(可用性)
只要收到用户的请求，服务器就必须给出回应。用户可以向G1或者G2发起读操作，不管是哪台服务器，只要收到请求，就必须告诉用户到底是V0还是V1，否则就不满足可用性。 一致性和可用性不可能同时成立，因为通讯可能失败(即出现分区容错) 如果需要保证G2的一致性，那么G1必须在写操作时锁定G2的读操作和写操作。只有数据同步后才重新开放读写。锁定期间G2是不能读写的，所有没有可用性。如果需要保证G2的可用性那么势必不能锁定G2，但是G1和G2的一致性就不成立。所以G2无法同时做到一致性和可用性。系统设计时只能选择一个目标， 追求一致性那么就无法保证可用性，如过追求可用性就无法做到一致性。
CA：传统Oracle数据库。
AP：大多数网站架构的选择。
CP：Redis，MongoDB （弱一致性，高可用性和分区容错性）。
Base
Bas理论是对CAP中一致性和可用性权衡的结果，其来源与对大型互联网分布式实践的总结，是基于CAP定理逐步演化而来的。 Base全称 Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。其核心思想是即是无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终的一致性(Eventual consistency)。
Basically Available(基本可用)
- 假设系统出现了不可预知的故障，但是还是能用的。相比较正常的系统而言响应时间上的损失，比如正常需要0.5秒返回用户结果，而基本可用可以在1秒返回结果。或功能上的损失。
Soft state（软状态）
- 相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。 软状态指的是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
Eventually consistent（最终一致性）
- 数据不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。
最终一致性分为五种
- 因果一致性（Causal consistency）： 指的是如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。
- 读已之所写(Read your writes) ：节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。
- 会话一致性(session consistency)： 会话一致性将对系统数据的访问过程框定在了一个会话当中,系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
- 单调读一致性(Monotonic read consistency) ：单调读一致性是指如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
- 当调写一致性(Monotonic write consistency)： 指一个系统要能够保证来自同一个节点的写操作被顺序的执行。 在实际的实践中，这 5 种系统往往会结合使用，以构建一个具有最终一致性的分布式系统。实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的，比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例
