Zookeeper简单介绍

Zookeeper简单介绍

2017-12-25

目录

1 ZooKeeper是什么
1.1 分布式系统面临的问题
1.2 ZooKeeper概述
1.3 分布式锁服务，是如何实现的呢
2 Zookeeper典型应用场景
2.1 命名服务(Naming Service)
2.2 数据发布与订阅（配置中心）
2.3 集群管理与Master选举
2.4 分布式锁
2.5 分布式通知/协调
2.6 分布式队列
2.7 负载均衡
3 Zookeeper实现原理
3.1 ZooKeeper的4个目标
3.2 Paxos算法
3.3 ZooKeeper算法
4 ZooKeeper的API
参考

1 ZooKeeper是什么

返回

1.1 分布式系统面临的问题

在分布式系统中，所有在同一台机器上的假设都不存在：因为网络是不可靠的。

在分布式环境中，由于网络的原因：

你对一个服务的调用失败了并不表示一定是失败的，可能是执行成功了，但是响应返回的时候失败了。

还有，A和B都去调用C服务，在时间上 A还先调用一些，B后调用，那么最后的结果是不是一定A的请求就先于B到达呢？

1.2 ZooKeeper概述

Google的三篇论文一直是分布式领域传阅的经典。根据MapReduce，于是我们有了Hadoop；根据GFS，于是我们有了HDFS；根据BigTable，于是我们有了HBase。而在这三篇论文里都提及Google的一个lock service---Chubby，于是我们有了Zookeeper。

伴随着Zookeeper有两篇论文：

一篇是Zab，就是介绍Zookeeper背后使用的一致性协议的(Zookeeper atomic broadcast protocol)，

一篇就是介绍Zookeeper本身的。

Zookeeper：是一个分布式协调服务(a service for coordinating processes of distributed applications)。它提供了一项基本服务：分布式锁服务。

1.3 分布式锁服务，是如何实现的呢

它设计一种新的数据结构-Znode，并在在该数据结构的基础上定义了一些原语，也就是一些关于该数据结构的一些操作。我们暂且把它称作文件系统

由于ZooKeeper是工作在一个分布式的环境下，我们的服务是通过消息以网络的形式发送给分布式应用程序，所以还需要一个通知机制——Watcher机制。

1 logicalclock++，表示是新一轮leader选举，它是一个内存值，服务器重启就会导致该值归0，所以如果服务器活得越久，这个值随着应该越大，每一轮选举会保持所有机器该值始终是其中相同的最大值。
2 推举自己作为leader，并将自己服务器上存储的最大zxid，自己的服务器id，自己的状态(looking)notify所有的服务器，告知大家我想当leader.
3 等待其他服务器的反馈消息，如果有消息回来，分为以下几个情况：
3.1 自己还在looking，该消息标记的服务器也在looking
消息的epoch<自己的logicalclock，表示这条消息是前面一轮的消息，于是回发一条消息告诉对方当前的机器的logicalclock和推举的leader和zxid
消息epoch>自己的logicalclock，表示对方已经开始新一轮选举了，更新logicalclock为epoch，清空接收到的所有服务器状态recvset.对比消息的zxid和本地的lastzxid，选取最大的作为leader，如果相同，则选取serverid最大的作为leader.然后sendNotifications()通知所有服务器我的选择。
消息epoch=自己的logicalclock，表示是同一轮选举，对比消息的zxid和本地的lastzxid，选取最大的作为leader，如果相同，则选取serverid最大的作为leader.如果返回的消息是最后选择，则sendNotifications()通知所有服务器我的选择，否则不理睬这条消息，不发送任何回应。
3.2 自己还在looking，该消息标记的服务器已经没有looking了
消息的epoch=自己的logicalclock，如果消息状态是leading，那么就认为他是leading，更改自己的状态返回。如果消息认为自己是leader，那么需要有1/2以上服务器认为自己是leader，就更改状态并返回。
消息的epoch<>自己的logicalclock，那么投票将加入到outofelection中，如果有1/2服务器以上的投票选择这条消息推荐的leader，那么更改自身的状态并返回。
3.3 自己没有looking，该消息标记的服务器还在looking
获得当前的leader信息，直接通知对方已经选择的leader.
3.4 自己没有looking，该消息标记的服务器没有looking
不做任何处理。

3.1 这种状态下：
如果收集到了所有服务器的投票，
如果此时收集的投票大于1/2服务器数，那么再等待一个时段，如果没有其他响应到来或者到来的响应没有新的选票产生。
此时看下此时选举出来的proposedLeader是否是自己，是则更改自己的状态为leading，否则更改为following，然后跳出选举阶段.如果不满足上面的两条条件，则继续等待消息。

View Code

4 ZooKeeper的API

返回

Zookeeper的client是通过Zookeeper类提供的。Zookeeper的client api给我们提供以下这些API：

4.1 create

在给定的path上创建节点，这个path就像文件系统的路径，比如/myapp/data/1，

在创建节点的时候还可以指定节点的类型：

是永久节点，

永久顺序节点，

临时节点，

临时顺序节点。

这个节点类型是非常强大的：

永久节点：一经创建就永久保留了，就像我们在文件系统上创建一个普通文件，这个文件的生命周期跟创建它的应用没有任何关系。

临时节点：，当创建这个临时节点的应用与zookeeper之间的会话过期之后就会被zookeeper自动删除了。这个特性是实现很多功能的关键。比如我们做集群感知，我们的应用启动的时候将自己的ip地址作为临时节点创建在某个节点下面。当我们的应用因为某些原因，比如网络断掉或者宕机，它与zookeeper的会话就会过期了，过期后这个临时节点就删除了。这样我们就可以通过这个特性来感知到我们的服务的集群有哪些机器是活者的。

顺序节点：一般，如果我们在指定的path上创建节点，如果这个节点已经被创建了，则会抛出一个NodeExistsException的异常。如果我们在指定的路径上创建顺序节点，则Zookeeper会自动的在我们给定的path上加上一个顺序编号。这个特性就是实现分布式锁的关键。假设我们有几个节点共享一个资源，我们这几个节点都想争用这个资源，那我们就都向某个路径创建临时顺序节点。然后顺序最小的那个就获得锁，然后如果某个节点释放了锁，那顺序第二小的那个就获得锁，以此类推，这样一个分布式的公平锁就实现了。

除此之外，每个节点上还可以保存一些数据。

4.2 delete

删除给定节点。删除节点的时候还可以给定一个version，只有路径和version都匹配的时候节点才会被删除。有了这个version在分布式环境种我们就可以用乐观锁的方式来确保一致性。比如我们先读取一下节点，获得了节点的version，然后删除，如果删除成功了则说明在这之间没有人操作过这个节点，否则就是并发冲突了。

4.3 exists

这个节点会返回一个Stat对象，如果给定的path不存在的话则返回null。这个方法有一个关键参数，可以提供一个Watcher对象。Wathcer是Zookeeper强大功能的源泉。Watcher就是一个事件处理器，一个回调。比如这个exists方法，调用后，如果别人对这个path上的节点进行操作，比如创建，删除或设置数据，这个Wather都会接收到对应的通知。

4.4 setData/getData

设置或获取节点的数据，getData也可以设置Watcher

4.5 getChildren

获取子节点，可以设置Watcher

4.6 sync

zookeeper是一个集群，创建节点的时候只要半数以上的节点确认就认为是创建成功了，但是如果读取的时候正好读取到一个落后的节点上，那就有可能读取到旧的数据，这个时候可以执行一个sync操作，这个操作可以确保读取到最新的数据。

参考

[1] 随笔分类 - Zookeeper

[2] ZooKeeper学习笔记

[3] ZooKeeper典型应用场景一览

[4] zookeeper体系架构