|
|
zookeeper 是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一种复杂的过程。Zookeeper 通过其简单的架构和API 解决了这个问题。
Zookeeper 允许开发人员专注于核心应用程序逻辑。而不必担心应用程序的分布式特点
以下为Zookeeper 的基本概念
Zookeeper 的数据模型Zookeeper 的数据模型是什么样子呢？ 他很像数据结构中的树，也很像文件系统的目录。
树是由节点所组成，Zookeeper 的数据存储也同样是基于节点，这种节点叫做Znode。 但是,不同树的节点，Znode 的引用方式是路径引用，类似于文件路径。
这样的层级结构，让每一个znode 节点拥有唯一的路径，就像命名空间一样对不同的信息作出清晰的隔离。
Znode 包含哪些元素 
data： Znode 存储的数据信息；
ACL： 记录Znode 的访问权限，即那些人和哪些ip可以访问本节点
stat： 包含Znode 的各种元数据，比如事务ID， 版本号，时间戳，大小等等。
child： 当前节点的子节点应用。
这里需要注意一点，Zookeeper 是为读多写少的场景锁设计，Znode 并不是用来存储大规模业务数据，而是用于存储少量的状态和配置信息，每个节点的数据最大不能超过1m；
Zookeeper 的基本操作创建节点：
删除节点：
判断节点是否存在：
获得一个节点的数据：
设置一个节点的数据：
获取节点下的所有子节点
这其中，exists， getData, getChildren 属于 读操作。Zookeeper客户端在请求读操作的时候，可以选择是否设置Watch.
Zookeeper的事件通知我Watch 理解成是注册在特定Znode 上的触发器，当这个Znode 发生改变，也就是调用了create, delete, setData 方法的时候，将会触发Znode 上注册的对应事件，请求Watch 的客户端会接收到异步通知。
具体交互过程如下：
客户端调用 getData 方法， watch参数是 true。 服务端接到请求，返回节点数据。并且在对应的哈希表里被watch的znode路径，以及watcher 列表。
当被watch 的znode 已删除，服务端会查找哈希表，找到该znode 对应的所有watcher, 异步通知客户端，并删除哈希表中对应的key-value。
Zookeeper 的一致性
Zookeeper 身为 分布式系统协调服务，如果自身挂了如何处理呢？ 为了防止单机挂掉的情况，Zookeeper 维护了有个集群。如下图：
Zookeeper Service 集群是一主多从结构，
在更新数据时，首先更新到主节点（这里的节点是指服务器，不知Znode），再同步到从节点。
在读取数据时，直接读取任意丛节点。
为了保证主从节点的数据一致性，Zookeeper 采用了ZAB 协议，这种协议非常类似于一致性算法 Paxos 和 Raft。
什么事ZABZookeeper Atomic Broadcast， 有效解决了Zookeeper 集群崩溃恢复，以及主从同步数据的问题。
zab协议定义的三种节点状态
looking： 选举状态，
Following: Following 节点（从节点）所处的状态。
leading： leader 节点（主节点）所处的状态。
最大ZXID
最大ZXID 也就是节点本地的最新事务编号，包含epoch 和计数2部分。epoch是纪元的意思，相当于raft 算法选举时候 的term.
ZAB 的崩溃恢复：
假如 Zookeeper 当前的主节点挂掉了，集群会进行崩溃恢复，zab 的崩溃恢复分成三个阶段：
leader election
选举阶段，此时集群中的节点处于 Looking 状态， 他们会各自向其他节点发起投票，投票当中包含自己的服务器ID，和最新事务ID（zxid）
接下来节点会用自身的ZXID 和从其他节点接收到的ZXID进行比较，如果发现别人家的ZXID 比自己的大，也就是数据比自己新，那么重新发起投票，投票给目前已知最大的zxid所属节点。
每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准leader，状态变为 leading。 其他节点的状态变为 Following。
发现阶段，用于从节点中发现最新的ZXID 和事务日志，获取有人会问： 既然leader 被选举为主节点，已经是集群里数据最新的了，为什么还要从节点中寻找最新的事务呢？
这是为了防止某些意外情况，比如因网络原因在上一阶段产生多个leader 的情况。
所以这一阶段，leader 集思广益，接收所有Follower 发来各自的最新epoch值。
leader 从中选出最大的epoch，基于此值加1， 生成新的epoch 分发给各个follower
各自follower 收到 全新的epoch 后，返回ack 给leader，带上各自最大的zxid 和历史事务日志，Leader 选出最大的ZXID,并更新自身历史日志。
Synchronization
同步阶段，把leader 刚才手机到的最新历史事务日志，同步给集群中所有的Follow。只有当半数Follower 同步成功，这个准leader 才能成为正式的leader。自此，故障恢复正式完成。
ZAB 数据写入
Broadcast
ZAB 的数据写入涉及到Broadcast，简单的说就是Zookeeper 等常规情况下更新数据的时候，由leader 广播到所有的Follower。 其过程如下：
客户端发出写入请求给任意Follower,
follower把写入数据请求转发给leader
leader 采用二进制提交方式，先发送给Propose 广播给follower
follower 接到Propose 消息，写入日志成功后，返回ack 消息给leader.
leader 接到半数以上ack 消息，返回成功给客户端，并且广播到commit请求给follower
ZAB 协议既不是强一致性，也不是弱一致性，而是处于2者之间的单调一致性（顺序一致性）。他依靠事务id和版本号，保证了数据的更新和读取是有序的。
Zookeeper 的应用场景：
分布式锁
这是雅虎研究员设计zookeeper 的初衷，利用Zookeeper 的临时顺序节点
，可以轻松实现分布式锁。
服务注册和发现。
利用Znode 和watcher， 可以实现分布式服务的注册和发现。最著名的应用就是阿里的分布式rpc 框架 dubbo。
共享配置和状态信息；
redis 的分布式解决方案codis, 就利用了Zookeeper 来存放数据路由表和codis-proxy 节点 的元信息。同时 codis-config 发起的命令都会通过zookeeper 同步到各个存活的codis-proxy.
此外， kafka, HBase,Hadoop, 也都依靠zookeeper 同步节点信息，实现高可用。
----------------------------
原文链接:https://www.jianshu.com/p/e5c05108e643
程序猿的技术大观园：www.javathinker.net
[这个贴子最后由 flybird 在 2020-05-31 20:30:58 重新编辑]
|
网站系统异常
| 系统异常信息 |
Request URL:
http://www.javathinker.net/WEB-INF/lybbs/jsp/topic.jsp?postID=3339
java.lang.NullPointerException
如果你不知道错误发生的原因，请把上面完整的信息提交给本站管理人员。
|
|
Java技术网站 → 『 Java开发技术 』 → 『 大数据处理和分布式架构专题 』 → 一文看懂Zookeeper
消息
查看
搜索
好友
邮件
复制
引用