NoSQL 数据库与分布式一致 Zookeeper

1. NoSQL数据库

1.1 CAP理论

CAP是一个已经经过证实的理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

一致性

我们知道ACID中事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行前后，数据库都必须处于一致性状态。也就是说，事务的执行结果必须是使数据库从一个一致性状态转变到另一个一致性状态。和ACID中的一致性不同，分布式环境中的一致性是指数据在多个副本之间是否能够保持一致的特性。

分布式系统中，数据一般会存在不同节点的副本中，如果对第一个节点的数据成功进行了更新操作，而第二个节点上的数据却没有得到相应更新，这时候读取第二个节点的数据依然是更新前的数据，即脏数据，这就是分布式系统数据不一致的情况。

在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都能读取到最新的值，那么这样的系统就被认为具有强一致性（或严格的一致性）。



可用性

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果，如果超过了这个时间范围，那么系统就被认为是不可用的。

“有限的时间内”是在系统的运行指标，不同系统会有差别。例如搜索引擎通常在0.5秒内需要给出用户检索结果。

“返回结果”是可用性的另一个重要指标，它要求系统完成对用户请求的处理后，返回一个正常的响应结果，要明确的反映出对请求处理的成功或失败。如果返回的结果是系统错误，比如"OutOfMemory"等报错信息，则认为此时系统是不可用的。



分区容错性

一个分布式系统中，节点组成的网络本来应该是连通的。然而可能因为某些故障，使得有些节点之间不连通了，整个网络就分成了几块区域，而数据就散布在了这些不连通的区域中，这就叫分区。

当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。

提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项仍然能在其他区中读取，容忍性就提高了。然而，把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。

总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。



面临的问题

对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C。



1.2 场见的NoSQL数据库

关系数据库经过几十年的发展后已经非常成熟，强大的 SQL 功能和 ACID 的属性，使得关系数据库广泛应用于各式各样的系统中，但这并不意味着关系数据库是完美的，关系数据库存在如存储是行记录，大数据场景I/O较高，全文检索能力弱等缺点。针对关系型数据库存在的问题，分别诞生了不同的 NoSQL 解决方案，这些方案与关系数据库相比，在某些应用场景下表现更好。但世上没有免费的午餐，NoSQL 方案带来的优势，本质上是牺牲 ACID 中的某个或者某几个特性，因此我们不能盲目地迷信 NoSQL 是银弹，而应该将 NoSQL 作为 SQL 的一个有力补充。



常见的 NoSQL 方案分为 4 类。

• K-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表。

• 文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表。

• 列式数据库：解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。

• 全文搜索引擎：解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表。

1.3 ACID

ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库，必须要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。



1.4 BASE

BASE理论是对CAP理论的延伸，思想是即使无法做到强一致性（CAP的一致性就是强一致性），但可以采用适当的采取弱一致性，即最终一致性。



BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。



基本可用

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用。

响应时间上的损失：正常情况下搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。

功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。



软状态

软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。



最终一致性

最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。



2. 分布式一致Zookeeper

Zookeeper 是一个高性能、高可靠的分布式协调系统，是 Google Chubby 的一个开源实现，目前在分布式系统、大数据领域中使用非常广泛。本文将介绍 Zookeeper 集群架构、数据模型、监听机制，以及Zookeeper典型的应用场景等。

2.1 Zookeeper 集群角色



  首先介绍下 Zookeeper 集群，一个 Zookeeper 集群通常由一组机器组成，一般3~5台集群就可以组成一个 Zookeeper 集群。集群拓扑图基本如下：





  Zookeeper 集群中每一个节点都会在内存中维护当前的节点状态，并且彼此之间保持着通信。这里说明一点，只要集群中存在过半的节点正常工作，整个集群就能够对外提供服务。



  如上图，在 Zookeeper 集群中，有 Leader、Follower 和 Observer 三种类型的角色。



Leader



Leader 节点整个 Zookeeper 集群工作机制中的核心，主要工作是处理客户端的读写请求，及集群内部各服务的调度。注意只有 leader 能够处理写请求。



Follower



处理客户端的读请求，将写请求转发给 leader。参与 leader 选举投票等。



Observer



这是自 Zookeeper 3.3.0 版本引入的一个新的角色，主要是为了解决大规模 Server 场景下因 leader 选举投票成本增加导致写性能下降的问题。Observer 的工作原理和 follower 基本一致。处理客户端的读请求，将写请求转发给leader。和 follower 唯一的区别在于，Observer不参与任何形式的选举，包括 leader 选举。一般而言，中小型规模的 Zookeeper 集群中只包含 leader 和 follower 两个角色，这容易让我们忽略 observer 角色的存在。



至此，相信你对 Zookeeper 的集群架构与相关角色有了一定认识。



2.2. Zookeeper 数据模型



  Zookeeper 的数据模型是一棵类似 Unix 文件系统的 ZNode Tree 即 ZNode 树，但是没有引入传统文件系统的目录或者文件等概念，而是使用了称为 “数据节点” 的概念，术语叫做 ZNode。ZNode 是 Zookeeper 存储数据的最小单元，每个 ZNode 可以保存数据，也可以挂载子节点，其中根节点是 /。示意图如下：

使用过 Zookeeper 的同学应该都知道，Zookeeper 主要提供了两个核心功能：



管理（存储、读取）客户端提交的数据；

为客户端提供数据节点的监听服务；

2.3 Zookeeper 应用场景

Zookeeper 在分布式系统、大数据领域里应用广泛，这里总结了 8 个典型的应用场景：

数据发布/订阅

负载均衡

命名服务

分布式协调/通知

集群管理

Master 选举

分布式锁

分布式队列