zookeeper

一、What

一个主从架构的分布式框架
给分布式框架提供协调服务（service）

作用

提供简版文件系统来存储数据
维护和监控存储的数据状态变化，通过监控数据状态变化达到基于数据的集群管理
主要用来解决分布式集群中应用系统的一致性问题

应用场景

1. 主备切换
2. 节点的上下线感知
3. 统一命名服务
4. 状态同步服务
5. 集群管理
6. 分布式应用配置管理

二、基本概念

ZooKeeper=简版文件系统(Znode)+原语+通知机制(Watcher)

ZK文件系统
基于类似于文件系统的目录节点树方式的数据存储
原语
提供类linux指令进行操作
Watcher（监听器）

数据节点ZNode

数据节点本质就是目录

	持久节点	临时节点
非有序节点	create	create -e
有序节点	create -s	create -s -e

持久节点（无序）
节点创建以后，即便连接断开，除非主动删除，不然会一直存在
持久节点（有序）
创建节点的时候加上 -s ，会默认的在目录后加上数字
防止同一目录创建同名ZNode导致失败
临时节点（无序）
节点创建以后，一旦连接断开会自动删除
创建节点的时候通过 -t 指定
持久节点（有序）
同上

会话

与zk交互时会建立TCP长连接，称为会话
建立会话后，如果超过SessionTimeout时间，两者间没有通信，会话超时
特点：同一个会话里执行的指令是有序的；不同会话之间的指令是无序的

事务zxid

每个对数据的增删改操作都会生成一个对应的zxid
zxid全局唯一，并且是自增的
zxid通常是由64位数字，epoch+counter组成

Watch监视与通知

方式一（轮询）：ZooKeeper以远程服务的方式，被客户端访问；客户端以轮询的方式获得znode数据，效率会比较低（代价比较大）

方式二（通知机制）：客户端在znode上注册一个Watcher监视器，当znode上数据出现变化，watcher监测到此变化，通知客户端

Watch作用流程

客户端在服务器端，注册的事件监听器
watcher用于监听znode上的某些事件
比如znode数据修改、节点增删等
当监听到事件后，watcher会触发通知客户端

节点上下线原理
① 节点1（client1）创建临时节点
② 节点2（client2）在临时节点，注册监听器watcher
③ 当client1与zk集群断开连接，临时节点会被删除
④ watcher发送消息，通知client2，临时节点被删除的事件
用到的zk特性：Watcher+临时节点
好处：通过这种方式，检测和被检测系统不需要直接关联（如client1与client2），而是通过ZK上的某个节点进行关联，大大减少了系统耦合。

三、HDFS HA方案

工作原理

ZooKeeper使用原子广播协议叫做Zab(ZooKeeper Automic Broadcast)协议

Zab协议有两种模式
- 恢复模式（选主）：因为ZooKeeper是主从架构；当ZooKeeper集群没有主的角色leader时，从众多服务器中选举leader时，处于此模式
- 广播模式（同步）：当集群有了leader后，客户端向ZooKeeper集群读写数据时，集群处于此模式
为了保证事务的顺序一致性，ZooKeeper采用了递增的事务id号（zxid）来标识事务，所有提议（proposal）都有zxid

监听器

注册：客户端向ZooKeeper集群注册监听器
监听事件：监听器负责监听特定的事件
回调函数：当监听器监听到事件的发生后，调用注册监听器时定义的回调函数

HA原理

HDFS HA方案，主要分两部分：

①元数据同步

在同一个HDFS集群，运行两个互为主备的NameNode节点。
一台为主Namenode节点，处于Active状态，一台为备NameNode节点，处于Standby状态。
只有Active NameNode对外提供读写服务，Standby NameNode会根据Active NameNode的状态变化，在必要时切换成Active状态。
JournalNode集群
- 在主备切换过程中，新的Active NameNode必须确保与原Active NamNode元数据同步完成，才能对外提供服务
- 所以用JournalNode集群作为共享存储系统；
- 当客户端对HDFS做操作，会在Active NameNode中edits.log文件中作日志记录，同时日志记录也会写入JournalNode集群；负责存储HDFS新产生的元数据
- 当有新数据写入JournalNode集群时，Standby NameNode能监听到此情况，将新数据同步过来
- Active NameNode(写入)和Standby NameNode(读取)实现元数据同步
- 另外，所有datanode会向两个主备namenode做block report

②主备切换

每个NameNode节点上各有一个ZKFC进程
ZKFC即ZKFailoverController，作为独立进程存在，负责控制NameNode的主备切换
ZKFC会监控NameNode的健康状况，当发现Active NameNode异常时，通过Zookeeper集群进行namenode主备选举，完成Active和Standby状态的切换
- ZKFC在启动时，同时会初始化HealthMonitor和ActiveStandbyElector服务
- ZKFC同时会向HealthMonitor和ActiveStandbyElector注册相应的回调方法（如上图的①回调、②回调）
- HealthMonitor定时调用NameNode的HAServiceProtocol RPC接口(monitorHealth和getServiceStatus)，监控NameNode的健康状态，并向ZKFC反馈
- ActiveStandbyElector接收ZKFC的选举请求，通过Zookeeper自动完成namenode主备选举
- 选举完成后回调ZKFC的主备切换方法对NameNode进行Active和Standby状态的切换

主备切换过程

① 启动NameNode，ZKFC，此时两个NameNode的状态都是竞选状态
② 两个ZKFC分别通过ActiveStandbyElector发起NameNode的选举
   通过zookeeper的写一致性以及临时节点来实现
③ 发起主备选举的时候，ActiveStandbyElector会尝试在zookeeper的某个目录下创建一个临时节点，zookeeper的写一致性会保证只有一个节点创建成功
④ 创建成功的ActiveStandbyElector通过回调方式通知ZKFC，将对应的NameNode切换为Active状态；创建失败的也通过同样方式将NameNode切换为Standby状态
⑤ 无论是否创建成功，这些ActiveStandbyElector都会监听那个目录；
  当Active NameNode对应的HealthMonitor监控到NameNode异常时，会告知ZKFC
  ZKFC通过ActiveStandbyElector删除所创建的临时节点，以及目录A
  若是ZKFC是因为异常断开的连接，那么目录A还会存在
⑥ 此时处于Standby的NameNode会监控到这个消息
  它首先会通过判断目录A是否存在来确认情况
  如果是正常关闭的，则发起主备选举，成功创建临时节点，并且将NameNode的状态切换为Active
  如果是异常关闭的，则会
  (1) 通过RPC调用，试图让之前的Active的NameNode切换为StandBy 
  (2) 隔离：① 发送kill指令    ② 使用hadoop的隔离方式

脑裂
在分布式系统中双主现象又称为脑裂，由于Zookeeper的“假死”、长时间的垃圾回收或其它原因都可能导致双Active NameNode现象，此时两个NameNode都可以对外提供服务，无法保证数据一致性

隔离
对于生产环境，这种情况的出现是毁灭性的，必须通过自带的隔离（Fencing）机制预防此类情况
原理
- ActiveStandbyElector成功创建ActiveStandbyElectorLock临时节点后，额外创建一个ActiveBreadCrumb持久节点
- ActiveBreadCurmb持久节点保存Active NameNode的服务器信息
- 当Active NameNode正常状态下断开与Zookeeper Session，会一并删除临时节点ActiveStandbyElectorLock和ActiveBreadCurmb持久节点
- 如果是异常断开的，那么此时临时节点ActiveStandbyElectorLock不存在，但是ActiveBreadCurmb持久节点还存在；Standby节点会收到监听器发来的提醒将要从Standby切换成Active时，会先通过ActiveBreadCurmb里的服务器信息做隔离

1、通过RPC调用，试图让之前的Active的NameNode切换为StandBy
2、隔离（hadoop提供这两种隔离）：① 发送kill指令 ② 使用hadoop的隔离方式

只有成功地fencing之后，选主成功的ActiveStandbyElector才会回调ZKFC的becomeActive方法transitionToActive将对应的NameNode切换为Active，开始对外提供服务

四、Zookeeper架构

ZooKeeper服务器四种状态：

looking：服务器处于寻找Leader群首的状态
leading：服务器作为群首时的状态
following：服务器作为follower跟随者时的状态
observing：服务器作为观察者时的状态

安其内

全新leader选举（重启集群）
原则：集群超过半数的服务器启动后，才能选出leader
选举规则：

1. 初始化：每个节点都投自己一票，然后向其他所有节点发送自己票的信息
2. 交换投票信息：接收其他节点的选举信息，与自己的那票进行比较
   投票信息vote信息结构为(serverId, zxid)
   会先比较zxid，zxid大的那台服务器胜出（zxid越大意味存储了更多的数据）
   若是zxid相同则serverId大的那台服务器会胜出
   比较结束后，每台服务器会更新自己的投票信息，继续给其他服务器发送
3. 决定投票结果：假设服务器B接收到超过半数的票选举自己，则自己从looking切换为leading，其他服务器从looking切换为following
4. 当服务器C启动时，发现已有Leader，不再选举，直接从Looking改为Following

全新leader选举（leading挂掉或者出现网络分区）

攘其外

读操作

常见的读取操作，如ls /查看目录；get /zktest查询ZNode数据
读操作
- 客户端先与某个zk任意一台服务器建立Session
- 然后，直接从此ZK服务器读取数据，并返回客户端即可
- 关闭Session

写操作

① 与zk任意一台服务器建立Session建立连接
② follower将写请求转发给leader（不执行）
③ leader收到消息后，发起proposal提案
④ 每台服务器都会收到proposal后会记录这次操作并向leader返回同意，但不执行
⑤ 超过半数quorum同意，则leader提交commit提案，leader执行该操作
⑥ leader通知所有节点也commit提交该提案；所有节点在所在服务器执行该操作
⑦ client连接的那台follower响应Client

五、原理

quorum仲裁

什么是仲裁quorum？
- 发起proposal时，只要多数派同意，即可生效
为什么要仲裁？
- 多数据派不需要所有的服务器都响应，proposal就能生效
- 提高集群的响应速度
quorum数如何选择？
- 集群节点数 / 2 + 1

为什么集群节点数强烈建议奇数个？
5节点的比6节点的集群

容灾能力一样，
quorum小，响应快
偶数个如果被网络分区平分，则不能提供服务

网络分区和脑裂

网络分区：网络通信故障，集群被分成了2部分
脑裂：
- 原leader处于一个分区；
- 另外一个分区选举出新的leader
- 集群出现2个leader

ZAB算法

每个节点都有一个计时器（150毫秒~300毫秒之间的随机数），时间到后会发起选举的操作
非leader节点会定时的向leader节点发送心跳，leader收到心跳后会返回信息，非leader节点收到这个信息后会重置计时器
当发生网络分区并且leader处于少数的那边时，其他follower会进行选举，假设B服务器选举成功，那么它会和其他follower进行zxid的比较
① 假设服务器C的zkid比服务器B的少10个，那么服务器B会将这十个操作封包发给服务器C来执行
② 假设服务器D的zxid比服务器B多10个，那么服务器B会让它将这十个记录都删除
做完以上操作后，服务器B才会从follower切换成leader，并且将epoch里的值进行加1，zxid进行重置
当网络恢复了之后，旧leader比较路径下的epoch值的时候，发现已经有新的leader产生，会将自己切换成follower，并且进行数据的同步

状态同步

完成选举后，zk之间会进行状态同步操作

leader构建NEWLEADER封包，包含leader最大zxid值，广播给其他follower
follower收到后会跟自己最大zxid比较，若是比它小则进行同步操作
leader给每个需要同步的follower创建LearnerHandler同步线程，负责进行同步操作
leader主线程等待LearnerHandler线程处理结果
只有当大部分follower完成同步，该集群才对外提供服务，相应写请求
LearnerHandler线程处理逻辑
1. 接收follower封包FOLLOWERINFO，包含此follower最大zxid（代称f-max-zxid）
2. f-max-zxid与leader最大zxid（代称l-max-zxid）比较
3. 若相等，说明当前follower是最新的
4. 另外，若在判断期间，有没有新提交的proposal
  1. 如果有，那么会发送DIFF封包将有差异的数据同步过去.同时将follower没有的数据逐个发送COMMIT封包给follower要求记录下来.
  2. 如果follower数据id更大,那么会发送TRUNC封包告知截除多余数据.
  3. 如果这一阶段内没有提交的提议值,直接发送SNAP封包将快照同步发送给follower.
5. 以上消息完毕之后,发送UPTODATE封包告知follower当前数据就是最新的了
6. 再次发送NEWLEADER封包宣称自己是leader,等待follower的响应.

分布式锁

所有需要获取锁的引用都在 /locker路径下创建一个有序临时节点
该路径下序号最小的应用获取该锁，其他应用分别监视比自己小一点的那个ZNode
当序号最小的那个应用操作完后，断开连接时，比它稍微大一点的那个应用会获取锁

分布式锁主要是应用了zk的一致性、临时节点、watch监视器这几个特性来保证的

WHO

NameNode使用ZooKeeper实现高可用.
Yarn ResourceManager使用ZooKeeper实现高可用.
利用ZooKeeper对HBase集群做高可用配置
kafka使用ZooKeeper(仅限0.9以及之前版本)
- 保存消息消费信息比如offset.
- 用于检测崩溃
- 主题topic发现
- 保持主题的生产和消费状态