Zookeeper学习个人总结

学习心得，记录于此。自己能随时查漏补缺，也望诸君不吝赐教，批评指正。同时有好的工作机会可以联系一下我。

NO1：说说zookeeper是什么？

Zookeeper一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心，服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。

NO2：了解Zookeeper的系统架构吗？

ZooKeeper 的架构图中我们需要了解和掌握的主要有：

（1）ZooKeeper分为服务器端（Server） 和客户端（Client），客户端可以连接到整个 ZooKeeper服务的任意服务器上（除非 leaderServes 参数被显式设置， leader 不允许接受客户端连接）。
（2）客户端会使用并维护TCP链接，通过这个链接发送请求，接受响应，获取观察的事务和发送心跳。如果这个TCP中断，客户端就会尝试连接另外的zookeeper服务器。
（3）组成zookeeper服务的服务器必须彼此了解。他们中间维护一个内存中的状态图像，以及持久保存的事务日志和快照，只要大多数服务可以用，zookeeper就可以用。
（4）zookeeper启动时，将从实例中选举一个leader，leader负责处理数据更新等操作。
（5）zookeeper中数据是一致性。
（6）zab协议：leader election和actomic brodcast阶段
一.集群中将选举一个leader，其他都被称为follower,所有的写操作传送给leader，并更新到每个follower。
二.当leader崩溃或者leader失去大多数的follower时，需要重新选举新leader。
三.leader被选举出来的时候，leader election就结束了，只剩下同步信息状态了。

NO3：能说说Zookeeper的工作原理？

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式，它们 分别是恢复模式（选主）和广播模式（同步）。
Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。
每个Server在工作过程中有三种状态：
LOOKING：当前Server不知道leader是谁，正在搜寻。
LEADING：当前Server即为选举出来的leader。
FOLLOWING：leader已经选举出来，当前Server与之同步。

NO4：Zookeeper为什么要这么设计？

ZooKeeper设计的目的是提供高性能、高可用、顺序一致性的分布式协调服务、保证数据最终一致性。
高性能：简单的数据模型
1.采用树形结构组织数据节点。
2.全量数据节点，都存储在内存中。
3.follower和observer直接处理非事务请求
高可用
1.半数以上机器存活，服务就能正常运行。
2.自动进行leader选举。
顺序一致性
1.每个事务请求，都会转发给leader处理。
2.每个事务，会分配全局唯一的递增id。保证最终一致性。
最终一致性
1.通过提议投票方式，保证事务提交的可靠性。
2.提议投票方式，只能保证客户端收到事务提交成功后，半数以上节点能看到最新数据。

NO5：你知道Zookeeper中有哪些角色？

领导者（leader）
Leader服务器为客户端提供读服务和写服务。负责进行投票的发起和决议，更新系统状态。
跟随者（follower） Follower服务器为客户端提供读服务，参与Leader选举过程，参与写操作“过半写成功”策略。
客户端（client）：服务请求发起方。

NO6：你熟悉Zookeeper节点ZNode和相关属性吗？

Znode两种类型：
1.持久的（persistent）：客户端和服务器端断开连接后，创建的节点不删除（默认）。
2.短暂的（ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除。
Znode有四种形式：
1.持久化目录节点（存储的数据不会丢失。）
2. 顺序自动编号的持久化目录节点（存储的数据不会丢失，并且根据当前已近存在的节点数自动加 1）
3.临时目录节点
4.临时自动编号节点

NO7：请简述Zookeeper的选主流程

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当leader崩溃就是恢复模式，恢复完成就是广播模式。leader选举是保证分布式数据一致性的关键。
如何进入选举模式
leader不可用
选举规则：
（1）初始阶段，都会给自己投票。
（2）当接收到来自其他服务器的投票时，都需要将别人的投票和自己的投票进行pk。优先检查zxid。zxid比较大的服务器优先作为leader。如果zxid相同的话，就比较sid，sid比较大的服务器作为leader。

NO8：有了解过watch机制吗？

client端会对某个znode 注册一个watcher事件，当该znode发生变化时，这些client会收到ZooKeeper的通知，然后client可以根据znode变化来做出业务上的改变等。
经典使用场景：zookeeper为dubbo提供服务的注册与发现，作为注册中心。
服务注册：服务提供者（Provider）启动时，会向zookeeper服务端注册服务信息，也就是创建一个节点，存储服务的相关数据。
服务发现：服务消费者（Consumer）启动时，根据自身配置的依赖服务信息，向zookeeper服务端获取注册的服务信息并设置watch监听，获取到注册的服务信息之后，将服务提供者的信息缓存在本地，并进行服务的调用。
服务通知：一旦服务提供者因某种原因宕机不再提供服务之后，客户端与zookeeper服务端断开连接，zookeeper服务端上服务提供者对应服务节点会被删除（例如：用户注册服务com.xxx.user.register），随后zookeeper服务端会异步向所有消费用户注册服务com.xxx.user.register，且设置了watch监听的服务消费者发出节点被删除的通知，消费者根据收到的通知拉取最新服务列表，更新本地缓存的服务列表。

NO9：那你说说Zookeeper有哪些应用场景？

数据发布与订阅
zookeeper为dubbo提供服务的注册与发现
分布式锁
写锁：在zk上创建的一个临时的无编号的节点。由于是无序编号，在创建时不会自动编号，导致只能客户端有一个客户端得到锁，然后进行写入。

读锁：在zk上创建一个临时的有编号的节点，这样即使下次有客户端加入是同时创建相同的节点时，他也会自动编号，也可以获得锁对象，然后对其进行读取。

时序锁：在zk上创建的一个临时的有编号的节点根据编号的大小控制锁。

阻塞锁和非阻塞锁
阻塞锁：多个系统同时调用同一个资源，所有请求被排队处理。已经得到分布式锁的系统，进入运行状态完成业务操作；没有得到分布式锁的线程进入阻塞状态等待，当获得相应的信号并获得分布式锁后，进入运行状态完成业务操作。
非阻塞锁：多个系统同时调用同一个资源，当某一个系统最先获取到锁，进入运行状态完成业务操作；其他没有得到分布式锁的系统，就直接返回，不做任何业务逻辑，可以给用户提示进行其他操作。

NO10：知道监听器的原理吗？

1.创建一个Main()线程。
2.在Main()线程中创建两个线程，一个负责网络连接通信（connect），一个负责监听（listener）。
3.通过connect线程将注册的监听事件发送给Zookeeper。
4.将注册的监听事件添加到Zookeeper的注册监听器列表中。
5.Zookeeper监听到有数据或路径发生变化时，把这条消息发送给Listener线程。
6.Listener线程内部调用process()方法。

NO11：为什么Zookeeper集群的数目，一般为奇数个？

首先需要明确zookeeper选举的规则：leader选举，要求可用节点数量 > 总节点数量/2。
zookeeper有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。
zookeeper的选举策略也是需要半数以上的节点同意才能当选leader，如果是偶数节点可能导致票数相同的情况。