文档介绍：分布式服务框ZooKeeper分享
探讨zookeeper在分布式环境中的应用
目录
初识ZooKeeper
► ZooKeeper由来
ZooKeeper深入剖析
►总体架构
►数据模型
►实现原理
ZooKeeper应用场景及生产中的实现
►数据发布/订阅
►负载均衡
►命名服务
►分布式锁
初始ZooKeeper
ZooKeeper介绍
ZooKeeper是什么,Zookeeper 是雅虎模仿强大的Google chubby 实现的一套分布式锁管理系统。同时,Zookeeper 分布式服务框架是Apache Hadoop的一个子项目,它将复杂且容易出错的分布式一致性服务封装起来,将简单易用的接口和性能高效、功能稳定的系统提供给用户。
Zookeeper总体结构
Leader 接受所有Follower的提案请求并统一协调发起提案的投票,负责与所有的Follower进行内部的数据交换(同步)
Follower 直接为客户端服务并参与提案的投票,同时与Leader进行数据交换(同步)
Observer 直接为客户端服务但并不参与提案的投票,同时也与Leader进行数据交换(同步)(默认关闭)
集群要点说明
集群中主要有两个角色leader和flower
建议部署的节点个数为奇数个
每个客户端可以连接集群中的任何一个节点,同时从其上面read信息,但是针对write操作,flower节点会转发给leader,由leader负责原子广播,从而保证集群中各个节点的数据一致性
只有当多余一半的节点同步完成整个write操作才算完成。
zookeeper数据模型
数据模型说明
每个子目录项都被称作为 znode,这个 znode 是被它所在的路径唯一标识
znode 可以有子节点目录,并且每个 znode 可以存储数据
znode 可以是临时节点,一旦创建这个 znode 的客户端与服务器失去联系,这个 znode 也将自动删除
znode 可以被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化可以通知设置监控的客户端
leader选举实现
每个server会发出一张投票
接收各个服务器的投票
处理投票
统计投票
改变服务器状态
ZAB协议实现
broadcast模式
recovery模式
订阅与发布
将数据发布到ZK节点上,供订阅者动态获取数据,实现配置信息的集中式管理和动态更新。例如全局的配置信息,地址列表等就非常适合使用。集中式的配置管理在应用集群中是非常常见的,一般商业公司内部都会实现一套集中的配置管理中心,应对不同的应用集群对于共享各自配置的需求,并且在配置变更时能够通知到集群中的每一个机器。