zookeeper

最新推荐文章于 2020-12-14 18:59:13 发布

不染^

最新推荐文章于 2020-12-14 18:59:13 发布

阅读量181

点赞数

分类专栏：大数据笔记

本文链接：https://blog.csdn.net/ZY12166/article/details/93129333

版权

大数据笔记专栏收录该内容

17 篇文章 0 订阅

订阅专栏

zookeeper

1、结合zookeeper详细说明CAP定理

分布式领域中存在CAP理论，且该理论已被证明：任何分布式系统只可同时满足两点，无法三者兼顾。因此P是必须的,往往选择就在CP或者AP中。
　　C：Consistency，一致性，数据一致更新，所有数据变动都是同步的。
　　A：Availability，可用性，系统具有好的响应性能。
　　P：Partition tolerance，分区容错性。

用分布式系统的CAP原则来分析Zookeeper：

C: Zookeeper保证了最终一致性,在十几秒可以Sync到各个节点.
A: Zookeeper保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的. 如果想保证取得是数据一定是最新的,需要手工调用Sync()
P:
1、节点多了会导致写数据延时非常大,因为需要多个节点同步.
2、节点多了Leader选举非常耗时, 就会放大网络的问题. 可以通过引入 observer节点缓解这个问题.

为了保证一致性，为了保证集群中各个节点数据的一致性，ZK做了两类数据同步，初始化同步和更新同步。

1：当新的Leader选举出来后，各个Follower需要将新的Leader的数据同步到自己的缓存中，这就是初始化同步

2：当Leader数据被客户端修改后，其会向Follower发出广播，然后各个Follwer会竹筒去同步更新的数据，这是更新同步

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

广播模式
1、zookeeper读写消息

1）Client与Server是通过NIO方式通信的。

2）消息是FIFO方式执行的（顺序的，先进先出）。

3）读消息可以通过zookeeper的leader和所有的follower。

4）写消息必须通过leader。

2、zookeeper写消息的过程

（1）Client通过某个follower请求写操作时，该follower会把这个请求发给leader；

（2）leader再将这个更新（proposal），顺序发送给follower；

（3）follower收到leader更新时，follower会将数据持久化到磁盘；

（4）当follower写到磁盘后，就会向leader发送ACK；

（5）当leader收到半数以上的follower向它发送ACK后，就向全部的follower发送commit；

（6）leader并在本地commit消息（commit的意思是就是这个消息可对外读了）；

（7）当follower收到leader发送的commit后，就会将磁盘里的数据写进内存数据库，同时commit（每个follower都有内存数据库，Client去向follower请求数据时，都是通过内存数据库读取的）。同时每条消息，都有一个递增的id。

恢复模式
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通信，从而保证大部分节点都拥有最新的数据。

3、详述zookeeper选主的流程

在Zookeeper集群中，主要分为三者角色，而每一个节点同时只能扮演一种角色，这三种角色分别是：
(1). Leader 接受所有Follower的提案请求并统一协调发起提案的投票，负责与所有的Follower进行内部的数据交换(同步);
(2). Follower 直接为客户端服务并参与提案的投票，同时与Leader进行数据交换(同步);
(3). Observer 直接为客户端服务但并不参与提案的投票，同时也与Leader进行数据交换(同步);observer的作用是为了拓展系统，提高读取速度。

Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。

1)、选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；

2)、选举线程首先向所有Server发起一次询问(包括自己)；

3)、选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；

4)、/distribute_lock已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。

5)、线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1. 每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。

fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和 zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。

4、列出zookeeper节点命令及其作用

ZooKeeper服务命令

\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客户端命令

\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

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 相关的路径。