Zookeeper内部原理概述
一、Zookeeper简单介绍ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。二、Zookeeper的工作机制Zookeeper从设计模式的角度来理解:是一个基于观察者模式的分布式服务管理框架...
一、Zookeeper简单介绍
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。
二、Zookeeper的工作机制
Zookeeper从设计模式的角度来理解:是一个基于观察者模式的分布式服务管理框架,它负责存储和管理重要的数据,然后接受观察者的注册,一旦这些被观察的数据状态发生变化,Zookeeper就负责通知已经在Zookeeper上注册的那些观察者让他们做出相应的反应。
工作机制原理如下图:
简单概括:Zookeeper = 文件系统 + 通知机制。
三、Zookeeper特点
【1】Zookeeper是存在一个领导者(Leader)和多个跟随者(Follower) 组成的集群。
【2】集群中若存在半数以上的(服务器存活数量必须大于一半,小于等于一半都不行)节点存活,就能正常工作。
【3】数据一致:每个Server保存一份相同的数据副本,Client无论连接到哪一个Server获取的数据都是一样的。
【4】更新请求按发送的顺序依次执行。
【5】数据更新原子性原则,要么一次更新成功,要么失败。
【6】实时性,Client能够读取到最新的数据。
四、Zookeeper的选举机制
【1】半数机制:集群中半数以上的机器存活,集群就可以正常工作,所以Zookeeper适合安装奇数台服务器。
【2】ZooKeeper虽然在配置中没有指定Master和Slave,但是Zookeeper在工作时会有一个节点成为Leader,其他的则为Follower,Leader是通过内部的选举机制临时产生的。
下面场景模拟内部的选举机制:假设有五台服务器,他们的ID分别是1-5。首先从ID为1开始,它进行投票,选择一台服务器为Leader,但是ID为1的服务器是会把这一票投给自己的,所以ID为1的票数为1,但是Leader只有票数超过总数的一半的时候才会产生(这里是总数是五台,其满足大于等于3就可以产生Leader)。所以轮到ID为2的服务器进行投票,当然ID为2的服务器是投自己的,所以ID为2的服务器票数为1,而这个时候ID为1的服务器就把自己的那一票投给ID为2的服务器(ID为1的服务器良心发现),所以这个时候ID为2的服务器票数为2,当然还没有满足票数大于总数的一半(这个场景票数为3才可以当Leader)。轮到ID为3的服务器开始投票,当然它也是自己投给自己,然后ID为1和ID为2的服务器也把自己的票投给ID为3的服务器,所以ID为3的服务器票数为3,满足票数大于总数的一半,ID为3的服务器变为Leader,而ID为4和ID为5没办法,只能乖乖被ID为3的服务器领导了。
图解如下:
五、节点类型
【1】持久:客户端和服务端断开连接后,创建的节点不删除。
①、持久化目录节点:客户端与服务端断开连接后,该节点依然存在。
②、持久化顺序编号目录节点:客户端与服务端断开连接后,该节点依然存在,只是给该节点名称进行顺序编号。
【2】短暂:客户端和服务端断开连接后,创建的节点自己删除。
①、临时目录节点:客户端与服务端断开连接后,该节点被删除。
②、临时顺序编号目录节点:客户端与服务端断开连接后,该节点被删除,只是给该节点名称进行顺序编号。
六、监听器原理
【1】首先要有一个main()线程。
【2】在main()线程中创建一个Zookeeper客户端,这个时候机会创建两个线程,一个负责网络连接通信(Connect),另外一个负责监听(Listener)。
【3】通过Connect线程将注册的监听事件发送给Zookeeper集群。
【4】在Zookeeper的注册监听器列表中添加注册的监听事件。
【5】Zookeeper监听到有数据或者路径发生变化,就会把消息发送给Listener线程。
【6】Listener线程就会调用内部process()方法处理业务。
图解如下:
七、写数据流程
【1】Client向Zookeeper中的Server1上写数据,发送Server1一个写请求。
【2】如果Server1不是Leader,那么Server1会把接受到的请求发送给Leader,然后Leader会把接受到的写请求广播给各个Server,比如Server1,Server2,Serber3,各个Server写成功后就会通知Leader。
【3】当Leader接受到大多数Server写数据成功的响应时(大多数是指超过服务器总数的一半),那么就认为写数据这个操作成功了,然后Leader就告诉Server1写数据成功了。
【4】Server1会进一步通知Client写数据成功了,这是整个写数据操作就认为是成功的了。
图解如下:
八、应用场景
【1】数据发布与订阅。
【2】 负载均衡(软负载均衡)。
【3】命名服务。
【4】分布式通知/协调。
【5】集群管理与 Leader 选举。
【6】分布式锁。
【7】分布式队列。
更多推荐
所有评论(0)