Zookeeper概述

概述

Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出响应的反应。
（1）Zookeeper：一个领导者，多个跟随者组成的集群。
（2）集群中只要有半数以上的节点存活，Zookeeper集群就能正常服务。
（3）全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
（4）更新请求顺序，来自同一个Client的更新请求按其发送顺序依次执行。
（5）数据更新原子性，一次数据更新要么成功，要么失败。
（6）实时性，在一定时间范围内，Client能读到最新数据。

数据结构

说明Zookeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点可以称作一个ZNode。每一个ZNode默认能够存储1M的数据，每个ZNode都可以通过其路径唯一标识。

选举机制（面试重点）

监听器原理（面试重点）

写数据流程

选举机制中涉及到的核心概念

（1）Server id（或sid）：服务器ID
比如有三台服务器，编号分别是1,2,3。编号越大在选择算法中的权重越大，比如初始化启动时就是根据服务器ID进行比较。
（2）Zxid：事务ID
服务器中存放的数据的事务ID，值越大说明数据越新，在选举算法中数据越新权重越大。
（3）Epoch：逻辑时钟
也叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的，每投完一次票这个数据就会增加。
（4）Server状态：选举状态
LOOKING，竞选状态。
FOLLOWING，随从状态，同步leader状态，参与投票。
OBSERVING，观察状态,同步leader状态，不参与投票。
LEADING，领导者状态。

客户端常用命令行

命令基本语法	功能描述
help	显示所有操作命令
ls path [watch]	使用ls命令来查看当前znode中所包含的内容
ls2 path [watch]	查看当前节点数据并能看到更新次数等数据
create	普通创建
-s	含有序列
-e	临时（重启或者超时消失）
getpath [watch]	获得节点的值
set	设置节点的具体值
stat	查看节点的状态
delete	删除节点
rmr	递归删除节点

服务器运行时期Leader选举

在 Zookeeper运行期间 Leader 和 非 Leader 各司其职，当有非 Leader 服务器宕机或加入不会影响 Leader，但是一旦 Leader 服务器挂了，那么整个 Zookeeper 集群将暂停对外服务，会触发新一轮的选举。
运行期选举与初始状态投票过程基本类似，大致可以分为以下几个步骤：
（1）状态变更。Leader 故障后，余下的非 Observer 服务器都会将自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。
（2）每个Server会发出投票。
（3）接收来自各个服务器的投票，如果其他服务器的数据比自己的新会改投票。
（4）处理和统计投票，每一轮投票结束后都会统计投票，超过半数即可当选。
（5）改变服务器的状态，宣布当选。

（1）第一次投票，每台机器都会将票投给自己。
（2）接着每台机器都会将自己的投票发给其他机器，如果发现其他机器的zxid比自己大，那么就需要改投票重新投一次。比如server1 收到了三张票，发现server2的xzid为102，pk一下发现自己输了，后面果断改投票选server2为老大。