Zookeeper基本概念

引言

首先在学习Zookeeper之前，我们要知道Zookeeper是什么东西，其次我们要知道Zookeeper能干什么。我通过自己的总结和自己的理解和大家一起分享一下Zookeeper的基本的概念的Zookeeper简单集群的搭建。

什么是Zookeeper

Zookeeper是一个高可用的分布式管理和协调框架，基于ZAB（原子消息广播协议，有兴趣的可以了解一下）实现，而这个原子消息广播机制又是基于Paxos算法实现，对于这个算法，在后面的博客中会提到。对于ZAB来说能够很好的保证分布式环境中数据的一致性，同样正是由于这些特性，才使得Zookeeper称为在分布式系统中解决数据一致性的最好的工具。
Zookeeper是一个高效的分布式协调服务框架，它暴露了一些公共的服务，例如命名、配置、管理、同步控制、群组服务等等。课可以使用Zookeeper来实现一些功能，例如共识、集群管理、leader选举等等的操作。在实际开发中也是比较高效的集群管理框架。
一般情况下，我们大家Zookeeper集群至少需要三个Linux的节点。而且在后期扩展的时候，更多的使用的是单数个节点，一个最主要的原因就是有利于Paxos算法的计算。当然实在是由偶数个节点也不是不可以。

Zookeeper特性

顺序一致性

从一个客户端发起的事务请求，最终将严格按照其发起的顺序被应用到Zookeeper中去。

原子性

所有事务请求的处理结果在整个集群中的所有机器上的应用情况都是一致的，也就是说，要在整个集群中成功的应用了某个事务，那么这个集群中的所有的节点都会应用，不会出现一部分节点有这个事务，一部分节点上没有这个事务。

例如有三个节点，两个是从节点，一个是主节点，如果主节点挂掉之后从节点就会上升为一个主节点，整个集群全部正常工作，这个就是集群之间的原子消息广播，如果修改了Zookeeper上的其中一个节点上的内容，其他节点上的内容也是一样的。

单一视图

对于单一视图来说，无论客户端连接的是哪个Zookeeper服务器，其他看到的服务端数据模型都是一致的，不会出现多种视图。

可靠性

一旦服务器上的某一个节点成功应用了一个事务，并对客户端完成正确的响应，那么由该事务引起的服务端状态将会被保留下来，除非出现另一个事务将其修改。

实时性

通常我们所说的实时性就是指一个事务一旦被应用成功，那么客户端会立即从服务器上获取变化后的新的数据，但是Zookeeper仅仅能够保证一段时间内，客户端最终一定能从服务器端读取最新的数据状态，想要数据持久化还是要加入其它的数据持久化的技术。

Zookeeper设计目标

1 简单的数据结构，Zookeeper就是以比较简单的树形结构来进行相互协调（也被称为是树形命名空间）
2 可以构建集群，一般情况下Zookeeper集群通常是一组机器组成，一般情况下最少是三台，3-5台机器就课可以组成一个Zookeeper集群，只要集群中超过半数以上的机器都能够正常使用，那么正规集群就能够正常对外部提供服务。
3 顺序访问。对于一个来自客户端的请求，Zookeeper都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序，应用程序可以使用Zookeeper这个特性来实现更高层次的同步操作。
4 高性能，由于Zookeeper将会将全量的数据存储在内存中，并直接服务于所有的非事务请求。因此尤其在读操作方面性能是非常突出的，在Jmater压力测试下（100%读请求场景），结果大约在12-13w的QPS

Zookeeper的结构

Zookeeper维护的是一个具有层次关系的数据结构，也就是我们常说的树形结构，但是也不完全是，它类似于Linux文件系统。

Zookeeper的数据模型

Znode 可以简单的理解为每个层级的节点

每个字目录项如NameService都被称为是一个Znode，这个Znode是被它所在的路径唯一标识的。
Znode可以有子目录和子节点，并且每个Znode可以存储数据，注意EPHEMERAL类型的目录是不支持子目录的概念。
Znode是由版本的（这个在后期的博客中会有），每个Znode中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据。
Znode可以是临时节点，一旦创建这个Znode的客户端与服务器失去联系，这个Znode节点就会被自动删除，Zookeeper客户端与服务器采用长连接方式，每个客户端和服务器通过心跳来保持连接。这个连接状态被称为Session，如果Znode是临时节点，这个Session就会失效，Znode就会被删除。
Znode 的目录名称是可以自动编号的，这个在之前的时候提到过自动编号来判断事务的先后顺序。例如APP1已经存在，如果再次创建就会被自动命名为APP2。
Znode 可以被监控，这个监控也可以包括这个目录中存储的数据的修改、子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是Zookeeper的核心的特性，Zookeeper的很多的功能都是通过这个特性来实现的，这个就是我们之前提到过的实时性。

Zookeeper的组成

Zookeeper 服务根据其在集群中的特性分为三种Leader、Follower、Observer，其中Follower和Observer统称为Learner（学习者）

Leader：负责客户端的writer类型的请求
Follower：负责客户端reader类型的请求，参与Leader的选举等
Observer：是一个特殊的Follower，它可以接收客户端的reader请求，但是不参加选举（扩容系统支持能力，提高读取数据的速度，因为它不接受任何同步的写入请求，只负责Leader同步数据）

Zookeeper应用场景

经典应用场景

Zookeeper从设计模式的角度上来看，是一个基于观察者模式设计的分布式服务管理架构，它负责存储和管理大家共同关注的数据，然后接受观察者的注册，一旦这些数据状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者作出正确的反应，从而实现了集群中的而类似与Master/Slave管理模式

配置管理

配置管理在分布式应用中是比较常见的，例如在我现在做的分布式ESB系统中，对于各个应用的配置都会有自己的配置信息。如机器的配置列表、运行的开关配置、数据配置信息等等。这些都是全局的配置，而这些全局的配置有三个特点

数据量小
数据内容在运行时根据不同的环境发生变化
数据中各个节点的信息的共享的，一致性发生变化

集群管理

Zookeeper可以帮助维护当前系统集群中的机器的状态，还为这些机器选择了一个总管Leader，让这个总管来管理整个集群，主要就是支持一些简单的容错机制

知道当前集群中有多少个工作机器
对集群中每天集群中的运行时状态进行数据收集
对集群中的每台机器进行上下线操作

发布订阅

Zookeeper是一个比较典型的发布/订阅模式的分布式数据管理和协调框架，提到发布/订阅的概念现在有好多的工具都可以实现这种类似于发布/订阅的模式，例如Redis、各种MQ、Kafka等等。在Zookeeper中一个比较常用的场景就是数据库的切换，Zookeeper能够帮助把数据库的切换通知发送到各个节点的客户端上，每个客户端收到变更之后，就可以重新获取新的数据

分布式日志收集

可以做一个分布式日志收集系统收集所有日志信息，进行统一管理，还有分布式锁，队列管理等等。

Zookeeper最主要的特性就是在分布式场景下高可用，但是原生的API实现分布式功能是非常困难的，对于一个团队来说是比较浪费时间，就算是实现了也未必能够稳定运行，这里就推荐几个第三方的客户端。例如Curator框架，这个作为Apache的顶级项目，是比较推荐使用的。

Zookeeper的使用场景是非常广泛的，例如Hadoop、Storm、消息中间件、RPC服务框架、数据库增量订阅与消费者组件（MySQL Binlong）、分布式数据库同步系统、淘宝的Otter等等。都是Zookeeper的使用。另外，Zookeeper使用ZAB（原子消息广播）作为底层实现。使用了CAS原子消息算法，Paxos复制算法，在分布式的应用中有比较好的应用。