Zookeeper原理架构

Zookeeper究竟是什么！？

学一个东西，不搞明白他是什么东西，哪还有心情学啊！！ 
首先，Zookeeper是Apache的一个java项目，属于Hadoop系统，扮演管理员的角色。 
而后看到官网那些专有名词，实在理解不了。

在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 

那么咱们来仔细研究一下这个东西吧！

Zookeeper能干吗？！

1. 配置管理

这个好理解。分布式系统都有好多机器，好比我在搭建hadoop的HDFS的时候，须要在一个主机器上（Master节点）配置好HDFS须要的各类配置文件，而后经过scp命令把这些配置文件拷贝到其余节点上，这样各个机器拿到的配置信息是一致的，才能成功运行起来HDFS服务。Zookeeper提供了这样的一种服务：一种集中管理配置的方法，咱们在这个集中的地方修改了配置，全部对这个配置感兴趣的均可以得到变动。这样就省去手动拷贝配置了，还保证了可靠和一致性。 

2. 名字服务

这个能够简单理解为一个电话薄，电话号码很差记，可是人名好记，要打谁的电话，直接查人名就行了。 
分布式环境下，常常须要对应用/服务进行统一命名，便于识别不一样服务； 
相似于域名与ip之间对应关系，域名容易记住； 
经过名称来获取资源或服务的地址，提供者等信息

3. 分布式锁

碰到分布二字貌似就难理解了，其实很简单。单机程序的各个进程须要对互斥资源进行访问时须要加锁，那分布式程序分布在各个主机上的进程对互斥资源进行访问时也须要加锁。不少分布式系统有多个可服务的窗口，可是在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，当即fail over到另外的服务。这在不少分布式系统中都是这么作，这种设计有一个更好听的名字叫Leader Election(leader选举)。举个通俗点的例子，好比银行取钱，有多个窗口，可是呢对你来讲，只能有一个窗口对你服务，若是正在对你服务的窗口的柜员忽然有急事走了，那咋办？找大堂经理（zookeeper）!大堂经理指定另外的一个窗口继续为你服务！

4. 集群管理

在分布式的集群中，常常会因为各类缘由，好比硬件故障，软件故障，网络问题，有些节点会进进出出。有新的节点加入进来，也有老的节点退出集群。这个时候，集群中有些机器（好比Master节点）须要感知到这种变化，而后根据这种变化作出对应的决策。我已经知道HDFS中namenode是经过datanode的心跳机制来实现上述感知的，那么咱们能够先假设Zookeeper其实也是实现了相似心跳机制的功能吧！

Zookeeper的特色

1 最终一致性：为客户端展现同一视图，这是zookeeper最重要的功能。 
2 可靠性：若是消息被到一台服务器接受，那么它将被全部的服务器接受。 
3 实时性：Zookeeper不能保证两个客户端能同时获得刚更新的数据，若是须要最新数据，应该在读数据以前调用sync()接口。 
4 等待无关（wait-free）：慢的或者失效的client不干预快速的client的请求。 
5 原子性：更新只能成功或者失败，没有中间状态。 
6 顺序性：全部Server，同一消息发布顺序一致。

用到Zookeeper的系统

HDFS中的HA方案 
YARN的HA方案 
HBase：必须依赖Zookeeper，保存了Regionserver的心跳信息，和其余的一些关键信息。 
Flume：负载均衡，单点故障

Zookpeeper的基本架构

 
1 每一个Server在内存中存储了一份数据； 
2 Zookeeper启动时，将从实例中选举一个leader（Paxos协议）； 
3 Leader负责处理数据更新等操做（Zab协议）； 
4 一个更新操做成功，当且仅当大多数Server在内存中成功修改 
数据。 

Zookpeeper Server 节点的数目

Zookeeper Server数目通常为奇数 
Leader选举算法采用了Paxos协议；Paxos核心思想：当多数Server写成功，则任务数据写 
成功。也就是说： 
若是有3个Server，则两个写成功便可； 
若是有4或5个Server，则三个写成功便可。 
Server数目通常为奇数（三、五、7） 
若是有3个Server，则最多容许1个Server挂掉； 
若是有4个Server，则一样最多容许1个Server挂掉 
既然如此，为啥要用4个Server？

Observer节点

3.3.0 之后 版本新增角色Observer 
增长缘由： 
Zookeeper需保证高可用和强一致性； 
当集群节点数目逐渐增大为了支持更多的客户端，须要增长更多Server，然而Server增多，投票阶段延迟增大，影响性能。为了权衡伸缩性和高吞吐率，引入Observer： 
Observer不参与投票； 
Observers接受客户端的链接，并将写请求转发给leader节点； 
加入更多Observer节点，提升伸缩性，同时不影响吞吐率。

Zookeeper写流程：

 
客户端首先和一个Server或者Observe（能够认为是一个Server的代理）通讯，发起写请求，而后Server将写请求转发给Leader，Leader再将写请求转发给其余Server，Server在接收到写请求后写入数据并相应Leader，Leader在接收到大多数写成功回应后，认为数据写成功，相应Client。

Zookeeper数据模型

 zookeeper采用层次化的目录结构，命名符合常规文件系统规范； 每一个目录在zookeeper中叫作znode,而且其有一个惟一的路径标识； Znode能够包含数据和子znode（ephemeral类型的节点不能有子znode）； Znode中的数据能够有多个版本，好比某一个znode下存有多个数据版本，那么查询这个路径下的数据需带上版本； 客户端应用能够在znode上设置监视器（Watcher） znode不支持部分读写，而是一次性完整读写 Znode有两种类型，短暂的（ephemeral）和持久的（persistent）； Znode的类型在建立时肯定而且以后不能再修改； ephemeralzn ode的客户端会话结束时，zookeeper会将该ephemeral znode删除，ephemeralzn ode不能够有子节点； persistent znode不依赖于客户端会话，只有当客户端明确要删除该persistent znode时才会被删除； Znode有四种形式的目录节点，PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、PHEMERAL_SEQUENTIAL。