Zookeeper主要是基于文件系统和监听通知机制，可以用于统一命名服务、分布式配置管理、集群管理、分布式锁、分布式队列、负载均衡等功能。
文件系统结构
Zookeeper维护一个类似文件系统的数据结构：
每一个子目录，如NameService称之为一个znode目录节点，和文件系统一样，我们可以对znode节点进行添加、删除操作，在znode的子节点下添加删除操作，唯一的不同是znode是可以保存数据的，数据还包含当前版本、数据版本、建立时间和修改时间等
数据类型
Zookeeper支持四种类型的节点数据：
持久化目录节点(persistent)：客户端与zookeeper断开连接后，该节点依然存在
持久化顺序编号目录节点(persistent_sequential)：与持久化目录节点一样，不过Zookeeper给该节点进行顺序编号
临时目录节点(ephemeral)：客户端与zookeeper断开连接后，该节点被删除
临时顺序编号目录节点(ephemeral_sequential)：与临时目录节点一样，不过Zookeeper给该节点进行顺序编号
监听通知机制
客户端监听它所关心的目录节点，当目录节点发生变化(数据改变、删除、子目录节点发生变化)的时候，zookeeper会通知客户端，在Zookeeper中，默认有二种角色，Follower、Leader，一个Zookeeper集群在同一时刻只会有一个Leader，其余都是Follower，我们还可以添加Observer角色，如果想使用Observer模式，在任何想变成Observer的节点的配置文件中加入：peerType=Observer。Leader服务器可以为客户端提供读和写操作，而Follower和Observer都只能提供读服务，唯一的区别是Observer不参与Leader选举过程，也不参与写操作(过半写成功)策略，因此Observer可以在不影响写性能的情况下提升集群的读性能。
应用场景
Zookeeper所有的功能都是基于文件系统和监听通知机制来完成的，下面来讲解一下各个功能的实现原理：
分布式配置管理
在大型系统中，我们部署的项目可能超过上百台机器，当我们在修改配置的时候，不可能每一台机器都去修改一下，这样维护起来太复杂了，所以我们可以将配置文件通过Zookeeper来管理，在Zookeeper中创建一个Configuration的目录节点，所有应用程序都监听这个目录节点，一旦配置文件的信息发生变化，Zookeeper会通知每个应用，然后每个应用从Zookeeper中获取最新的配置信息。
Zookeeper集群环境
如上图，我们在三台服务器上部署了Zookeeper的集群环境，在三台机器的Zookeeper启动完成后，会选举一台机器为Leader，负责客户端的的读和写请求，其他两条机器为Follower，只能负责读请求
场景模拟：当我们通过zkclient在192.168.1.1的机器上创建了一个/hello的数据节点，会发现这台Follower也能写成功，并且在192.168.1.2或者192.168.1.3的机器上都能够获取到，那么是不是就与上面的Follower只能负责读理论冲突了？其实并没有冲突，而是Follower在接受到写请求后，它会将写请求转给Leader节点，让Leader节点去处理写请求，Leader写成功后会通知同步到各个Follower节点，这样做的目的是保证数据的唯一性，过程如下：
1、 Client向Follower发起一个写请求
2、 Follower把写请求转发给Leader
3、 Leader接收到请求以后开始发起投票并通知Follower进行投票
4、 Follower把投票结果发送给Leader
5、 Leader将结果汇总，发现如果超过一半的节点支持写入，那么投票成功，则开始写入同时把写入操作通知给Follower，然后commit
6、 Follower把请求结果返回给Client
集群选举原理
还是拿上面的写请求作为分析案例，当我们的Follower向Leader发送一个写请求后，会在Leader节点生成一个全局唯一的严格保证顺序递增的事务ID(ZXID)，因为读不会有事务的概念，写才有事务的概念，生成后Leader节点会向所有的Follower节点服务器发送请求，并且所有的Follower服务器会发送一个收到事务通知的确认消息到Leader服务器，只要Leader服务器收到超过一半的Follower服务器发过来的确认消息，Leader服务器就可以开始做Commit操作，同时也通知其他Follower服务器做Commit操作，这样在一台Follower服务器上写数据后，其他服务器都能够同步更新，这里面涉及到两阶段提交，这样做的目的是保证了数据的一致性，性能也比较高。
如果其中Leader节点因为某种原因而导致服务器挂了，那么如何保证高可用呢，Zookeeper会通过集群选举一个新的节点作为Leader节点，实现如下：当Leader节点不可用的时候，所有的Follower节点会向集群中其他的存活的Follower节点发送投票消息，该消息格式为(myid,zxid)，每台服务器当然是优先投自己，其中myid为集群搭建的时候我们自己配置的，zxid为该服务器最新的zxid，每台机器的zxid由于受到Leader消息的前后可能会不一样，当每台机器接受到来自不同Follower发送的消息后，根据最大的zxid进行pk，谁的最大，谁的票数最多，然后其他的票数作废，因为最大的zxid的服务器肯定能保证数据是最新最全的，当每台服务器选举出来结果后会做更新操作，同时会向其他服务器发通知，其他服务器收到投票通知后，当其中一台服务器得到的票数大于总服务器数的一半，那么该服务器就成功选举成为Leader，所以我们在搭建集群环境的时候，最好搭建的集群数量为奇数，集群Leader选举和集群消息广播(两阶段提交)的组合就是zab原子广播协议。Zookeeper没有用到paxos算法来保证数据一致性，zab协议其实是paxos算法的一个变种。
分布式锁
分布式锁主要用于在分布式环境中保护跨进程、跨主机、跨网络的共享资源实现互斥访问，以达到保证数据的一致性。Zookeeper实现分布式锁是通过持久节点和临时顺序节点来完成的，实现思路如下：
1、 在指定目录下创建一个持久节点，例如lock节点(zookeeper里面的znode节点会自动同步，而且是强一致性的，创建一个节点后只有zookeeper集群同步完成后才算成功)
2、 每当进程需要访问共享资源的时候，会在lock下面建立响应的顺序临时子节点，例如tmp_node1、tmp_node2、tmp_node3
3、 建立临时顺序子节点后，判断建立的子节点的顺序号(临时子节点创建会自动生成一个顺序号)是否为最小节点，如果是最小节点，就可以获得锁对资源进行访问
4、 如果该节点不是最小节点，那么就获得该节点的上一个顺序节点，并给该节点注册监听事件监听
5、 当客户端关闭与zookeeper连接之后，会删除当前的临时子节点，释放当前的锁，下面的临时节点会得到通知，并判断自己的节点是否为当前最小的，如果是则获取共享锁，如果不是则继续第4步对比自己小的节点注册监听事件
流程如下：
创作不容易，欢迎大家关注2B哥微信公众号：（Java2B）
转载：https://blog.csdn.net/HarderXin/article/details/103975611