Zookeeper概念知识

课题：zk选举算法、ZAB原子广播协议如何实现的，CAS、Paxos

1、Zookeeper简介

        Zookeeper是一个高效的分布式协调服务，它暴露了一些公用服务，比如：命名/配置管理/同步控制/群组服务等。我们可以使用ZK来实现比如：达成共识/集群管理/Leader选举等。

        Zookeeper是一个高可用的分布式管理与协调框架，基于ZAB算法（原子消息广播协议）的实现。该框架能够很好的保证分布式环境中数据的一致性。也正是基于这样的特性，使得Zookeeper成为了解决分布式一致性问题的利器。

 

2、Zookeeper特点

        顺序一致性：从一个客户端发起的事物请求，最终将会严格的按照其发起的顺序被应用到Zookeeper中去。

        原子性：所有事物请求的处理结果在整个集群中所有机器上的应用情况是一致的。也就是说，要么整个集群所有的机器都成功应用了某一事物，要么都没有应用，一定不会出现部分机器应用了该事物，而另一部分没有应用的情况。

        单一视图：无论客户端连接的是哪一个Zookeeper服务器，其看到的服务器端数据模型都是一致的。

        可靠性：一旦服务器成功的应用了一个事物，并完成对客户端的响应，那么该事物所引起的服务器端状态将会被一直保留下来，除非有另一个事物对其更改。

        实时性：通常所说的实时性就是指一旦事物被成功应用，那么客户端就能立刻从服务器上获取变更后的新数据。Zookeeper仅仅能保证在一段时间内，客户端最终一定能从服务器端读取最新的数据（最终一致性）。

 

3、Zookeeper设计目标

        目标1：简单的数据结构。Zookeeper就是以简单的树形结构来进行相互协调的（也叫树形名字空间）。

        目标2：可以构建集群。一般Zookeeper集群通常由一组机器构成，一般3~5台机器就可以组成一个Zookeeper集群了。只要集群中超过半数以上的机器能够正常工作，那么整个集群就能够正常对外提供服务。

        目标3：顺序访问。对应来自每一个客户端的每一个请求，Zookeeper都会分配一个全局唯一的递增编号，这个编号反应了所有事物操作的先后顺序，应用程序可以使用Zookeeper的这个特性来实现更高层次的同步。

        目标4：高性能。由于Zookeeper将全量数据存储在内存中，并直接服务于所有的非事物请求，因此尤其是在读操作为主的场景下性能非常突出。在JMater压力测试下（100%读请求场景下），其结果大约在12~13w的QPS。

 

4、数据模型

        每个子目录项如NameService都被称作为znode，这个znode是被它所在的路径唯一标识，如Server1这个znode的标识为/NameService/Server1

        znode可以有子节点目录，并且每个znode可以存储数据，注意EPHEMERAL类型的目录节点不能有子节点目录。

        znode是有版本的，每个znode中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据。

        znode可以是临时节点，一旦创建这个znode的客户端与服务器失去联系，这个znode也将自动删除，Zookeeper的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为session，如果znode是临时节点，这个session失效，znode也就删除了。

        znode的目录名可以自动编号，如App1已经存在，再创建的话，将会自动命名为App2.

        znode可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是Zookeeper的核心特性，Zookeeper的很多功能都是基于这个特性实现的。

 

5、Zookeeper组成

        ZK server根据其身份特性分为三种：Leader，Follower，Observer。其中Follower和Observer又称Learner（学习者）。

        Leader：负责客户端的writer类型的请求，所有事物请求。

        Follower：负责客户端的reader类型的请求

        Observer：特殊的“Follower”，其可以接受客户端reader请求，但不参与选举，不响应提议，不将事物持久化到磁盘。（扩容系统支持能力，提高了读取速度、吞吐量）（如果ZooKeeper集群的读取负载很高，或者客户端多到跨机房，可以设置一些observer服务器，以提高读取的吞吐量。Observer和Follower比较相似，只有一些小区别：首先observer不属于法定人数，即不参加选举也不响应提议；其次是observer不需要将事务持久化到磁盘，一旦observer被重启，需要从leader重新同步整个名字空间。）

 

6、应用场景

        Zookeeper从设计模式角度来看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式。

        配置管理：配置的管理在分布式应用环境中很常见，比如我们在平常的应用系统中，经常会碰到这样的需求：如机器的配置列表、运行时的开关配置、数据库配置信息等。这些全局配置信息通常具备以下3个特性：①数据量比较小。②数据内容在运行时动态发生变化。③集群中各个集群共享信息，配置一致。

        集群管理：Zookeeper不仅能维护当前的集群中机器的服务状态，而且能够帮你选出一个“总管”，让这个总管来管理集群，这就是Zookeeper的另一个功能Leader，并实现集群容错功能。①：希望知道当前集群中究竟有多少机器工作。②对集群中每天集群的运行时状态进行数据收集。③对集群中每台集群进行上下线操作。

        发布与订阅：Zookeeper是一个典型的发布/订阅模式的分布式数控管理与协调框架，开发人员可以使用它来进行分布式数据的发布与订阅。

        数据库切换：比如我们初始化Zookeeper的时候读取节点上的数据库配置文件，当配置一旦发生变更时，Zookeeper就能帮助我们把变更的通知发生到各个客户端，每个客户端在接受到这个变更通知后，就可以重新进行最新数据的获取。

        分布式日志的收集：我们可以做一个日志系统收集集群中所有的日志信息，进行统一管理。

        分布式锁、队列管理等等

        开源框架应用：Hadoop、Storm、消息中间件、RPC服务框架、数据库增量订阅与消费组件（如 Mysql Binlog）、分布式数据库同步系统：淘宝的Otter等，

 

7、Zookeeper API

        Zookeeper的特性就是在分布式场景下高可用，但是原生的API实现分布式功能非常困难，团队去实现也太浪费时间，即使实现了也未必稳定。那么可用采用第三方的客户端的完美实现，比如Curator框架，它是Apache的顶级项目。

 

8、Watcher、ZK状态、事件类型

        Zookeeper有watch事件，是一次性触发的，当watch监视的数据发生变化时，通知设置了该watch的client，即watcher。

        同样，其watcher是监听数据发送了某些变化，那就一定会有对应的事件类型和状态类型。

        事件类型：（znode节点相关的）

                        EventType.NodeCreated

                        EventType.NodeDataChanged

                        EventType.NodeChildrenChanged

                        EventType.NodeDeleted

        状态类型：(和客户端实例相关)

                        KeeperState.Disconnected

                        KeeperState.SyncConnected

                        KeeperState.AuthFailed

                        KeeperState.Expired

 

9、watcher的特性

        一次性、客户端串行执行、轻量。

        一次性：对于ZK的watcher，你只需要记住一点：Zookeeper有watch事件，是一次性触发的，当watch监视的数据发生变化时，通知设置了该watch的client，即watcher，由于Zookeeper的监控都是一次性的，所以每次必须设置监控。

        客户端串行执行：客户端watcher回调的过程是一个串行同步的过程，这为我们保证了顺序，同时需要开发人员注意一点，千万不要因为一个watcher的处理逻辑影响了整个客户端的watcher回调。

        轻量：WatchedEvent是Zookeeper整个Watcher通知机制的最小通知单元，整个数据结构只包含三部分：通知状态、事件类型和节点路径。也就是说Watcher通知非常的简单，只会告诉客户端发生了事件而不会告知其具体内容，需要客户自己去进行获取，比如NodeDataChanged事件，Zookeeper只会通知客户端指定节点的数据发生了变更，而不会直接提供具体的数据内容。

 

10、ACL

        Zookeeper作为一个分布式协调框架，其内部存储的都是一些关乎分布式系统运行时状态的元数据，尤其是设计到一些分布式锁、Master选举和协调等应用场景。我们需要有效的保证Zookeeper中的数据安全，Zookeeper提供了三种模式。权限模式、授权模式、权限。

        权限模式的分类：IP、Digest、World、Super

        权限对象：指的是权限赋予的用户或者一个指定的实体，例如ip地址或机器等。在不同的模式下，授权对象是不同的。这种模式和权限对象一一对象。

        权限：权限就是指那些通过权限检测后可以被运行执行的操作，在ZK中，对数据的操作权限分为五大类：CREATE、DELETE、READ、WRITE、ADMIN

 

11、Curator场景应用

        分布式锁功能：在分布式场景中，我们为了保证数据的一致性，经常在程序运行的某一个点需要进行同步操作。使用Curator基于Zookeeper的特性提供的分布式锁来处理分布式场景的数据一致性。

        分布式计数器功能：针对jvm的场景，可能想到AtomicInteger。但是我们在分布式场景下，就需要利用Curator框架的DistributedAtomicInteger了。

 

12、ZAB协议（具体参考《从Paxos到Zookeeper》）

        ZAB协议的核心是定义了对于那些会改变ZooKeeper服务器数据状态的事物请求的处理方式：即：所有事物请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则成为Follower服务器。？Leader服务器负责将一个客户端事物请求转换成为一个事物Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求将前一个Proposal进行提交。

        ZAB协议的两种基本模式：崩溃恢复和消息广播。

        保证旧Leader已经提交的消息所有其他节点都提交，保证所有其他节点丢弃已经跳过的消息。

 

13、ZAB与Paxos算法的联系与区别

        具体参考《从Paxos到Zookeeper》4.2.4  P77

 

14、Leader选举算法（ZXID）

        具体参考《从Paxos到Zookeeper》4.2.4  P321

        ①每个Server会发出一个投票。

        ②接受来自各个服务器的投票。

        ③处理投票。

        ④统计投票。

        ⑤改变服务器状态。

 

15、Leader选举算法核心实现

         具体参考《从Paxos到Zookeeper》4.2.4  P332

        ①自增选举轮次

        ②初始化选票

        ③发送初始化选票

        ④接收外部投票

        ⑤判断选举轮次

        ⑥选票PK

        ⑦变更投票

        ⑧选票归档

        ⑨统计投票

        ⑩更新服务器状态