四面楚歌的Java工程师该何去何从？干货满满

1. 面试官：工作中使用过Zookeeper嘛？你知道它是什么，有什么用途呢？

小菜鸡的我：

• 有使用过的，使用ZooKeeper作为dubbo的注册中心，使用ZooKeeper实现分布式锁。
• ZooKeeper，它是一个开放源码的分布式协调服务，它是一个集群的管理者，它将简单易用的接口提供给用户。
• 可以基于Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
• Zookeeper的用途：命名服务、配置管理、集群管理、分布式锁、队列管理

用途跟功能不是一个意思咩？

2. 面试官：说下什么是命名服务，什么是配置管理，又什么是集群管理吧

小菜鸡的我(幸好我刷过面试题)，无所畏惧

• 命名服务就是：

  命名服务是指通过指定的名字来获取资源或者服务地址。Zookeeper可以创建一个全局唯一的路径，这个路径就可以作为一个名字。被命名的实体可以是集群中的机器，服务的地址，或者是远程的对象等。一些分布式服务框架（RPC、RMI）中的服务地址列表，通过使用命名服务，客户端应用能够根据特定的名字来获取资源的实体、服务地址和提供者信息等。

• 配置管理： ：

  实际项目开发中，我们经常使用.properties或者xml需要配置很多信息，如数据库连接信息、fps地址端口等等。因为你的程序一般是分布式部署在不同的机器上（如果你是单机应用当我没说），如果把程序的这些配置信息保存在zk的znode节点下，当你要修改配置，即znode会发生变化时，可以通过改变zk中某个目录节点的内容，利用watcher通知给各个客户端，从而更改配置。

• 集群管理

  集群管理包括集群监控和集群控制，其实就是监控集群机器状态，剔除机器和加入机器。zookeeper可以方便集群机器的管理，它可以实时监控znode节点的变化，一旦发现有机器挂了，该机器就会与zk断开连接，对用的临时目录节点会被删除，其他所有机器都收到通知。新机器加入也是类似酱紫，所有机器收到通知：有新兄弟目录加入啦。

3. 面试官：你提到了znode节点，那你知道znode有几种类型呢？zookeeper的数据模型是怎样的呢？

小菜鸡的我（我先想想）：

zookeeper的数据模型

ZooKeeper的视图数据结构，很像Unix文件系统，也是树状的，这样可以确定每个路径都是唯一的。zookeeper的节点统一叫做znode，它是可以通过路径来标识，结构图如下：

znode的4种类型

根据节点的生命周期，znode可以分为4种类型，分别是持久节点（PERSISTENT）、持久顺序节点（PERSISTENT_SEQUENTIAL）、临时节点（EPHEMERAL）、临时顺序节点（EPHEMERAL_SEQUENTIAL）

• 持久节点（PERSISTENT）

  这类节点被创建后，就会一直存在于Zk服务器上。直到手动删除。

• 持久顺序节点（PERSISTENT_SEQUENTIAL）

  它的基本特性同持久节点，不同在于增加了顺序性。父节点会维护一个自增整性数字，用于子节点的创建的先后顺序。

• 临时节点（EPHEMERAL）

  临时节点的生命周期与客户端的会话绑定，一旦客户端会话失效（非TCP连接断开），那么这个节点就会被自动清理掉。zk规定临时节点只能作为叶子节点。

• 临时顺序节点（EPHEMERAL_SEQUENTIAL）

  基本特性同临时节点，添加了顺序的特性。

4、面试官：你知道znode节点里面存储的是什么吗？每个节点的数据最大不能超过多少呢？

小菜鸡的我：

znode节点里面存储的是什么？

Znode数据节点的代码如下

public class DataNode implements Record {
    byte data[];                    
    Long acl;                       
    public StatPersisted stat;       
    private Set<String> children = null; 
}

哈哈，Znode包含了存储数据、访问权限、子节点引用、节点状态信息，如图：

• data: znode存储的业务数据信息
• ACL: 记录客户端对znode节点的访问权限，如IP等。
• child: 当前节点的子节点引用
• stat: 包含Znode节点的状态信息，比如事务id、版本号、时间戳等等。

每个节点的数据最大不能超过多少呢

为了保证高吞吐和低延迟，以及数据的一致性，znode只适合存储非常小的数据，不能超过1M，最好都小于1K。

5、面试官：你知道znode节点上的监听机制嘛？讲下Zookeeper watch机制吧。

小菜鸡的我：

• Watcher机制
• 监听机制的工作原理
• Watcher特性总结

Watcher监听机制

Zookeeper 允许客户端向服务端的某个Znode注册一个Watcher监听，当服务端的一些指定事件触发了这个Watcher，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher通知状态和事件类型做出业务上的改变。

可以把Watcher理解成客户端注册在某个Znode上的触发器，当这个Znode节点发生变化时（增删改查），就会触发Znode对应的注册事件，注册的客户端就会收到异步通知，然后做出业务的改变。

Watcher监听机制的工作原理

• ZooKeeper的Watcher机制主要包括客户端线程、客户端 WatcherManager、Zookeeper服务器三部分。
• 客户端向ZooKeeper服务器注册Watcher的同时，会将Watcher对象存储在客户端的WatchManager中。
• 当zookeeper服务器触发watcher事件后，会向客户端发送通知， 客户端线程从 WatcherManager 中取出对应的 Watcher 对象来执行回调逻辑。

Watcher特性总结

• **一次性：**一个Watch事件是一个一次性的触发器。一次性触发，客户端只会收到一次这样的信息。
• 异步的: Zookeeper服务器发送watcher的通知事件到客户端是异步的，不能期望能够监控到节点每次的变化，Zookeeper只能保证最终的一致性，而无法保证强一致性。
• 轻量级： Watcher 通知非常简单，它只是通知发生了事件，而不会传递事件对象内容。
• 客户端串行： 执行客户端 Watcher 回调的过程是一个串行同步的过程。
• 注册 watcher用getData、exists、getChildren方法
• 触发 watcher用create、delete、setData方法

6、面试官：你对Zookeeper的数据结构都有一定了解，那你讲下Zookeeper的特性吧

小菜鸡的我：（我背过书，啊哈哈）

Zookeeper 保证了如下分布式一致性特性：

• 顺序一致性：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。
• 原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
• 单一视图：无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
• 可靠性： 一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来。
• 实时性（最终一致性）： Zookeeper 仅仅能保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

7、面试官：你刚提到顺序一致性，那zookeeper是如何保证事务的顺序一致性的呢？

小菜鸡的我：（完蛋了这题不会）

需要了解事务ID，即zxid。ZooKeeper的在选举时通过比较各结点的zxid和机器ID选出新的主结点的。zxid由Leader节点生成，有新写入事件时，Leader生成新zxid并随提案一起广播，每个结点本地都保存了当前最近一次事务的zxid，zxid是递增的，所以谁的zxid越大，就表示谁的数据是最新的。

ZXID的生成规则如下：

ZXID有两部分组成：

• 任期：完成本次选举后，直到下次选举前，由同一Leader负责协调写入；
• 事务计数器：单调递增，每生效一次写入，计数器加一。

ZXID的低32位是计数器，所以同一任期内，ZXID是连续的，每个结点又都保存着自身最新生效的ZXID，通过对比新提案的ZXID与自身最新ZXID是否相差“1”，来保证事务严格按照顺序生效的。

8、面试官：你提到了Leader，你知道Zookeeper的服务器有几种角色嘛？Zookeeper下Server工作状态又有几种呢？

小菜鸡的我：

Zookeeper 服务器角色

Zookeeper集群中，有Leader、Follower和Observer三种角色

Leader

Leader服务器是整个ZooKeeper集群工作机制中的核心，其主要工作：

• 事务请求的唯一调度和处理者，保证集群事务处理的顺序性
• 集群内部各服务的调度者

Follower

Follower服务器是ZooKeeper集群状态的跟随者，其主要工作：

• 处理客户端非事务请求，转发事务请求给Leader服务器
• 参与事务请求Proposal的投票
• 参与Leader选举投票

Observer

Observer是3.3.0 版本开始引入的一个服务器角色，它充当一个观察者角色——观察ZooKeeper集群的最新状态变化并将这些状态变更同步过来。其工作：

• 处理客户端的非事务请求，转发事务请求给 Leader 服务器
• 不参与任何形式的投票

Zookeeper下Server工作状态

服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。

• 1.LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有 Leader，因此需要进入 Leader 选举状态。
• 2.FOLLOWING：跟随者状态。表明当前服务器角色是Follower。
• 3.LEADING：领导者状态。表明当前服务器角色是Leader。
• 4.OBSERVING：观察者状态。表明当前服务器角色是Observer。

9、面试官：你说到服务器角色是基于ZooKeeper集群的，那你画一下ZooKeeper集群部署图吧？ZooKeeper是如何保证主从节点数据一致性的呢？

小菜鸡的我：

ZooKeeper集群部署图

ZooKeeper集群是一主多从的结构：

• 如果是写入数据，先写入主服务器（主节点），再通知从服务器。
• 如果是读取数据，既读主服务器的，也可以读从服务器的。

ZooKeeper如何保证主从节点数据一致性

我们知道集群是主从部署结构，要保证主从节点一致性问题，无非就是两个主要问题：

• 主服务器挂了，或者重启了
• 主从服务器之间同步数据~

Zookeeper是采用ZAB协议（Zookeeper Atomic Broadcast，Zookeeper原子广播协议）来保证主从节点数据一致性的，ZAB协议支持崩溃恢复和消息广播两种模式，很好解决了这两个问题：

• 崩溃恢复：Leader挂了，进入该模式，选一个新的leader出来
• 消息广播： 把更新的数据，从Leader同步到所有Follower

Leader服务器挂了，所有集群中的服务器进入LOOKING状态，首先，它们会选举产生新的Leader服务器；接着，新的Leader服务器与集群中Follower服务进行数据同步，当集群中超过半数机器与该 Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式。Leader 服务器开始接收客户端的事务请求生成事务Proposal进行事务请求处理。

最后

文章中涉及到的知识点我都已经整理成了资料，录制了视频供大家下载学习，免费分享，诚意满满，希望可以帮助在这个行业发展的朋友，在论坛博客等地方少花些时间找资料，把有限的时间，真正花在学习上，所以我把这些资料，分享出来。相信对于已经工作和遇到技术瓶颈的朋友们，在这份资料中一定都有你需要的内容。

资料免费获取方式：点击这里免费领取Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术资料

等地方少花些时间找资料，把有限的时间，真正花在学习上，所以我把这些资料，分享出来。相信对于已经工作和遇到技术瓶颈的朋友们，在这份资料中一定都有你需要的内容。**

[外链图片转存中…(img-bUxkBIFG-1626359030737)]

资料免费获取方式：点击这里免费领取Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术资料

标签：四面楚歌,Java,Zookeeper,Leader,干货,集群,服务器,节点,客户端
来源： https://blog.csdn.net/m0_57771583/article/details/118770453