zookeeper基本概念

什么是zookeeper

zookeeper是apache hadoop下的一个开源分布式协调框架，主要用来解决分布式应用中遇到的一些数据管理问题，例如：统一命名服务、状态同步服务、集群管理、分布式应用配置项管理，我们可以简单的认为zookeeper就是一个基于内存的可以存储少量数据的数据库，核心概念就是文件系统数据结构和监听通知机制

文件系统数据结构

zookeeper使用一个类似文件系统的树形数据结构维护存储的数据，每个子目录项叫做znode(目录节点)，我们可以随意的删除增加znode，并在znode下面增加删除子znode，不同点在于znode可以存储数据，znode存储的数据是有版本的，zookeeper内部定义了以下几种znode类型

1、PERSISTENT-持久化目录节点：
即使客户端与zookeeper连接断开，节点依然存在，必须主动删除
2、 PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
创建时会被按照顺序进行编号的持久化目录节点
3、EPHEMERAL-临时目录节点
客户端与zookeeper连接断开，session超时后，删除该节点，session是客户端和服务器之间的TCP长连接，每个客户端连接服务器时都会被分配一个唯一的sessionId，session有超时时间，即使客户端连接断开，只要在超时时间内，客户端能重新连接到zookeeper集群，那session就会延长保活
4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
带编号的临时目录节点
5、Container节点-容器节点
如果container节点下面没有字节点，会被zookeeper删除，默认每60S检查一次
6、TTL节点
带超时时间的节点，超时被删除

监听通知机制

客户端注册监听它关心的任意节点或者目录节点及递归子目录节点
1、如果注册的是对某个节点的监听，当节点被删除或者节点数据被修改时，注册监听的客户端将被通知
2、如果注册的是对某个目录的监听，当目录有子节点被创建，或者有子节的被删除，注册监听的客户端将被通知
3、如果注册的是对某个目录的递归子节点监听，当这个目录下的任意子节点有变化或者根目录节点有变化时，注册监听的客户端将被通知
通知都是一次性的，触发之后不会被再次触发

zookeeper最常用的场景

分布式配置中心
分布式注册中心
分布式锁
分布式队列
集群选举
分布式屏障
发布/订阅

zookeeper的ACL控制

zookeeper的权限控制分布三个部分：权限模式、授权对象、权限信息
权限模式分为范围验证(IP地址或IP地址段)和口令验证(用户名密码) 授权对象指的就是IP段或者用户名
权限信息指可执行的操作种类，分为c(创建)、w(更新)、r(读取)、d(删除)、a(管理员)
可以通过系统参数zookeeper.skipACL=yes进行配置，默认是no,可以配置为true, 则配置过的 ACL将不再进行权限检测

zookeeper内存数据持久化机制

事务日志

zookeeper是基于内存存储数据的，zookeeper会将每次客户端的事务操作(客户端对节点的增删改都是事务的)记录到磁盘上的事务日志中，存放目录为配置文件中的dataLogDir(如果没有配置则存放在dataDir目录下)，为了提升磁盘IO的性能，zookeeper在创建事务日志文件的时候就进行文件空间的预分配，即在创建文件时就预申请一块磁盘块
事务日志文件名：log.<当时最大事务ID>，当时最大事务ID也是整个事务日志文件中最小的事务ID

数据快照

数据快照会记录zookeeper服务器上某一个时刻的全量数据，并写入本地磁盘，快照文件名：snapshot.<当时最大事务ID>，数据快照的目的是为了恢复数据时更快

zookeeper集群

zookeeper集群跟传统的master/slave模式有所区别，zookeeper集群里的节点分为三个角色
Leader：基于ZAB协议选举出来的主节点，处理读写请求，集群中只会有一台leader
Fllower：Leader的候选节点，处理读请求，可以参与选举
Observer：和Fllower一样处理读请求，不参与选举

过半写机制：向Leader写数据时，只有Leader+Fllower节点写成功的个数超过一半才算真正的写成功

zookeeper选举算法

zookeeper在两种情况下会开启leader选举：
（1）集群服务器启动
（2）leader和集群连接断开

选举流程：
首先所有机器都向集群中的其他机器投出一张选择自己为leader的选票(myid, ZXID)，集群启动时所有选票的ZXID都是0，服务器收到投票后和自己的选票进行比较，优先选择ZXID最大的选票，如果ZXID相同，那么就比较myid，myid较大的服务器作为leader，然后更新选票重新投票，每次投票后服务器都会统计是否已经有过半机器收到了相同的投票，如果有就选出了leader，服务器从LOOKING变为FOLLOWING或LEADING

leader选举底层分为选举处理和投票传输接收两部分，投票传输部分按照每个机器划分投票队列避免给网络问题机器投票时影响其他机器

保证数据一致性的ZAB协议

ZAB全称zookeeper原子消息广播协议，ZAB的核心是整个zookeeper集群由一个唯一的节点即Leader处理客户端的写请求，Leader将写请求转换成一个事务Proposal，并分发给集群中的其他Follower节点，只有超过半数的Follower节点写入本地磁盘成功并返回ACK，Leader才会再次向所有Follower节点发送Commit消息，提交之前发送的Proposal，ZAB协议主要有两种模式：消息广播和崩溃恢复

消息广播：
zookeeper节点之间数据同步采用消息广播方式，Leader会将客户端每个写操作请求转换成事务Proposal，并为该事务分配一个全局单调递增的事务ID(ZXID)，然后将事务Proposal发送至每个Follower节点对应的队列中，Follower节点接收事务Proposal后写入本地事务日志并反馈ACK给Leader，Leader接收过半数的ACK后广播Commit消息提交事务Proposal同时完成本地事务提交标志写入数据成功，需要注意的是leader自己也会将proposal写入本地事务日志并给自己发送一个ACK，因此leader自己也包含在过半ACK的节点列表中

崩溃恢复： zookeeper只有Leader节点能处理写请求，如果Leader节点宕机，zookeeper集群将进入崩溃恢复重新选举Leader并进行数据同步，ZAB协议崩溃恢复有两个要求：
1、确保leader已提交的propoasl必须被所有的follower提交
2、确保丢弃没有被提交的proposal
根据以上要求，leader必须是已提交所有proposal并且ZXIDz最大的节点，leader选举成功后，将自身提交的最大的ZXID发送给其他的follower节点完成数据同步

ZAB协议的四个阶段：
1、选举：选举准leader的阶段，得到超过半数的选票的节点会成为准leader节点并在同步后成为leader节点
2、发现：此阶段leader和其他follower节点进行通信
3、同步：此节点leader和follower节点同步最新的proposal，半数follower节点同步完成后，准leader节点正式成为leader
4、广播：此阶段zookeeper开始处理请求，leader广播开始消息

消息广播模型

集群脑裂问题

什么是脑裂？
假设有三台Zookeeper组成集群，分别是A、B、C，选举后A成为Leader，B和C成为Follower，突然A和B、C失去连接，B、C重新选举，B成为Leader，此时集群内出现了两个Leader都对外提供服务，这种情况称之为脑裂

zookeeper如何应对脑裂？
zookeeper通过ZAB协议解决脑裂问题，首先ZAB协议限制了A在处理写入时只能写入本地日志文件，不能写入内存，避免了数据不一致问题，然后A在一段时间后失去和B、C的连接重新进行选举，由于ZAB协议限制无法成为Leader，只能成为Follower，重新和B、C建立连接后，A需要从B同步数据，此时B的选举周期比A大，A依然是Follower，丢弃本地日志文件的数据，同步最新的数据