zookeeper--介绍

 

Zookeeper概述

Zookeeper是Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目，可以实现集群中的分布式协调服务。所谓的分布式协调服务，就是在集群的节点中进行可靠的消息传递，来协调集群的工作。

Zookeeper之所以能够实现分布式协调服务，靠的就是它能够保证分布式数据一致性。所谓的分布式数据一致性，指的就是可以在集群中保证数据传递的一致性。

 

Zookeeper可以干什么?

数据发布订阅、负载均衡、命名服务、分布式协调/通知、配置管理、集群管理、分布式锁、分布式队列等功能

(Zookeeper设计本来就是充着做协调服务的，然而，协调服务是各异的，基本上没有统一算法框架或者服务架构可言，实际上，Zookeeper只给你提供了一堆操作，大部分都是基于znode，还有重要的watch机制。怎么利用它来做协调服务都是要开发者自己实现)

 

Zookeeper的特点

顺序一致性

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

原子性

所有事物请求的处理结果在整个集群中所有机器上的应用情况是一致的，即，要么整个集群中所有机器都成功应用了某一事务，要么都没有应用，一定不会出现集群中部分机器应用了改事务，另外一部分没有应用的情况。

单一视图

无论客户端连接的是哪个zookeeper服务器，其看到的服务端数据模型都是一致的。

可靠性

一旦服务端成功的应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直保留下来，除非有另一个事务又对其进行了改变。

实时性

zookeeper并不是一种强一致性，只能保证顺序一致性和最终一致性，只能称为达到了伪实时性。

 

zookeeper的数据模型

zookeeper中可以保存数据，正是利用zookeeper可以保存数据这一特点，我们的集群通过在zookeeper里存取数据来进行消息的传递。

zookeeper中保存数据的结构非常类似于文件系统。都是由节点组成的树形结构。不同的是文件系统是由文件夹和文件来组成的树，而zookeeper中是由znode来组成的树。

每一个znode里都可以存放一段数据，znode下还可以挂载零个或多个子znode节点，从而组成一个树形结构。

(zookeeper不能作为大数据存储系统，提供的每个“目录”称为znode，默认提供了1MB的存储空间，用来辅助协调工作，只适合保存元数据metadata)

zookeeper功能强大，成熟，稳定，几个缺点如下：

1.无http访问接口，只能通过api访问

2.监控管理工具不完善

3.底层数据采用类似linux文件结构存储，大数据量时效率比较低

4.api使用不方便，需要coding 重复注册watcher，session失效重连，异常处理等

5.zookeeper只保证数据最终一致性，如果想保证取得的数据是最新的，需要收工调用sync方法

6.zookeeper功能强大，导致实现和使用起来有些复杂，比如共享配置和服务发现可以使用简单点的etcd

zookeeper使用的quorum的2pc机制来做数据一致性，这样的一种强一致性的代价就是吞吐率，写入速度极慢。

使用zookeeper比较好的方式是：小集群（zookeeper集群）+大集群（比如 hadoop），通过zookeeper来保证元信息的一致性，大集群来存储真正的数据

 

zookeeper基本原理及适用场景 http://blog.chinaunix.net/uid-26748613-id-4536290.html

zookeeper集群的搭建http://www.cnblogs.com/zpb2016/p/5791636.html

zookeeper的shell下操作http://www.cnblogs.com/zpb2016/p/5791637.html

zookeeper中client命令实践http://www.cnblogs.com/felixzh/p/5873306.html

zookeeper letter 描述与实践http://www.cnblogs.com/felixzh/p/5873255.html

zookeeper监控管理http://www.cnblogs.com/felixzh/p/5868626.html

zookeeper的java api操作http://www.cnblogs.com/zpb2016/p/5791641.html

 

 

Zookeeper+Spring跨机房容灾系统以及灰度发布在线付费视频http://www.xuetuwuyou.com/course/20/reviews/

 

 

Zookeeper 本身单点失效问题？

Zookeeper本身也是集群啊，推荐配置不少于3个服务器。ZK集群的机制是只要超过半数的节点OK，集群就能正常提供服务。只有ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。

 

Zookeeper在哪些系统中使用？

storm中用zookeeper来协调同步集群中机器的状态（并不传递消息）。基本不会有负载，对机器性能没什么要求。jstorm也是用zk来做一致性服务。

dubbo中采用zookeeper来作注册中心，在阿里内部采用的是基于数据库的注册中心，我们自己用dubbo的时候采用了zookeeper，配置起来非常方便。当然如果采用redis或者自己写个简单的基于内存的注册中心也是可以的。从稳定性来讲，个人觉得zookeeper是比较好的选择，毕竟zookeeper集群中的机器只要不是半数以上宕掉，服务就是可用的。dubbo服务的消费者和提供者都需要用到zookeeper，然而消费者和提供者之间的长连接建立后，zookeeper参与程度就比较弱了(仅需要接受一些心跳包)，除非此时有新的提供者消费者加入或者离开(需要更新节点数据)。因此负载也是非常低的，基本不用考虑性能问题。zookeeper还同时起到了监控各个服务的作用。

(dubbo是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题)

Hadoop也是需要用到zookeeper的，用来管理集群中的NameNode。

Kafka集群依赖于ZooKeeper实现生产者在消费端的负载均衡，动态的集群扩展等等

 

zookeeper在dubbo到底起了什么作用，dubno如何解决了阿里的高并发问题？

zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。

至于支持高并发，简单来说就是横向扩展，在不更改代码的情况通过添加机器来提高运算能力。通过添加新的机器向zookeeper注册服务，服务的提供者多了能服务的客户就多了。

简单的分布式系统，可以通过静态的配置文件，来记录这些数据：进程之间的连接对应关系，他们的IP地址和端口，等等。然而一个自动化程度高的分布式系统，必然要求这些状态数据都是动态保存的。这样才能让程序自己去做容灾和负载均衡的工作。

然而，如果我们只是用一个进程来充当这个工作。那么这个进程就成为了这个集群的“单点”——意思就是，如果这个进程故障了，那么整个集群可能都无法运行的。所以存放集群状态的目录服务，也需要是分布式的。幸好我们有ZooKeeper这个优秀的开源软件，它正是一个分布式的目录服务区。

ZooKeeper可以简单启动奇数个进程，来形成一个小的目录服务集群。这个集群会提供给所有其他进程，进行读写其巨大的“配置树”的能力。这些数据不仅仅会存放在一个ZooKeeper进程中，而是会根据一套非常安全的算法，让多个进程来承载。这让ZooKeeper成为一个优秀的分布式数据保存系统。

由于ZooKeeper的数据存储结构，是一个类似文件目录的树状系统，所以我们常常会利用它的功能，把每个进程都绑定到其中一个“分枝”上，然后通过检查这些“分支”，来进行服务器请求的转发，就能简单的解决请求路由（由谁去做）的问题。另外还可以在这些“分支”上标记进程的负载的状态，这样负载均衡也很容易做了。