能否简单说一下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为２的服务器票数为２，当然还没有满足票数大于总数的一半（这个场景票数为３才可以当Leader）。轮到ID为３的服务器开始投票，当然它也是自己投给自己，然后ID为１和ID为２的服务器也把自己的票投给IＤ为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】分布式队列。

感谢你看到这里，我是程序员麦冬，一个java开发从业者，深耕行业六年了，每天都会分享java相关技术文章或行业资讯

欢迎大家关注和转发文章，后期还有福利赠送！