Zookeeper原理以及要点知识

Zookeeper

Zookeeper简述

Zookeeper是一个分布式服务框架，是Apache Hadoop 的一个子项目，它提供的是分布式协调服务。用来解决分布式应用中经常遇到的一些数据管理问题，比如统一命名服务、协调锁资源、状态同步服务、集群管理、分布式应用配置项的管理等。而Zookeeper实现这些功能的支撑其实是它类似于文件系统的数据模型和监听机制。

监听机制

客户端可以通过在它关心的目录节点上注册监听事件监听器(Watcher)，当目录节点发生相应的事件（数据改变、节点被删除、子目录节点增加删除）时，zookeeper会通知客户端并且进行信息同步。

zookeeper的常用操作如下:create–创建节点；delete–删除节点；exists–判断节点是否存在；getData–获得一个节点的数据；setData–设置一个节点的数据；getChildren–获取节点下的所有子节点。当客户端进行create、delete、setData等操作时可以通过设置watch参数进行watcher注册。

数据模型

Zookeeper的数据模型类似于文件系统，由一层层的目录组成，而每一个目录其实都是一个存储信息的节点，存储着状态/配置信息，Zookeeper的节点有着自己的独特名称—Znode，Znode除了存储信息还存储了子目录(节点)的指针，因此Znode的访问方式也与文件系统相同，采用的是路径引用，例如上图中我要访问SunAPP1这个节点则访问路径是/Apps/App3/SubApp1。这样的层级结构，让每一个Znode节点拥有唯一的路径，就像命名空间一样对不同信息作出清晰的隔离。

Znode类型

Znode分为四种类型，分别是持久节点 （PERSISTENT）、持久节点顺序节点（PERSISTENT_SEQUENTIAL）、临时节点（EPHEMERAL） 、临时顺序节点（EPHEMERAL_SEQUENTIAL） 。
(1)持久节点： 默认的节点类型。创建节点的客户端与zookeeper断开连接后，该节点依旧存在 。
(2)持久节点顺序节点: 与持久节点的区别就是在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号。
(3)临时节点: 和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除：
(4)临时顺序节点： 和临时顺序节点的区别就是创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号。客户端断开链接后还是会被删除。Zookeeper实现分布式锁就是使用的这种节点。

Znode节点内信息

Zookeeper是为读多写少的场景所设计，主要用来进行状态、配置管理的，因此Znode并不用来存储大规模业务数据，而是用于存储少量的状态和配置信息，每个节点的数据最大不能超过1MB。Znode包含访问权限、数据、子节点指针等信息。
(1)Data：Znode存储的数据信息。
(2)ACL：记录Znode的访问权限，即哪些人或哪些IP可以访问本节点。ZooKeeper定义了如下5种权限,CREATE: 创建子节点的权限。READ: 获取节点数据和子节点列表的权限。WRITE：更新节点数据的权限。DELETE: 删除子节点的权限。ADMIN: 设置节点ACL的权限。需要注意的是CREATE 和 DELETE 都是针对子节点的权限控制。
(3)Stat：包含Znode的各种元数据，比如事务ID、版本号、时间戳、大小等等。Stat中记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和aversion（当前ZNode的ACL版本）。
(4)Child：当前节点的子节点引用，类似于二叉树的左孩子右孩子。

会话(Session)

Session是指客户端会话，在ZooKeeper中，一个客户端连接是指客户端和ZooKeeper服务器之间的TCP长连接。ZooKeeper对外的服务端口默认是2181，客户端启动时，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳检测和服务器保持有效的会话，也能够向ZooKeeper服务器发送请求并接受响应，同时还能通过该连接接收来自服务器的Watch事件通知。Session的SessionTimeout值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在SessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

心跳检测: 这里的心跳检测指的是客户端每隔一定时间就会像服务器发送Ping请求，证明自己还活着，服务器端接收到客户端的请求后，会进行对应的客户端的会话激活，会话激活就会延长该会话的存活期。如果会话一直没有激活，那么说明该客户端挂掉了，服务器端的会话超时检测任务就会检查出那些一直没有被激活的与客户端的会话，然后进行清理，清理中有一步就是删除这些客户端创建的临时节点和临时有序节点。

事务操作

在ZooKeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。对应每一个事务请求，ZooKeeper都会为其分配一个全局唯一的事务ID，用ZXID表示，通常是一个64位的数字。每一个ZXID对应一次更新操作，从这些ZXID中可以间接地识别出ZooKeeper处理这些事务操作请求的全局顺序。

Zookeeper特性

(1)顺序一致性：从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到ZooKeeper中。
(2)原子性: 所有事务请求的结果在集群中所有机器上的应用情况是一致的，也就是说要么整个集群所有集群都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况。
(3)单一视图：无论客户端连接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的。
(4)可靠性：一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更。
(5)实时性:通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。这是因为Zookeeper放弃了CAP原则中的A，而满足了CP原则，Zookeeper为了保证数据的一致性，需要在集群各个节点机器上完成同步，再将数据返回。

Zookeeper集群介绍

Zookeeper为分布式应用提供协调服务，作为一个协调者每时每刻都可能需要进行协调，因此Zookeeper不能出现停止工作的时候，若Zookeeper位于单个机器上面，则可能会出现宕机情况，因此Zookeeper必须选择集群部署。而Zookeeper为了提供了数据的一致性和容错性，放弃了可用性，选择了CP原则。Zookeeper为了实现数据的一致性，必须先完成数据同步才能返回数据，而Zookeeper通过ZAB协议高效的完成了数据的同步并且完成了机器崩溃的修复，以此实现数据的一致性和容错性。Zookeeper集群采用的是一主多从的形式，一主也就是一个集群只有一个Leader节点，多从也就是集群有多个Follower、Observer服务器节点。只有Leader节点才能做写服务，因此数据同步其实就是从Leader节点同步到其他从节点；而当Leader节点崩溃时，就无节点能进行写服务以及协调从节点，因此Zookeeper服务基本不能使用，此时就需要有一定的机制进行恢复，ZAB协议提供了崩溃恢复和数据同步功能。

集群角色与状态

在ZooKeeper中，有三种角色：Leader、Observer、Follower，一个ZooKeeper集群同一时刻只会有一个Leader，其他都是Follower或Observer；ZooKeeper默认只有Leader和Follower两种角色，没有Observer角色，若想添加Observer角色需要修改服务器节点的相关配置。Leader服务器为客户端提供读和写服务。Follower和Observer都能提供读服务，不能提供写服务。两者唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的『过半写成功』策略，因此Observer可以在不影响写性能的情况下提升集群的读性能。

正常状态下，不同节点有着各自的状态，Leader节点状态为Leading，Observer节点状态为Observering，follow节点状态为following，当Leader节点崩溃后，集群进入选举状态，此时除了不参与选举的Observer节点，其它节点状态都为为Locking。

ZAB协议

Zookeeper使用了一种称为ZooKeeper Atomic Broadcast（ZAB，ZooKeeper原子广播协议）的协议作为其数据一致性的核心算法。它是一种特别为ZooKeeper设计的崩溃可恢复的原子广播算法。ZAB协议包括两种基本的模式，分别是崩溃恢复和消息广播。在整个ZooKeeper集群启动过程中，或是当Leader服务器节点出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进入恢复模式并选举产生新的Leader服务器节点。当选举产生了新的Leader服务器节点，同时集群中有过半的机器与该Leader服务器完成了数据同步之后，ZAB协议就会退出恢复模式进入消息广播模式。消息广播模式指的是Zookeeper在正常状态下通过广播的方式实现数据同步，采用的是二阶段提交的方式。

崩溃修复

ZAB的崩溃恢复分成三个阶段：选举、发现、同步阶段。
1.Leader election(选举)
选举阶段，此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票，投票当中包含自己的服务器ID和最新事务ID（ZXID）。接下来，节点会用自身的ZXID和从其他节点接收到的ZXID做比较，如果发现别人家的ZXID比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的ZXID所属节点。每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。

2.Discovery(发现阶段)
发现阶段，用于在从节点中发现最新的ZXID和事务日志。或许有人会问：既然Leader被选为主节点，已经是集群里数据最新的了，为什么还要从节点中寻找最新事务呢？这是为了防止某些意外情况，比如因网络原因在上一阶段产生多个Leader的情况。所以这一阶段，Leader集思广益，接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch，基于此值加1，生成新的epoch分发给各个Follower。各个Follower收到全新的epoch后，返回ACK给Leader，带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID，并更新自身历史日志。(epoch为纪元，可以理解为投票的轮次)

3.Synchronization(同步阶段)
同步阶段，把Leader刚才收集得到的最新历史事务日志，同步给集群中所有的Follower。只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。

消息广播

1、所有写事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，因此客户端发出写入数据请求给任意Follower，Follower都会把写入数据请求转发给Leader。

2、Leader采用二阶段提交方式，先发送Propose(提案)广播给Follower。

3.Follower接到Propose消息，写入日志成功后，返回ACK消息给Leader。

4.Leader接到半数以上ACK消息，返回成功给客户端，并且广播Commit请求给Follower，让Follower节点提交事务。

参考:
https://www.jianshu.com/p/84ad63127cd1
https://mp.weixin.qq.com/s/Gs4rrF8wwRzF6EvyrF_o4A
https://my.oschina.net/u/3796575/blog/1845035