Zookeeper概述
Zookeeper是一种分布式协调服务。
主要服务于分布式系统，解决分布式系统节点管理问题的中间件。
Zookper = 文件系统 + 通知机制
面试中问到的那些分布式问题 — zookeeper：https://www.bilibili.com/video/BV1xv411t7xu
C/C++Linux服务器开发/后台架构师学习视频：https://ke.qq.com/course/417774?flowToken=1031343
ZooKeeper应用场景
- 统一配置管理
- 统一命名服务
- 分布式锁
- 集群管理
ZooKeeper工作机制
Zookeeper从设计模式角度来理解，是一个基于观察者模式的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者，作出相应的反应。
ZooKeeper集群特点
- Zookeeper集群是一个领导者(Leader)和多个跟随者(Follower)组成的集群。
- 集群中只要有半数以上的节点存活，Zookeeper就能正常工作。
- 全局数据一致性，每个Server保存一份相同的数据，Client无论连接到哪个Server，数据都是一致的。
- 更新请求顺序进行，来自同一个Client的更新请求按其顺序依此执行。
- 数据更新原子性，一次数据更新要么全部成功，要么全部失败。
- 实时性：在一定的时间范围内，Client能读到最新数据。
Zookeeper数据结构
- 类似数据结构中的树，也像文件系统的目录。
- Zookeeper的数据存储也同样是基于节点，这种节点叫做Znode。
- Znode的引用方式是路径引用，类似于文件路径：/ 动物 / 仓鼠。
- 每个ZNode都可以通过其路径唯一标示。
- Znode并不是用来存储大规模业务数据，而是用于存储少量的状态和配置信息，每个节点的数据最大不能超过1MB。
Znode分类
短暂/临时(Ephemeral)：当客户端和服务端断开连接后，所创建的Znode(节点)会自动删除
持久(Persistent)：当客户端和服务端断开连接后，所创建的Znode(节点)不会删除
- 短暂 ：普通短暂节点、带序列号短暂节点
- 持久 ：普通持久节点、带序列号持久节点
Znode包含内容
data
Znode存储的数据信息。
ACL
记录Znode的访问权限，即哪些人或哪些IP可以访问本节点。
stat
包含Znode的各种元数据，比如事务ID、版本号、时间戳、大小等等。
child
当前节点的子节点引用。
Zookeeper基本操作
help ———— 显示所有操作命令
create ———— 创建节点（-s 含有序列、-e临时）
delete ———— 删除节点
exists ———— 节点是否存在
getData ———— 获得一个节点的数据
setData ———— 设置一个节点的数据
getChildren ———— 获取节点下的所有子节点
stat ———— 节点状态
rmr ———— 递归删除节点
Watch机制
监听场景
- 监听Znode节点的数据变化
- 监听子节点的增减变化
交互过程
1.客户端调用getData方法，watch参数是true。服务端接到请求，返回节点数据，并且在对应的哈希表里插入被Watch的Znode路径，以及Watcher列表。
Watch的Znode已删除，服务端会查找哈希表，找到该Znode对应的所有Watcher，异步通知客户端，并且删除哈希表中对应的Key-Value。
Zookeeper的一致性
Zookeeper作为分布式系统的协调服务，为了防止单机挂掉的情况，维护了一个集群
在更新数据时，首先更新到主节点（这里的节点是指服务器，不是Znode），再同步到从节点。 为了保证主从节点的数据一致性，Zookeeper采用了ZAB协议。
C/C++Linux服务器开发/后台架构师面试题、学习资料、教学视频和学习路线图，免费分享有需要的可以自行添加学习交流群960994558
ZAB协议
Zookeeper Atomic Broadcast
节点状态
-
Looking ：选举状态。
-
Following ：Follower节点（从节点）所处的状态。
-
Leading ：Leader节点（主节点）所处状态。
最大ZXID
最大ZXID也就是节点本地的最新事务编号。
集群崩溃恢复过程
1.Leader election
选举阶段，此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票，投票当中包含自己的服务器ID和最新事务ID（ZXID）。
接下来，节点会用自身的ZXID和从其他节点接收到的ZXID做比较，如果发现别人家的ZXID比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的ZXID所属节点。
每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。
2.Discovery
发现阶段，用于在从节点中发现最新的ZXID和事务日志。 既然Leader被选为主节点，已经是集群里数据最新的了，为什么还要从节点中寻找最新事务呢？这是为了防止某些意外情况，比如因网络原因在上一阶段产生多个Leader的情况。所以这一阶段，Leader集思广益，接收所有Follower发来各自的最新epoch(ZXID包含)值。Leader从中选出最大的epoch，基于此值加1，生成新的epoch分发给各个Follower。各个Follower收到全新的epoch后，返回ACK（确认字符）给Leader，带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID，并更新自身历史日志。
3.Synchronization
同步阶段，把Leader刚才收集得到的最新历史事务日志，同步给集群中所有的Follower。只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。
自此，故障恢复正式完成。
ZAB如何写入数据
Broadcast：Zookeeper常规情况下更新数据的时候，由Leader广播到所有的Follower。
1.客户端发出写入数据请求给任意Follower。
2.Follower把写入数据请求转发给Leader。
3.Leader采用二阶段提交方式，先发送Propose广播给Follower。
4.Follower接到Propose消息，写入日志成功后，返回ACK消息给Leader。
5.Leader接到半数以上ACK消息，返回成功给客户端，并且广播Commit请求给Follower。
Zab协议既不是强一致性，也不是弱一致性，而是处于两者之间的单调一致性。它依靠事务ID和版本号，保证了数据的更新和读取是有序的。
Zookeeper应用场景
统一配置管理
比如我们现在有三个系统A、B、C，他们有三份配置，分别是ASystem.yml、BSystem.yml、CSystem.yml，然后，这三份配置又非常类似，很多的配置项几乎都一样。
此时，如果我们要改变其中一份配置项的信息，很可能其他两份都要改。并且，改变了配置项的信息很可能就要重启系统。
于是，我们希望把ASystem.yml、BSystem.yml、CSystem.yml相同的配置项抽取出来成一份公用的配置common.yml，并且即便common.yml改了，也不需要系统A、B、C重启。
做法：我们可以将common.yml这份配置写入ZooKeeper的Znode节点中，系统A、B、C监听着这个Znode节点有无变更，一旦Znode中的数据被修改，Zookeeper将通知各个客户端服务器。
统一命名服务
统一命名服务的理解其实跟域名一样，是我们为这某一部分的资源给它取一个名字，别人通过这个名字就可以拿到对应的资源。 对于某个域名www.baidu.com,域名下有多台机器：
- 192.168.1.1
- 192.168.1.2
- 192.168.1.3
- 192.168.1.4
分布式锁
一节课搞懂分布式锁以及数据库锁 （Nginx|Redis|mysql|zookeeper）：https://www.bilibili.com/video/BV1rN411f73d
我们可以使用ZooKeeper来实现分布式锁 系统A、B、C都去访问/locks节点
访问的时候会创建带顺序号的临时/短暂(EPHEMERAL_SEQUENTIAL)节点，比如，系统A创建了id_000000节点，系统B创建了id_000002节点，系统C创建了id_000001节点。
接着，拿到/locks节点下的所有子节点(id_000000,id_000001,id_000002)，判断自己创建的是不是最小的那个节点
如果是，则拿到锁。 释放锁：执行完操作后，把创建的节点给删掉 如果不是，则监听比自己要小1的节点变化
举例：
系统A拿到/locks节点下的所有子节点，经过比较，发现自己(id_000000)，是所有子节点最小的。所以得到锁
系统B拿到/locks节点下的所有子节点，经过比较，发现自己(id_000002)，不是所有子节点最小的。所以监听比自己小1的节点id_000001的状态
系统C拿到/locks节点下的所有子节点，经过比较，发现自己(id_000001)，不是所有子节点最小的。所以监听比自己小1的节点id_000000的状态
……
等到系统A执行完操作以后，将自己创建的节点删除(id_000000)。通过监听，系统C发现id_000000节点已经删除了，发现自己已经是最小的节点了，于是顺利拿到锁
统一集群管理
分布式环境中，实时掌握每个节点的状态是必要的。
可根据节点实时状态做出一些调整。
Zookeeper可以实现实时监控节点状态变化：
1）将节点信息写入Zookeeper上的一个ZNode
2）监听这个ZNode获取它的实时状态变化
以我们三个系统A、B、C为例，
只要系统A挂了，那/groupMember/A这个节点就会删除，通过监听groupMember下的子节点，系统B和C就能够感知到系统A已经挂了。(新增也是同理)
除了能够感知节点的上下线变化，ZooKeeper还可以实现动态选举Master的功能。
服务动态上下线
软负载均衡
Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求。
重点
选举机制
1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
2）Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。
3）以一个简单的例子来说明整个选举的过程。
假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么：
（1）服务器1启动，此时只有它一台服务器启动了，它发出去的报文没有任何响应，所以它的选举状态一直是LOOKING状态。
（2）服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。
（3）服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的Leader。
（4）服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了。
（5）服务器5启动，同4一样当小弟。
监听器原理
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
