Hadoop离线ZooKeeper基础

ZooKeeper基础

分布式服务协调框架,主要用于协调辅助其他框架正常运行,主要为了解决应用系统中一致性问题,不干活,协助别人干活

主从架构:主节点是分配任务的节点,一般是一个或者两个,也可能是多个,从节点执行任务的节点,主要是干主节点分配的活

主备架构:解决主节点单一故障问题

主节点:作用是维护数据的一致性,负责处理用户的读写数据请求

从节点:负责处理用户的读数据请求,并且维护数据的一致性

⚠️ 对于非事务请求,可以独立处理,所有带有事务性操作的请求,最终都要转到leader节点

 

ZooKeeper特性

全局数据一致性:每个server保存一份相同的副本,client无论连接到哪个server,展示的数据都是一致的,这是最重要的

可靠性:如果消息被其中一台服务器接受,那么将被所有服务器接受

顺序性:如果在一台服务器上,消息a比消息b更先发布,那么,在所有服务器上a都比b先发布

数据更新原子性:一次数据要么更新成功,要么更新失败,没有中间状态

实时性:保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器的失败消息

 

ZooKeeper内部原理

选举机制

1)半数机制:集群中半数以上机器存活,集群可用。所以Zookeeper适合安装奇数台服务器。

2)Zookeeper虽然在配置文件中并没有指定MasterSlave但是,Zookeeper工作时,是有一个节点为Leader,其他则为Follower,Leader是通过内部的选举机制临时产生的。

3)以一个简单的例子来说明整个选举的过程。

假设有五台服务器组成的Zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的

  1. 服务器1启动,此时只有它一台服务器启动了,它发出去的报文没有任何响应,所以它的选举状态一直是LOOKING状态。
  2. 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1、2还是继续保持LOOKING状态。
  3. 服务器3启动,根据前面的理论分析,服务器3成为服务器1、2、3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的Leader。
  4. 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1、2、3、4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了。
  5. 服务器5启动,同4一样当小弟。

节点类型

持久化目录节点:客户端与ZooKeeper断开连接后,该节点依旧存在

临时目录节点:客户端与ZooKeeper断开连接后,该节点被删除

持久化顺序编号目录节点:客户端与ZooKeeper断开连接后,该节点依旧存在,只是ZooKeeper给该节点名称进行顺序编号

临时顺序编号目录节点:客户端与ZooKeeper断开连接后,该节点被删除,只是ZooKeeper给该节点名称进行顺序编号

监听器原理

  1. 首先创建一个main()线程
  2. 在main线程中创建ZooKeeper客户端,这时候就会创建两个线程,一个负责网络连接通信,一个负责监听
  3. 通过通信线程将注册的监听事件发给ZooKeeper
  4. 在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中
  5. ZooKeeper监听到有数据或者路径变化,会将这个消息发送给listener线程
  6. listener线程内部调用了process()方法
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值