【金九银十】Zookeeper常用场景使用介绍

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步对比自己小的节点注册监听事件
流程如下：

在这边跟大家分享一些一线大厂Java面试题，希望能给后续想要去面试阿里巴巴等一线互联网大厂的小伙伴一些帮助！学习技术内容包含有：Spring，Dubbo，MyBatis, RPC, 源码分析，高并发、高性能、分布式,性能优化，微服务 高级架构开发等等。

下面这个链接，暗号： csdn 。加入即可获得。
点这个，点这个。

另外还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书。