@TOC

前言

主要理顺zookeeper的相关知识点以及面试常被问及的知识点
基础知识可看我之前的文章
Zookeeper从入门到精通（全）

1. Zookeeper的了解

zookeeper主要是文件系统（存储数据）和通知机制（进行通知信息）

它是一个为分布式应用提供一致性服务的软件

具体都有哪些些功能

• 统一命名服务（域名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息）
• 统一配置管理（一个集群中的所有配置都一致，且也要实时更新同步）

将配置信息写入ZooKeeper上的一个Znode，各个客户端服务器监听这个Znode。一旦Znode中的数据被修改，ZooKeeper将通知各个客户端服务器

• 统一集群管理（掌握实时状态）

将节点信息写入ZooKeeper上的一个ZNode。监听ZNode获取实时状态变化

• 服务器节点动态上下线（主节点挂了，从备用节点中选举）
• 软负载均衡（根据每个节点的访问数，让访问数最少的服务器处理最新的数据需求）
• 分布式锁（提供两种独占锁，共享锁）

2. ZAB协议 / 主从节点的同步了解

ZAB 协议包括两种基本的模式：崩溃恢复和消息广播。

假设两种服务器异常情况：
（1）假设一个事务在Leader提出之后，Leader挂了。
（2）一个事务在Leader上提交了，并且过半的Follower都响应Ack了，但是Leader在Commit消息发出之前挂了。

Zab协议崩溃恢复要求满足以下两个要求：
（1）确保已经被Leader提交的提案Proposal，必须最终被所有的Follower服务器提交。 （已经产生的提案，Follower必须执行）
（2）确保丢弃已经被Leader提出的，但是没有被提交的Proposal。（丢弃胎死腹中的提案）

之后开始新的leader的选举

Leader选举：根据上述要求，Zab协议需要保证选举出来的Leader需要满足以下条件：

（1）新选举出来的Leader不能包含未提交的Proposal。即新Leader必须都是已经提交了Proposal的Follower服务器节点
（2）新选举的Leader节点中含有最大的zxid。这样做的好处是可以避免Leader服务器检查Proposal的提交和丢弃工作。

消息广播模式：当集群超过半数机器与该Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式

Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。

之后ZooKeeper 服务一直维持广播状态，直到 leader 崩溃了或者 leader 失去了大部分的 followers 支持。

3. 多少种部署方式

• 单机部署（一台集群）
• 集群部署：（多台集群）
• 伪集群部署：（一台集群运行多个zookeeper）

4. 通知机制

客户端对某个节点进行监听，当节点发生变化的时候，客户端会收到zookeeper的通知，之后客户端会根据节点的变化做出改变

5. 集群节点的个数

集群规则为 2N+1
只要集群中半数以上的节点存活，集群就可以正常提供服务

比如：

集群中只有2台服务器，1台挂掉，集群不工作

集群中只有3台服务器（3的半数是1.5，半数以上是2），1台挂掉，集群重新选主对外工作（也就允许一台挂掉）

集群中只有4台服务器（4的半数为2，半数以上最少为3），1台挂掉，集群重新选主对外工作（也就允许一台挂掉）

特别重要的特点:
2n+1台和2n+2台机器的容灾能力相同，都是允许n台机器宕机。
一般选择部署2n+1台机器（节约数量）

6. 节点的类型有什么

节点类型分为（两两进行组合）

• 持久/短暂
• 有序号/无序号

如果退出客户端，这些短暂节点将会被清除

至于有序号的节点：一般都是在节点名后，追加一个由父节点维护的自增整型数字。

7. 集群安装的特点

要安装奇数台

服务器台数多：

• 好处，提高可靠性；
• 坏处：提高通信延时

8. 选举机制是如何的

半数机制，超过半数的投票通过，即通过。

（1）第一次启动选举规则：
投票过半数时，服务器 id 大的胜出

（2）第二次启动选举规则：
①EPOCH 大的直接胜出
②EPOCH 相同，事务 id 大的胜出
③事务 id 相同，服务器 id 大的胜出

9. Zookeeper与dubbo的关系

通过dubbo引入zookeeper
外接不同媒介给注册中心

可以达到负载均衡，管理各个节点
可以达到命名服务，更好的管理节点
可以达到节点和资源之间更好的同步（本身就有很好的机制）
可以有分布式锁等等

10. 分布式锁的了解

通过节点的加锁解锁
主要是通过监听机制，以及每个加锁节点的序号，前一个节点序号解锁，下一个节点序号才可加锁的机制等

详情可看这篇友情链接
Zookeeper 分布式锁 - 图解 - 秒懂

11. 客户端向服务端写数据流程

发送给leader的时候
通俗解释：客户端给服务器的leader发送写请求，写完数据后给手下发送写请求，手下写完发送给leader，超过半票以上都写了则发回给客户端。之后leader在给其他手下让他们写，写完在发数据给leader

发送给follower的时候
通俗解释：客户端给手下发送写的请求，手下给leader发送写的请求，写完后，给手下发送写的请求，手下写完后给leader发送确认，超过半票，leader确认后，发给刻划断，之后leader在发送写请求给其他手下

补充：
关于这个流程，详情可参照以下友情连接的补充
说一下两阶段提交和三阶段提交的过程？分别有什么问题？