Zookeeper-1-介绍

1、概述

Zookeeper是一个为分布式应用提供协调服务的项目

从设计模式的角度来说，它是一个基于观察者模式设计的分布式服务管理框架。它负责存储和管理广受关注的数据（被观察者），同时接受观察者的注册，当被观察的数据发生改变时，Zookeeper就负责通知那些在Zookeeper上注册的观察者

这类似于集群中的 Leader / Follower 管理模式

简单说，Zookeeper就是文件系统和通知机制

Zookeeper集群由1个主（Leader）和多个从（Follower）组成

主节点负责投票的发起和决议，以及更新系统状态

从节点负责接收客户端的请求，并返回给客户端响应。以及在投票主节点中参与投票
Zookeeper集群当中只要有半数以上的节点存活，该集群就能正常提供服务
每个节点都保存着相同的数据副本，客户端无论访问到哪个节点，得到的数据都是一样的
来自同一个客户端的多个更新请求，按照请求的发送顺序依次执行
一次更新操作要么成功，要么失败，保证了数据更新的事务特性

扫描二维码关注公众号，回复： 12279600 查看本文章
在一定时间范围内，客户端总是能够读取到最新的数据（ZK上存储的数据量不大，并且通知每个节点更新的速度快）

Zookeeper的数据模型类似于Unix文件系统，也是树形结构。它上面的每一个节点被称之为ZNode

每一个ZNode默认存储1MB大小的数据，并且可以通过唯一路径找到它

ZNode一共分为两大类：持久性节点和临时性节点

持久性节点是当客户端和服务端断开连接后，该节点不会被删除。而临时性节点，当客户端和服务端断开连接后，该节点会自己删除

ZNode有4种形式的目录节点：

由于Zookeeper的半数机制，即集群中半数以上的机器存活，则该集群可正常提供服务。所以Zookeeper集群节点的数量适合奇数

Zookeeper虽然没有在配置文件中显示地指定Leader和Follower，但是其内部的选举机制会临时选出一个主节点，然后剩余的节点都是从节点

选举机制是当某个节点所获得的”选票数“超过集群节点的半数时，该节点就是主节点

顺序依次启动各个节点，这时选票由节点机器的编号所决定。例如：现在有3个节点，依次按照机器编号从小到大启动，当启动到第二个节点时，由于它的编号要大于前一个节点，所以它现在有2票，同时票数超过了集群节点的半数（1.5），所以它就成为了主节点

集中式配置中心，适合多设备共享配置信息，并且配置信息会动态发生改变

当应用启动时，客户端主动到ZK集群上获取配置信息，并注册Watcher监听（拉）

当某个配置文件发生改变时，ZK会主动推送变更信息给客户端，出发Watcher监听的回调函数（推）

客户端根据业务逻辑，主动获取最新的配置信息，并更新自身状态（拉）

当服务器节点启动后，在ZK集群上注册相关域名信息。当请求到达服务器时，ZK集群解析请求的域名，并根据最新的服务器节点状态，选择合适的机器处理请求，并返回响应

ZK集群定时监控扫描每个服务器节点的状态，并动态更新节点信息

同时提供控制台，方便管理ZK集群

通过将服务器集群注册到ZK上，可以方便地知道当前有多少服务器在提供服务，每台服务器的工作状态。同时还可以方便地对某个节点进行下线操作，以及添加新节点的操作等