大数据学习第十三天：

ZooKeeper是什么
ZooKeeper(ZK)是一个分布式开源协调服务框架，是Google的Chubby一个开源的实现，是hadoop的一个子项目
主要用来解决分布式系统的一致性问题，封装好了复杂易出错的关键服务，通过简单的接口为外部提供高性能、稳定的服务
实际应用场景包括：统一命名服务、分布式配置管理、集群管理、分布式锁、分布式队列 ……

结合zookeeper详细说明CAP定理

CAP理论告诉我们，一个分布式系统不可能同时满足以下三种

​ 一致性（C:Consistency）
可用性（A:Available）
分区容错性（P:Partition Tolerance）

这三个基本需求，最多只能同时满足其中的两项，因为P是必须的,因此往往选择就在CP或者AP中。

一、一致性（C:Consistency）

在分布式环境中，一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。例如一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，其他节点上的数据也应该得到更新，并且所有用户都可以读取到其最新的值，那么这样的系统就被认为具有强一致性（或严格的一致性，最终一致性）。

可用性（A:Available）

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。“有效的时间内”是指，对于用户的一个操作请求，系统必须能够在指定的时间（即响应时间）内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。

“返回结果”是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确的反映出对请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。

分区容错性（P:Partition Tolerance）

分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络等）中，由于一些特殊的原因导致这些子网络之间出现网络不连通的状况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。

由于一个分布式系统无法同时满足上面的三个需求，而只能满足其中的两项，因此在进行对CAP定理的应用的时候，需要根据业务的要求抛弃其中的一项，下表所示是抛弃CAP定理中任意一项特性的场景说明。

因此，将精力浪费在思考如何设计能满足三者的完美系统上是愚钝的，应该根据应用场景进行适当取舍。

二、一致性的分类

一致性是指从系统外部读取系统内部的数据时，在一定约束条件下相同，即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同，可以将一致性的分类为如下几种：

强一致性：（strong consistency）。任何时刻，任何用户都能读取到最近一次成功更新的数据。

单调一致性：（monotonic consistency）。任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，可获取的数据顺序必是单调递增的。

会话一致性：（session consistency）。任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这值更旧的值，会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。

最终一致性：（eventual consistency）。用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。

弱一致性：（weak consistency）。用户无法在确定时间内读到最新更新的值。

三、ZooKeeper提供的一致性服务

ZooKeeper从以下几点保证了数据的一致性

顺序一致性：来自任意特定客户端的更新都会按其发送顺序被提交保持一致。也就是说，如果一个客户端将Znode z的值更新为a，在之后的操作中，它又将z的值更新为b，则没有客户端能够在看到z的值是b之后再看到值a（如果没有其他对z的更新）。

原子性：每个更新要么成功，要么失败。这意味着如果一个更新失败，则不会有客户端会看到这个更新的结果。

单一系统映像：一个客户端无论连接到哪一台服务器，它看到的都是同样的系统视图。这意味着，如果一个客户端在同一个会话中连接到一台新的服务器，它所看到的系统状态不会比 在之前服务器上所看到的更老。当一台服务器出现故障，导致它的一个客户端需要尝试连接集合体中其他的服务器时，所有滞后于故障服务器的服务器都不会接受该 连接请求，除非这些服务器赶上故障服务器。

持久性：一个更新一旦成功，其结果就会持久存在并且不会被撤销。这表明更新不会受到服务器故障的影响。

实时性：在特定的一段时间内，客户端看到的系统需要被保证是实时的（在十几秒的时间里）。在此时间段内，任何系统的改变将被客户端看到，或者被客户端侦测到。

四、用CAP理论来分析ZooKeeper

CAP理论告诉我们，一个分布式系统不可能同时满足以下三种

一致性（C:Consistency）
可用性（A:Available）
分区容错性（P:Partition Tolerance）

这三个基本需求，最多只能同时满足其中的两项，因为P是必须的,因此往往选择就在CP或者AP中。

在此ZooKeeper保证的是CP

分析：可用性（A:Available）

不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性（注：也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）。所以说，ZooKeeper不能保证服务可用性。

进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说，ZooKeeper不能保证服务可用性。

详述zookeeper的广播模式和恢复模式

在ZooKeeper中所有的事务请求都由一个主服务器也就是Leader来处理，其他服务器为Follower，Leader将客户端的事务请求转换为事务Proposal，并且将Proposal分发给集群中其他所有的Follower，然后Leader等待Follwer反馈，当有过半数（>=N/2+1）的Follower反馈信息后，Leader将再次向集群内Follower广播Commit信息，Commit为将之前的Proposal提交。

一个客户端的写请求进来之后，leader 会为每个客户端的写请求包装成事务，并提供一个递增事务ID(zxid),保证每个消息的因果关系顺序。leader 会为该事务生成一个 Proposal,进行广播，leader 会为每一个 Follower服务器分配一个单独的FIFO 队列，然后把 Proposal 放到队列中，每一个 Follower 收到 该 Proposal 之后会把它持久到磁盘上，当完全写入之后，发一个 ACK 给leader，我们的leader 也不傻，收到超过半数机器的ack之后，他自己把自己机器上 Proposal 提交一下，同时开始广播 commit,每一个 Follower 收到 commit 之后，完成各自的事务提交。

可见，多数派机制和 ack 机制保证了 zk 的效率和可靠性。

特殊情况崩溃的处理：

已经被 leader 提交的 Proposal 确保最终被所有的 Follower 提交。

确保只有在 leader 上被提出的 Proposal 会被遗弃。

这里的丢弃事务是如何让进行的呢？我们知道，每一个事务都是有一个 zxid进行标记的，这个zxid 是一个 64位的数字，低32位做为计数器，高32位作为 leadert 的epcho周期、重新选举出来的 leader 会在急集群中找到最大的日志的 zxid，然后提取出来 + 1 作为自己的 epcho 周期数，然后把后面的32位清零，开始计数。

zookeeper的恢复模式

1、进入恢复模式

当leader宕机或者丢失大多数follower后，即进入恢复模式。

2、结束恢复模式

新leader被选举起来后，且大多数的follower完成与leader的状态同步后，恢复模式即结束，进入广播模式。

3、恢复模式的意义

每个消息的id（zxid）是64位，前面32位称为epoch，后面32位称为counter。

（1）发现集群中被commit的proposal的最大的zxid，之后的leader不会commit比这zxid小的proposal，也就是说leader只能commit比这大的proposal。

（2）建立新的epoch，从而保证之前的leader不能再commit新的proposal（每选举出一个新的leader，epoch都会改变，且比之前的大，且保证一个leader的任期内，epoch不会被改变）。

（3）集群中大部分节点都commit过前一个leader commit过的消息，而新的leader是被大部分节点锁支持的（会选举出于前leader保持最为紧密的follower作为leader），所以被之前leader commit过的proposal不会丢失，至少被一个节点所保存。

（4）新的leader会与所有follower通信，从而保证大部分节点都拥有最新的数据。

详述zookeeper选主的流程

zookeeper提供了三种方式：

LeaderElection

AuthFastLeaderElection

FastLeaderElection

默认的算法是FastLeaderElection，所以这篇主要分析它的选举机制。

选择机制中的概念

服务器ID

比如有三台服务器，编号分别是1,2,3。

编号越大在选择算法中的权重越大。

数据ID

服务器中存放的最大数据ID.

值越大说明数据越新，在选举算法中数据越新权重越大。

逻辑时钟

或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。

选举状态

• LOOKING，竞选状态。
• FOLLOWING，随从状态，同步leader状态，参与投票。
• OBSERVING，观察状态,同步leader状态，不参与投票。
• LEADING，领导者状态。

选举消息内容

在投票完成后，需要将投票信息发送给集群中的所有服务器，它包含如下内容。

服务器ID

数据ID

逻辑时钟

选举状态

判断是否已经胜出

默认是采用投票数大于半数则胜出的逻辑。

选举流程简述

目前有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成为小弟。

列出zookeeper节点命令及其作用

ZooKeeper服务命令:

​ 在准备好相应的配置之后，可以直接通过zkServer.sh 这个脚本进行服务的相关操作

\1. 启动ZK服务: sh bin/zkServer.sh start

\2. 查看ZK服务状态: sh bin/zkServer.sh status

\3. 停止ZK服务: sh bin/zkServer.sh stop

\4. 重启ZK服务: sh bin/zkServer.sh restart

zk客户端命令

ZooKeeper命令行工具类似于Linux的shell环境，不过功能肯定不及shell啦，但是使用它我们可以简单的对ZooKeeper进行访问，数据创建，数据修改等操作. 使用 zkCli.sh -server 127.0.0.1:2181 连接到 ZooKeeper 服务，连接成功后，系统会输出 ZooKeeper 的相关环境以及配置信息。

命令行工具的一些简单操作如下：

\1. 显示根目录下、文件： ls / 使用 ls 命令来查看当前 ZooKeeper 中所包含的内容

\2. 显示根目录下、文件： ls2 / 查看当前节点数据并能看到更新次数等数据

\3. 创建文件，并设置初始内容： create /zk “test” 创建一个新的 znode节点“ zk ”以及与它关联的字符串

\4. 获取文件内容： get /zk 确认 znode 是否包含我们所创建的字符串

\5. 修改文件内容： set /zk “zkbak” 对 zk 所关联的字符串进行设置

\6. 删除文件： delete /zk 将刚才创建的 znode 删除

\7. 退出客户端： quit

\8. 帮助命令： help

9rmr命令

删除节点命令，此命令与delete命令不同的是delete不可删除有子节点的节点，但是rmr命令可以删除，注意路径为绝对路径。

如rmr /zookeeper/znode

10delquota命令

删除配额，-n为子节点个数，-b为节点数据长度。

如delquota –n 2，请参见listquota和setquota命令。

11printwatches命令

设置和显示监视状态，on或者off。

如printwatches on

listquota命令

显示配额。

如listquota /zookeeper

absolute path is/zookeeper/quota/zookeeper/zookeeper_limits

Output quota for /zookeepercount=2,bytes=-1

解释：

/zookeeper节点个数限额为2，长度无限额。

setAcl命令

设置节点Acl。

此处重点说一下acl，acl由大部分组成：1为scheme，2为user，3为permission，一般情况下表示为scheme?permissions。

其中scheme和id是相关的，下面将scheme和id一起说明。

scheme和id

world: 它下面只有一个id, 叫anyone, world:anyone代表任何人，zookeeper中对所有人有权限的结点就是属于world:anyone的

auth: 它不需要id, 只要是通过authentication的user都有权限（zookeeper支持通过kerberos来进行authencation, 也支持username/password形式的authentication)

digest: 它对应的id为username:BASE64(SHA1(password))，它需要先通过username:password形式的authentication

ip: 它对应的id为客户机的IP地址，设置的时候可以设置一个ip段，比如ip:192.168.1.0/16, 表示匹配前16个bit的IP段

super: 在这种scheme情况下，对应的id拥有超级权限，可以做任何事情(cdrwa)

permissions

CREATE©: 创建权限，可以在在当前node下创建child node

DELETE(d): 删除权限，可以删除当前的node

READ®: 读权限，可以获取当前node的数据，可以list当前node所有的child nodes

WRITE(w): 写权限，可以向当前node写数据

ADMIN(a): 管理权限，可以设置当前node的permission

综上，一个简单使用setAcl命令，则可以为：

setAcl /zookeeper/node1 world:anyone:cdrw

getAcl命令

获取节点Acl。

如getAcl /zookeeper/node1

'world,'anyone

cdrwa

注：可参见setAcl命令。

sync命令

强制同步。

如sync /zookeeper

由于请求在半数以上的zk server上生效就表示此请求生效，那么就会有一些zk server上的数据是旧的。sync命令就是强制同步所有的更新操作。

redo命令

再次执行某命令。

如redo 10

其中10为命令ID，需与history配合使用。

addauth命令

节点认证。

如addauth digest username:password，可参见setAcl命令digest处。

使用方法：

一、通过setAcl设置用户名和密码

setAcl pathdigest:username:base64(sha1(password)):crwda

二、认证

addauth digest username:password

delete命令

删除节点。

如delete /zknode1

setquota命令

设置子节点个数和数据长度配额。

如setquota –n 4 /zookeeper/node 设置/zookeeper/node子节点个数最大为4

setquota –b 100 /zookeeper/node 设置/zookeeper/node节点长度最大为100

ZooKeeper 常用四字命令：

​ ZooKeeper 支持某些特定的四字命令字母与其的交互。它们大多是查询命令，用来获取 ZooKeeper 服务的当前状态及相关信息。用户在客户端可以通过 telnet 或 nc 向 ZooKeeper 提交相应的命令

\1. 可以通过命令：echo stat|nc 127.0.0.1 2181 来查看哪个节点被选择作为follower或者leader

\2. 使用echo ruok|nc 127.0.0.1 2181 测试是否启动了该Server，若回复imok表示已经启动。

\3. echo dump| nc 127.0.0.1 2181 ,列出未经处理的会话和临时节点。

\4. echo kill | nc 127.0.0.1 2181 ,关掉server

\5. echo conf | nc 127.0.0.1 2181 ,输出相关服务配置的详细信息。

\6. echo cons | nc 127.0.0.1 2181 ,列出所有连接到服务器的客户端的完全的连接 / 会话的详细信息。

\7. echo envi |nc 127.0.0.1 2181 ,输出关于服务环境的详细信息（区别于 conf 命令）。

\8. echo reqs | nc 127.0.0.1 2181 ,列出未经处理的请求。

\9. echo wchs | nc 127.0.0.1 2181 ,列出服务器 watch 的详细信息。

\10. echo wchc | nc 127.0.0.1 2181 ,通过 session 列出服务器 watch 的详细信息，它的输出是一个与 watch 相关的会话的列表。

\11. echo wchp | nc 127.0.0.1 2181 ,通过路径列出服务器 watch 的详细信息。它输出一个与 session 相关的路径。

详述在zookeeper案例中，zookeeper的工作流程

读
读操作非常简单，因为各个server的数据完全一致，client发送读请求时，与此client相连的server直接从自己内存获取数据返回给client，非常快。

读的流程
写
写操作会影响目录树结构和节点的数据内容，涉及到各个server间的数据一致性，所以不像读操作那么简单
步骤
（1）client发送写请求给与其相连的server
（2）server把写请求转给leader
（3）leader执行写操作，然后通知其他server：数据有变化，你们马上更新
（4）各server更新数据后，通知client写操作完成

写的流程

session:
使用客户端来创建一个和zk服务端连接的句柄，这就是一个会话（session）。Session一旦建立，状态就是连接中（CONNECTING）状态，然后客户端会尝试去连接zk服务端，连接成功之后状态变成已连接（CONNECTED）。一般正常情况下只会有这两个状态。不过，还是会发生一些无法恢复的错误/故障，比如：session过期，认证失败，或者客户端关闭连接，这种情况下，session状态会变成闭（CLOSED）状态。