大数据笔记之Zookeeper
概述
Zookeeper是一个开源的分布式的并且为分布式应用提供协调服务的 Apache 项目。
Zookeeper工作机制
功能
管理(存储、读取)用户提交的数据
为用户程序提供数据节点的监听服务
Zookeeper特点
- 一个leader,多个follower
- 集群中只要有半数以上节点存活,Zookeeper集群就能正常服务
- 全局一致性:每个Server保存一份相同的数据副本
- 更新请求顺序进行,来自同一个Client的更新请求按其发送顺序依次执行
- 数据更新原子性,一次数据更新要么成功,要么失败
- 实时性,在一定时间范围内,Client能读到最新数据
数据结构
1、层次化的目录结构,命名符合常规文件系统规范(见下图)
2、每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
3、节点Znode可以包含数据(只能存储很小量的数据,<1M;最好是1k字节以内)和子节点(但是EPHEMERAL类型的节点不能有子节点)
4、客户端应用可以在节点上设置监视器
应用场景
提供的服务包括:
- 统一命名空间
- 统一配置管理
- 统一集群管理
- 服务器节点动态上下线
- 软负载均衡
内部原理
选举机制
半数机制: 集群中半数以上机器存活,集群可用。适合安装奇数台服务器。
Zookeeper 虽然在配置文件中没有指定 Master 和 Slave。但是只有一个节点为Leader,其他为Follower,Leader是通过内部的选举机制临时产生的。
以下以5台服务器描述整个选举过程:它们的 id 从1 - 5 ,同时它们都是最新启动的,也就是没有历史数据。假设这些服务器依序启动。
- 服务器 1 启动,此时只有一台服务器启动,它发出去的保温没有任何响应,所以它的选举状态一直是LOOKING状态。
- 服务器 2 启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器 2 胜出,但未超过半数以上服务器都同意选举它,所以服务器 1,2 保持LOOKING状态。
- 服务器 3 启动,根据以上分析,服务器 3 成为服务器 1、2、3 的老大,此时已有3台服务器选举了它,所以服务器 3 成为Leader。
- 服务器 4 启动,由于前面已经选举了服务器 3 未Leader,所以它只能接收当follower
- 服务器 5 启动,同上
节点类型
持久: client 与 server 断开连接后,创建的节点不删除
短暂: client 与 server 断开连接后,创建的节点自己删除
- 持久目录节点:client 与 zookeeper断开连接后,该结点依旧存在
- 持久顺序编号目录节点:client 与 zookeeper断开连接后,该结点依旧存在,只是 Zookeeper 给该节点名称进行顺序编号
- 临时目录节点:client 与 Zookeeper 断开连接后,该的节点自己删除
- 临时顺序编号目录节点:client 与 Zookeeper 断开连接后,创建的节点自己删除,只是 Zookeeper 给该节点名称进行顺序编号
说明:创建 znode 是设置标识,znode 名称后会附加一个值,顺序是一个单调递增的计数器,有父节点维护。
注意:在分布式系统中,顺序号可以被用于为所有的事件进行全局排序,着用客户端可以通过顺序号推断事件的顺序。
监听器原理
常见的监听
- 监听节点数据的变化:get path [watch]
- 监听子节点增减变化:ls path [watch]
监听原理详解
- 首先要有一个main()线程
- 在main()线程中创建ZkClient,此时会创建两个线程,一个负责网络连接通信,一个负责监听
- 通过 connect 线程将注册的监听事件发送给 Zookeeper
- 在 Zookeeper 的注册监听器列表中将注册的监听事件添加到列表中
- Zookeeper 监听到有数据或路径变化,就会把这个消息发送给 listener 线程
- listener 线程内部调用了 process() 方法
写数据流程
zk的分布式锁的实现
在我们自己的分布式业务系统中,可能会存在某种资源,需要被整个系统的各台服务器共享访问,但是只允许一台服务器同时访问
第一类实现:
- 先创建一个永久节点/ditribute_lock
- 所有客户端在/ditribute_lock节点下创建临时有序节点
- 编号最小的获得锁可以访问资源
- 资源访问结束后断开连接下一个编号成为了编号最小的获得锁
- 用完删除,依次执行
第二类实现
- 可以将zookeeper上的一个znode看做是一把锁,所有客户端都去创建相同名字的临时节点
2。 最终创建成功的客户端就获得了锁,用完删除,然后所有的客户端再重新去创建
双namenode需要解决的问题
哪儿台机器是active namenode,哪儿台是standby namenode
standby namenode元数据的获取
- 元数据的管理方式需要改变
把edits存放在一个共享存储中(qjournal和NFS两种实现) - 主备切换(状态管理)
1)需要监听每一个namendoe的健康状态
2)一旦active namenode健康发生变化,立刻重新选举出新的active namenode
3)然后切换状态
预防脑裂,一旦active namenode健康状态出现问题,切换前要将其杀死(可以使用免密码登录,然后kill掉,预防kill失败,写一个脚本程序去杀死进程)