5.4 NoSQL 的三大基石
一、NoSQL的三大理论基石
即CAP、BASE和最终一致性
（其实最终一致性就是BASE的“E”）
二、CAP
CAP理论即Consistency（一致性），Availability（可用性）和Partition tolerance（分区容忍性）
1. Consistency一致性
指任何一个读操作总能得到之前完成的写操作的结果。也就是在分布式环境当中，所有节点保存的相同副本在同一时间必须有相同的数据。
2. Availability可用性
为了快速获取数据，发出的请求必须能在最短时间得到响应——无论成功与否总要给个反应。
3. Partition tolerance分区容忍性
当系统中一部分节点出现故障，无法和其他节点通信，则会出现网络分区。这时需要保证其他节点依然可以正常运行。也就是要达到系统的部分故障不影响其他部分运行的目标。
4. 实践问题
虽然我们希望三个特性能同时实现，但研究和实践证明，一个分布式系统最多只能同时满足其中两个特性。
例如，网络上有两台机器M1和M2，分别保存有相同的副本V1和V2。当M1出现P1进程更新了副本V1，为了保证一致性，新副本V1应传给V2，这样之后M2上若出现读操作——如进程P2——就能获得和M1上一致的数据了。
但是，如果副本更新从V1传到V2的过程失败，就须要考虑，是允许进程P2依旧可以访问M2节点的旧副本V2——即放弃一致性来保证可用性（如下图3），还是优先保证V2刷新成功再开放访问——即放弃可用性来保证一致性
对于CAP问题，三选二的组合有
(1) CA：即放弃分区容忍性。把所有事务相关内容放在同一个机器上，避免网络分区问题。其实就放弃了分布式数据库而变回集中式了，如SQL Server和MySQL，扩展性差。
(2) CP：即放弃可用性。使用网络分区，等待数据一致才允许取数据（即上面例子的第二种选择）。这就会出现一段时间数据不可访问的情况。
(3) AP：即放弃一致性。使用网络分区，无论什么情况数据访问一直开放。这样可能出现副本不一致的问题，即从不同节点取到的相同数据的版本不同。
不同产品采用不同的设计原则，所以要根据实际的业务需求选择合适的产品
三、BASE与最终一致性
BASE是Basically Available Soft state & Eventual consistency的缩写。有趣的是，base有“碱”的意思，而关系型数据库四大原则ACID的字面意思是“酸”……你细品。
1. Basically Available基本可用
指分布式系统即便部分发生问题，其他正常部分仍然可用，即允许分区失败的情况出现。
2. Soft state软状态
硬状态：数据库状态必须一直保持一致性，即任何时刻数据都必须正确。
软状态：允许数据库有不同步的时候出现，即容忍滞后性。
因为需求不同，传统关系型数据库要求硬状态，NoSQL则遵从软状态设计。
3. Eventual consistency最终一致性
强一致性：任何时候从任何节点读到的相同副本都必须是一样的最新版本。
弱一致性：短时间内从不同节点可能读到不同版本的副本。
最终一致性可以视为弱一致性的一个特例——虽然可能在过程中不能保证一致性，但最后获得的结果是一致的。当然，如果一个数据库满足强一致性，它也一定满足最终一致性。
HDFS采用强一致性来保证最终一致性，即在所有节点必须都同步完之后，写操作才会返回成功，这样从任何节点读到的值总是最新的。HBase数据的冗余备份是底层是借助底层的HDFS来实现的，所以也满足强一致性（上文提到HBase采用CP设计原则）。
有些产品，如Cassandra采用弱一致性（以AP原则设计），它有自己的一套机制来保证最终一致性。
Reference:
https://www.icourse163.org/learn/XMU-1002335004?tid=1450180443#/learn/content?type=detail&id=1214310136&sm=1