每个节点的数据最大不能超过多少呢
为了保证高吞吐和低延迟，以及数据的一致性，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是如何保证事务的顺序一致性的呢？
小菜鸡的我：（完蛋了这题不会）
这道题可以看下这篇文章（本题答案来自该文章）：聊一聊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进行事务请求处理。
10、面试官：Leader挂了，进入崩溃恢复，是如何选举Leader的呢？你讲一下ZooKeeper选举机制吧
小菜鸡的我：
服务器启动或者服务器运行期间（Leader挂了），都会进入Leader选举，我们来看一下~假设现在ZooKeeper集群有五台服务器，它们myid分别是服务器1、2、3、4、5，如图：
服务器启动的Leader选举
zookeeper集群初始化阶段，服务器（myid=1-5）依次启动，开始zookeeper选举Leader~
-
服务器1（myid=1）启动，当前只有一台服务器，无法完成Leader选举
-
服务器2（myid=2）启动，此时两台服务器能够相互通讯，开始进入Leader选举阶段
-
每个服务器发出一个投票
服务器1 和 服务器2都将自己作为Leader服务器进行投票，投票的基本元素包括：服务器的myid和ZXID，我们以（myid，ZXID）形式表示。初始阶段，服务器1和服务器2都会投给自己，即服务器1的投票为（1,0），服务器2的投票为（2,0），然后各自将这个投票发给集群中的其他所有机器。
-
接受来自各个服务器的投票
每个服务器都会接受来自其他服务器的投票。同时，服务器会校验投票的有效性，是否本轮投票、是否来自LOOKING状态的服务器。
-
处理投票
收到其他服务器的投票，会将被人的投票跟自己的投票PK，PK规则如下：
- 优先检查ZXID。ZXID比较大的服务器优先作为leader。
- 如果ZXID相同的话，就比较myid，myid比较大的服务器作为leader。 服务器1的投票是（1,0），它收到投票是（2,0），两者zxid都是0，因为收到的myid=2，大于自己的myid=1，所以它更新自己的投票为（2,0），然后重新将投票发出去。对于服务器2呢，即不再需要更新自己的投票，把上一次的投票信息发出即可。
-
统计投票
每次投票后，服务器会统计所有投票，判断是否有过半的机器接受到相同的投票信息。服务器2收到两票，少于3（n/2+1,n为总服务器），所以继续保持LOOKING状态
-
-
服务器3（myid=3）启动，继续进入Leader选举阶段
跟前面流程一致，服务器1和2先投自己一票，因为服务器3的myid最大，所以大家把票改投给它。此时，服务器为3票（大于等于n/2+1）,所以服务器3当选为Leader。 服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；
-
服务器4启动，发起一次选举。
此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。选票信息结果：服务器3为4票，服务器4为1票。服务器4并更改状态为FOLLOWING；
-
服务器5启动，发起一次选举。
同理，服务器也是把票投给服务器3，服务器5并更改状态为FOLLOWING；
-
投票结束，服务器3当选为Leader
服务器运行期间的Leader选举
zookeeper集群的五台服务器（myid=1-5）正在运行中，突然某个瞬间，Leader服务器3挂了，这时候便开始Leader选举~
-
1.变更状态
Leader 服务器挂了之后，余下的非Observer服务器都会把自己的服务器状态更改为LOOKING，然后开始进入Leader选举流程。
-
2.每个服务器发起投票
每个服务器都把票投给自己，因为是运行期间，所以每台服务器的ZXID可能不相同。假设服务1,2,4,5的zxid分别为333,666,999,888，则分别产生投票（1,333），（2，666），（4,999）和（5,888），然后各自将这个投票发给集群中的其他所有机器。
-
3.接受来自各个服务器的投票
-
4.处理投票
投票规则是跟Zookeeper集群启动期间一致的，优先检查ZXID，大的优先作为Leader，所以显然服务器zxid=999具有优先权。
-
5.统计投票
-
6.改变服务器状态
11、面试官： 你前面提到在项目中使用过Zookeeper的分布式锁，讲一下zk分布式锁的实现原理吧？
小菜鸡的我：
Zookeeper就是使用临时顺序节点特性实现分布式锁的。
最后
看完美团、字节、腾讯这三家的面试问题，是不是感觉问的特别多，可能咱们又得开启面试造火箭、工作拧螺丝的模式去准备下一次的面试了。
开篇有提及我可是足足背下了1000道题目，多少还是有点用的呢，我看了下，上面这些问题大部分都能从我背的题里找到的，所以今天给大家分享一下互联网工程师必备的面试1000题。
注意：不论是我说的互联网面试1000题，还是后面提及的算法与数据结构、设计模式以及更多的Java学习笔记等，皆可分享给各位朋友，直接戳这里即可免费下载
互联网工程师必备的面试1000题
而且从上面三家来看，算法与数据结构是必备不可少的呀，因此我建议大家可以去刷刷这本左程云大佬著作的《程序员代码面试指南 IT名企算法与数据结构题目最优解》，里面近200道真实出现过的经典代码面试题。
习笔记等，皆可分享给各位朋友，直接戳这里即可免费下载
[外链图片转存中…(img-SebJDdfW-1628291408337)]
互联网工程师必备的面试1000题
而且从上面三家来看，算法与数据结构是必备不可少的呀，因此我建议大家可以去刷刷这本左程云大佬著作的《程序员代码面试指南 IT名企算法与数据结构题目最优解》，里面近200道真实出现过的经典代码面试题。
