第1章 分布式应用协调 第2节Zookeeper核心功能和应用场景

第一章 分布式应用协调

第二节 Zookeeper核心功能和应用场景

1.2.1 Zookeeper入门

1. 什么是Zookeeper

1）Zookeeper介绍

• 简介：Apache Zookeeper是一种用于分布式应用程序的高性能协调服务，提供一种集中式信息存储服务。
• 特点：数据存在内存中，类似文件系统的树形结构（文件和目录），高吞吐量和低延迟，集群高可靠。
• 作用：基于Zookeeper可以实现分布式统一配置中心、服务注册中心，分布式锁等功能。
• 官网：https://zookeeper.apache.org
  

2）何为分布式协调服务？

• 单机系统因处理能力上限、可用性、可靠性的考虑，变成分布式系统。
• 原来在单机进程中完成的一件事的多个步骤，变为在多个计算机中完成。这时就需要协调各个计算节点做事的顺序；原来在单系统中资源竞争通过锁进行同步控制，现在变成了多个计算机上的进程间的资源竞争，也需要分布式协调。
• 我们可以把每个分布式系统中需要的协调管理的公共基础部分抽取出来作为一个基础公共服务供大家使用，这就是分布式协调服务。

3）zookeeper的应用案例

• HBase：使用Zookeeper进行Master选举、服务间协调。
• Solr：使用Zookeeper进行集群管理、Leader选举、配置管理。
• Dubbo：服务注册。
• Mycat：集群管理、配置管理
• Sharding-sphere：集群管理、配置管理

4）Zookeeper同类产品

• consul：服务发现和配置共享
• etcd：轻量级Zookeeper
• Doozer：高可用的完整一致性的用于小量且重要的存储

2. 单机版安装

• 下载：https://archive.apache.org/dist/zookeeper/zookeeper-3.5.5/apache-zookeeper-3.5.5.tar.gz
• 可以在 https://archive.apache.org/dist/zookeeper/ 查看所有版本的Zookeeper
• 解压后的conf目录，增加配置文件zoo.cfg
• 启动服务端 bin/zkServer.sh start
• 测试，客户端连接：bin/zkCli.sh -server 127.0.0.1:2181

3. 客户端CLI-操作指令

• [zk:localhost:2181(CONNECTED)17] help
• 部分命令介绍：

4. Java API

• org.apache.zookeeper
• org.apache.zookeeper.data
• 创建客户端的核心类：Zookeeper
• 平时应用时一般很少使用Zookeeper的jar包，因为太偏于底层。
  

5. 第三方客户端

• 由于Zookeeper官方的jar包太过于底层，所以平时开发时可选用第三方的客户端。
• zkclient

<dependency>
    <groupId>com.101tecgroupId>
    <artifactId>zkclientartifactId>
    <version>0.11version>
dependency>

• Curator也是一种流行的第三方客户端

1.2.2 Zookeeper核心概念

1. session会话

• 一个客户端连接一个会话，由zk分配唯一会话id；
• 客户以特定的时间间隔发送心跳以保持会话有效；tickTime
• 超过会话超时时间未收到客户端的心跳，则判定客户端死了；（默认2倍tickTime）
• 会话中的请求按FIFO顺序执行。

2. 数据模型

1）层次名称空间

• 类似Unix文件系统，以(/)为根
• 区别：节点可以包含与之关联的数据以及子节点（既是文件也是文件夹）
• 节点的路径总是表示为规范的、绝对的、斜杠分隔的路径

2）znode

• 名称唯一，命名规范
• 节点类型：持久、顺序、临时、临时顺序
• 节点数据构成

3）znode - 命名规范

• 节点名称除下列限制外，可以使用任何unicode字符。
• null字符(\u0000)不能作为路径名的一部分；
• 以下字符不能使用，因为他们不能很好地显示，或者以令人困惑的方式呈现：\u0001~\u0019 和 \u007F~\u009F
• 不允许使用以下字符：\uD800~\uF8FF,\uFFF0~\uFFFF。
• “.”字符可以用作另一个名称的一部分，但是“.”和“…”不能单独用于指示路径上的节点，因为Zookeeper不使用相对路径。
  • 下列内容无效：“/a/b/./c”或“c/a/b/…/”
  • 可以用“/a/b.i/c”或“/a/b.i.j/d”,此时b.i是节点名
• “Zookeeper” 是保留节点名。

4）znode - 节点类型

i. 持久节点

create /app1 111

ii. 临时节点

• 会话结束时将被删除节点

create -e /app2 222

iii. 顺序节点

• 生成cp0000000000

create -s /app1/cp 888

• 生成0000000001

create -s /app1/ aa 

• 10位十进制序号
• 每个父节点一个计数器
• 计数器是带符号int（4字节）到2147483647之后将溢出（导致名称 “ -2147483648”）

iv. 临时顺序节点

create -e -s /app1/ 222

5）znode - 数据构成

• 节点数据：存储的协调数据（状态信息、配置、位置信息等）
• 节点元数据（stat结构）
• 数据量上限：1M
  

i. 元数据stat结构

[zkshell:12]get /app1
my_data
cZxid=5 #事务id，由哪个事务创建的
ctime=Fri Jun 05 13:57:06 PDT 2009
mZxid=5
mtime=Fri Jun 05 13:57:06 PDT 2009
pZxid=5
cversion=0
dataVersion=0
aclVersion=0
ephemeralOwner=0
dataLength=7
numChildren=0

3. Zookeeper中的时间

• Zookeeper使用多种方式跟踪时间
• Zxid：Zookeeper中的每次更改操作都对应一个唯一的事务id，称为Zxid，它是一个全局有序的戳记，如果zxid1小于zxid2，则zxid1发生在zxid2之前。
• Version numbers：版本号，对节点的每次更改都会导致该节点的版本号之一增加。
• Ticks：当使用多服务器Zookeeper时，服务器使用“滴答”来定义事件的时间，如状态上传、会话超时、对等点之间的连接超时等。滴答时间仅通过最小会话超时（滴答时间的2倍）间接公开；如果客户端请求的会话超时小于最小会话超时，服务器将告诉客户端会话超时实际上是最小会话超时。
  Real Time：Zookeeper除了在znode创建和修改时将时间戳放入stat结构之外，根本不使用Real Time 或时钟时间。

4. Watch监听机制

• 客户端可以在znodes上设置watch，监听znode的变化。
• 例如监听节点的子节点变化，节点的信息变化等，都会通过watch提醒客户端，关注的znode发生了变化。
• 命令行方式
  
• Java API
  

1）两类watch

• data watch监听数据变更
• child watch监听子节点变化

2）触发watch事件

• Created event:Enable with a call to exists.
• Deleted event:Enable with a call to exists,getData and getChildren.
• Changed event:Enable with a call to exists and getData.
• Child event:Enable with a call to getChildren.

3）Watch重要特性

• 一次性触发：watch触发后即被删除，要持续监控变化，则需要持续设置watch。
• 有序性：客户端先得到watch通知后，才会看到变化结果。

4）Watch注意事项

• watch是一次性触发器；如果获得了一个watch事件，并且希望得到关于未来更改的通知，则必须设置另一个watch。
• 因为watch是一次性触发器,并且在获取事件和发送获取watch的新请求之间存在延迟，所以不能可靠的得到节点发生的每个更改。
• 一个watch对象只会被特定的通知触发一次。如果一个watch对象同时注册了exists、getData，当节点被删除时，删除事件对exists、getData都有效，但只会调用watch一次。

5. Zookeeper特性

1. 顺序一致性(Sequential Consistency)：保证客户端操作是按顺序生效的。
2. 原子性(Atomicity)：更新成功或失败，没有部分结果。
3. 单个系统映像：无论连接到哪个服务器，客户端都将看到相同的内容。
4. 可靠性：数据的变更不会丢失，除非被客户端覆盖修改。
5. 及时性：保证系统的客户端当时读到的数据是最新的。

1.2.3 Zookeeper典型应用场景

• 数据发布订阅（配置中心）
• 命名服务
• Master选举
• 集群管理
• 分布式队列
• 分布式锁

1. Zookeeper实现配置中心

• 何为配置中心？
  

分布式系统的各个服务或多或少需要相关配置，当服务众多时，参数配置或动态改参将很麻烦，于是引入了配置中心。所有服务从配置中心获取参数。

• 用Zookeeper实现配置中心
  • znode能存储数据
  • Watch能监听数据改变
• 如何将配置放到配置中心？
  • 一个配置项一个znode
  • 一个配置文件一个znode

2. Zookeeper实现命名服务

• 何为命名服务？
  
• 服务A已完成，需要调用服务B（未完成），为了不用后期改服务的地址，使用命名服务。
• 服务A注册一个watch观察ServiceB节点，通过Zookeeper取到服务B的相关信息
• 服务B完成后需要向Zookeeper注册（创建）节点，把地址信息放入该节点。

3. Zookeeper实现Master选举

• 何为Master选举？
  

为保证集群的高可用性，在Master节点挂掉后需要从集群中选举出新的Master节点继续工作。

• Zookeeper如何来实现Master选举？

4. Zookeeper实现分布式队列

• 分布式队列分为有界队列和无界队列
• 使用无界队列没有注意事项
• 使用有界队列要特别注意要使用分布式锁，因为当队列将满时，多个生产者检测到队列未满，都创建节点，这将导致队列超界。

5. Zookeeper实现分布式锁

• 常用的分布式锁实现方式：Zookeeper、Redis
• 下面介绍两种Zookeeper的实现方式

1）方式一

• 原理：节点不可重名 + watch
• 缺点：惊群效应（每次释放锁唤醒一大堆阻塞的线程）
• 适用于并发数量小的场景，因为惊群效应造成大量的并发可能导致Zookeeper挂掉。

2）方式二

• 原理：取号 + 最小号获得锁 + watch
• 优点：没有惊群效应
  
  

1.2.4 Zookeeper集群

• 可靠的Zookeeper服务
• 只要集群的大多数都准备好了，就可以使用这项服务
• 容错集群设置至少需要三个服务器，强烈建议使用奇数个服务器
• 建议每个服务运行在单独的机器上

1. Zookeeper集群搭建

• 在Zookeeper的配置中添加后面几行

tickTime=2000
dataDir=/var/lib/zookeeper/
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888

• initLimit
  集群中的follower服务器(F)与leader服务器(L)之间完成初始化同步连接时能容忍的最多心跳数（tickTime的数量）。如果zk集群环境数量确实很大，同步数据的时间会变长，因此这种情况下可以适当调大该参数。

• syncLimit
  集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数（tickTime的数量）。

• 集群节点
  server.id=host:port:port
  id：通过在各自的dataDir目录下创建一个名为myid的文件来为每台机器赋予一个服务器id。
  两个端口号：第一个跟随者用来连接到领导者，第二个用来选举领导者。

• 创建myid文件

  • 一行只包含机器id的文本
  • id在集成中必须是唯一的，其值应该在1到255之间。如服务器1的id为“1”

2. 连接Zookeeper集群

• 集群的所有节点都可以提供服务，客户端连接时，连接串中可以指定多个或全部集群节点的连接地址。当一个节点不通时，客户端将自动切换另一个节点。

"10.168.1.23:2181,10.168.1.24:2181,10.168.1.25:2181"

3. Zookeeper集群监控

• 四字监控命令
• JMX
• 说明文档:http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_monitoring
• 四字命令:http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_zkCommands
• JMX:http://zookeeper.apache.org/doc/current/zookeeperJMX.html

4. ZAB协议

1）ZAB介绍

• 作为重要的分布式协调服务，如何保证集群数据的一致性？
• 所有server节点读取数据一致，但是对于写请求，每个server均可接受写请求但不执行，直接转发到Leader节点，由Leader节点执行写操作。
• ZAB协议(ZooKeeper Atomic Broadcast,ZooKeeper原子消息广播协议)是专为zookeeper设计的数据一致性协议。

• 读请求直接从每个节点的备份数据库读取，但是写请求必须通过Leader节点执行操作并原子广播到备份数据库。

2）ZAB协议过程说明

• ZAB协议重要特性：有序性

1. 所有事物请求转发给Leader（动作1&2）
2. Leader分配全局单调递增事务id(Zxid)，广播事务提议（动作3）
3. Follower处理提议，做出反馈（动作4）
4. Leader收到过半数反馈，广播Commit（动作5）
5. Leader做出响应（动作6&7）

3）崩溃恢复

• Leader服务器出现崩溃，或者说由于网络原因导致Leader服务器失去了与过半Follower的联系，那么就会进入崩溃恢复模式。
  • ZAB协议规定如果一个事务Proposal在一台机器上被处理成功，那么应该在所有的机器上都被处理成功，哪怕机器出现故障崩溃。
  • ZAB协议确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交
  • ZAB协议确保丢弃那些只在Leader服务器上被提出的事务。
• ZAB协议需要设计的选举算法应该满足：
  1. 确保提交已经被Leader提交的事务Proposal
  2. 同时丢弃已经被跳过的事务Proposal
• 实现方法：
  • 如果让Leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高ZXID的事务Proposal，那么就可以保证这个新选举出来的Leader一定具有所有已经提交的提案。
  • 如果让具有最高编号事务Proposal的机器来成为Leader，就可以省去Leader服务器检查Proposal的提交和丢弃工作的这一步操作。

4）数据同步

• Leader选举出来后，需完成Followers与Leader的数据同步，当半数的Followers完成同步，则可以开始提供服务。
• 同步过程如下：
  • Leader服务器会为每一个Follower服务器都准备一个队列，并将那些没有被各Follower服务器同步的事务以Proposal消息的形式逐个发送给Follower服务器，并在每一个Proposal消息后面紧接着再发送一个Commit消息，以表示该事务已经被提交。
  • Follower服务器将所有其尚未同步的事务Proposal都从Leader服务器上同步过来并成功应用到本地数据库中后，Leader服务器就会将该Follower服务器加入到真正的可用Follower列表中，并开始之后的其他流程。

5）丢弃事务Proposal处理

• 在ZAB协议的事务编号ZXID设计中，ZXID是一个64位的数字。
  • 低32位是一个简单的单调递增的计数器，针对客户端的每一个事务请求，Leader服务器在产生一个新的事务Proposal的时候，都会对该计数器进行加1操作；
  • 高32位代表了Leader周期纪元的编号，每当选举产生一个新的Leader服务器，就会从这个Leader服务器上取出其本地日志中最大事务Proposal的ZXID，并从该ZXID中解析出对应的纪元值，然后对其进行加1操作，之后就会以此编号作为新的纪元，并将低32位置0来开始生成新的ZXID。
• 基于这样的策略，当一个包含了上一个Leader周期中尚未提交过的事务Proposal的服务器启动加入到集群中，发现此时集群中已经存在Leader，将自身以Follower角色连接上Leader服务器之后，Leader服务器会根据自己服务器上最后被提交的Proposal来和Follower服务器的Proposal进行对比，发现Follower中有上一个leader周期的事务Proposal时，Leader会要求Follower进行一个回退操作（回退到一个确实已经被集群中过半机器提交的最新的事务Proposal）

5. Leader选举

• 对选举算法的要求：
  • 选出的Leader节点上要持有最高的ZXID
  • 过半数节点同意
• 内置实现的选举算法：
  • LeaderElection
  • FastLeaderElection（默认）
  • AuthFastLeaderElection
• Zookeeper的Leader选举只用Paxos算法实现

1）概念

• 选举机制中的概念：

1. 服务器id myid (在0~255)
2. 事务id，服务器中存放的最大Zxid
3. 逻辑时钟，发起的投票轮数计数
4. 选举状态：
   • Looking，竞选状态。
   • Following，随从状态，同步leader状态，参与投票。
   • Observing，观察状态，同步leader状态，不参与投票。
   • Leading，领导者状态。

2）选举算法

• 选举算法：
  1. 每个服务实例均发起选举自己为领导者的投票（自己的投给自己）；
  2. 其他服务实例收到投票邀请时，比较发起者的数据事务ID是否比自己最新的事务ID大，大则给它投一票，小则不投票给它，相等则比较发起者的服务器ID，大则投票给它；
  3. 发起者收到大家的投票反馈后，看投票数（含自己的）是否大于集群的半数，大于则胜出，担任领导者；未超过半数且领导者未选出，则再次发起投票。
• 胜出条件：
  投票赞成数大于半数则胜出的逻辑。

3）选举流程示例说明

• 有5台服务器，每台服务器均没有数据，它们的编号分别是1，2，3，4，5，按编号依次启动，它们的选举过程如下：
  • 服务器1启动，给自己投票，然后发投票信息，由于其他机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。
  • 服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是Looking。
  • 服务器3启动，给自己投票，同时与之前启动的服务器1，2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1，2成为小弟。
  • 服务器4启动，给自己投票，同时与之前启动的服务器1，2，3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
  • 服务器5启动，后面的逻辑同服务器4成为小弟。

6. ZooKeeper参数配置

• 从官网说明文档学习了解Zookeeper的可配置参数：http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_configuration