NOSQL基石：CAP-BASE-最终一致性

1、RDBMS的困境

RDBMS有以下三大困境：

1. 高并发：12306春节抢票、双11等场景下动则亿级并发，而现有RDBMS是能实现千级session。访问一次磁盘10ms, 已mysql的B+树千万级数据为2-4层存储，获取一次数据的代价为20-40ms。1秒钟理想的最大并发 1000 * 50 = 5W
2. 高效海量数据存储：数据量已经不是用GB、TB来衡量了，而是EB、ZB了，面对这海量的数据，如何高效率的存储这些数据，以Oracle为例，单机的物理扩展不仅成本高，而且难度也加大了
3. 高可用&高扩展：Oracle即使RAC能扩展数台机器，但数量也是有限

NoSql的出现即是为了解决这些问题了，但是NoSql并不是用来替代关系型数据库的，因为它本身也有着不可克服的缺陷。

2、 什么是CAP原则

CAP原则：

• 一致性（C）：读操作总能读到之前完成的写操作的结果。也就是在分布式系统中，多点数据是一致的
• 可用性(A)：读操作总能在确定的时间内得到结果，保证每个请求都能得到不管成功还是失败的响应，而不是阻塞。
• 分区容错性§：出现网络分区情况下（系统中的部分节点无法与其他节点进行通讯），分离系统仍然能够正常运行
  
  从这个图中我们看到三者重合的情况是做不到的，只能满足CA, AP, CP的22组合中的一种。鱼和熊掌不可兼得，不同的选择，衍生出不同的解决方案。
  举例，为满足一致性，需要确保多副本数据一致，就使得多副本写数据过程中无法响应读请求。所以，NOSql数据库都不能同时满足CA(一致性和可用性)两个要求。关系型数据库可同时满足CA(一致性和可用性)。典型的NOSql数据库Redis、HBase、MongoDB、Neo4j都不能满足CA特性，可满足CP特性。
  

3、什么BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

3.1 强一致性ACID和弱一致性BASE

3.2 一个RDBMS系统具有的ACID特性

• A（Atomicity）：原子性，是指事务必须是原子工作单元，对于其数据修改(包括新增，修改，删除数据)，要么全都执行，要么全都不执行
• C（Consistency）：一致性，是指事务在完成时，必须使所有的数据都保持一致状态
• I（Isolation）：隔离性，是指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离
• D（Durability）：持久性，是指事务完成之后，它对于系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持

3.3 一个NOSQL具有的BASE特性

1. 基本可用
   基本可用，是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现
   1、响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
   2、功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
2. 软状态
   “软状态（soft-state）”是与“硬状态（hard-state）”相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性
3. 最终一致性
   一致性的类型包括强一致性和弱一致性，二者的主要区别在于高并发的数据访问操作下，后续操作是否能够获取最新的数据。对于强一致性而言，当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据；反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例，允许后续的访问操作可以暂时读不到更新后的数据，但是经过一段时间之后，必须最终读到更新后的数据。
   最常见的实现最终一致性的系统是DNS（域名系统）。一个域名更新操作根据配置的形式被分发出去，并结合有过期机制的缓存；最终所有的客户端可以看到最新的值。

4、最终一致性

4.1 如何实现各种类型的一致性？

对于分布式数据系统：

• N — 数据复制的份数
• W — 更新数据是需要保证写完成的节点数(一个写操作，只有W个节点都写成功，本次写操作才返回成功)
• R — 读取数据的时候需要读取的节点数(一个读操作，只有R个节点都读成功，本次读操作才返回成功)

如果W+R>N，写的节点和读的节点重叠(可保证至少读取的一个节点数据是最新写入的数据)，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。一般设定是R＋W = N+1，这是保证强一致性的最小设定

如果W+R<=N，则是弱一致性(读取的R个节点，不能保证至少读取的一个节点数据是最新写入的数据)。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。

对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。

实例：HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前，写操作是不会返回成功的。也就是说它的W＝N，而读操作只需要读到一个值即可，也就是说它R＝1。

像Voldemort，Cassandra和Riak这些类Dynamo的系统，通常都允许用户按需要设置N，R，W三个值，即使是设置成W＋R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性，或者是W<N的强一致性时，则总会出现一段“各个节点数据不同步导致系统处理不一致的时间”。为了提供最终一致性的支持，这些系统会提供一些工具来使数据更新被最终同步到所有相关节点。**

4.2 一致性变种

在实际工程实践中，最终一致性存在以下五类主要变种。

• 因果一致性：
  因果一致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最新值，即不能发生丢失更新情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。

• 读己之所写：
  读己之所写是指，进程A更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者而言，其读取到的数据一定不会比自己上次写入的值旧。因此，读己之所写也可以看作是一种特殊的因果一致性。

• 会话一致性：
  会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现“读己之所写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

• 单调读一致性：
  单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

• 单调写一致性：
  单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序地执行。

以上就是最终一致性的五类常见的变种，在时间系统实践中，可以将其中的若干个变种互相结合起来，以构建一个具有最终一致性的分布式系统。事实上，可以将其中的若干个变种相互结合起来，以构建一个具有最终一致性特性的分布式系统。事实上，最终一致性并不是只有那些大型分布式系统才设计的特性，许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中，大多都会采用同步和异步方式来实现主备数据复制技术。在同步方式中，数据的复制国耻鞥通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新往往存在延时，这取决于事务日志在主备数据库之间传输的时间长短，如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上，那么狠显然，从备库中读取的的数据将是旧的，因此就出现了不一致的情况。当然，无论是采用多次重试还是认为数据订正，关系型数据库还是能搞保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性使相反的，它完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在一起使用。
备注：软状态关注数据在不同节点间同步的滞后性(关注同步状态)，最终一致性关注不同节点数据最终一致(关注最终结果)