我的编程空间,编程开发者的网络收藏夹
学习永远不晚

Zookeeper 集群角色、原理

短信预约 信息系统项目管理师 报名、考试、查分时间动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

Zookeeper 集群角色、原理

Zookeeper 集群角色、原理

Zookeeper 的集群角色

集群中的 server 分为三种角色:leader, follower, observer

file

  • 其中observer是配置zoo.cfg明确定义的,角色leader 在一个zookeeper集群中有且只能有一个,是通过内部的选举机制临时产生的。
  • leader 是集群中最重要的角色。负责响应集群的所有对Zookeeper数据状态变更的请求。它会将每个状态更新请求进行顺序管理,以便保证整个集群内部消息处理的 FIFO,遵循了顺序一致性(Sequential Consistency)。
    • leader 内部维护 session ,来自客户端的连接和断开连接,都会被统一followerobserver 转发给leader处理。
    • leader 内部维护单调递增的 Zxid(ZooKeeper Transaction Id),针对客户端连接,断开连接,节点的写操作都会分配一个全局唯一的Zxid,同时这些操作是原子性的,并且是严格顺序性的,遵循ZAB原子广播一致性协议完成事务(transaction)操作。如果客户端的所有写操作,都会被 follower 统一转发给leader处理。
  • follower 具有选举权。负责提供给客户端读写服务,需要响应leader的提议
  • observer 没有选举权。主要提供给客户端读服务,不提供写服务,也不需要响应leader的提议。也不需要日志文件,因为没有写服务,没有持久化的需要。
Server状态
  • LOOKING,竞选状态。
  • FOLLOWING,随从状态,同步leader状态,参与投票决策提案。
  • OBSERVING,观察状态,同步leader状态,不参与投票决策提案。
  • LEADING,领导者状态,发起正常消息的提案。

Zookeeper 的存储

zookeeper中的znode数据都是在内存中优先维护和提供读服务,当事务被提交以及最终提交都会持久化到磁盘的日志文件中。

Zookeeper 的内部网络拓扑

Zookeeper 在内部网络中如何实现两两连接的?

file

这里暂且使用 10.0.2.30,10.0.2.31,10.0.2.32,10.0.2.33 替代 node1,node2,node3,node4,并依次启动 zookeeper。

  • zoo.cfg配置文件
server.1=10.0.2.30:2888:3888
server.2=10.0.2.31:2888:3888
server.3=10.0.2.32:2888:3888
server.4=10.0.2.33:2888:3888

依次使用 netstat 查看网络连接情况

  • node1

file

可以看出来 node1作为服务节点,由 node2,node3,node4 通过 3888端口建立连接进来。
node1 作为客户端连接 node3 (目前node3是leader) 的2888端口。

  • node2

file

可以看出来 node2作为服务节点,由 node3,node4 通过 3888端口建立连接进来。
但是 node2 作为客户端连接node1的3888端口。
node2 作为客户端连接 node3 (目前node3是leader) 的2888端口。

  • node3

file

可以看出来 node3作为服务节点,由 node4 通过 3888端口建立连接进来。
但是 node3 作为客户端连接node1,node2 的3888端口。
node3 作为leader节点,由 node1,node2 ,node4 通过 3888端口建立连接进来。
至于为什么 node3能当选 leader 呢?可以在下面的 选举过程中 得到进一步详细的阐述。

  • node4

file

可以看出来 node4 作为客户端连接node1,node2 ,node3 的3888端口。
node4 作为客户端连接 node3 (目前node3是leader) 的2888端口。

  • 结论
    Zookeeper 在内部网络中如图所示,依据zoo.cfg的配置后续的server都逐个连接前面的server的3888端口,这样就形成了两两连接的拓扑,同时也不冗余。
    而当leader当选时,会开放2888端口,其他follower连接其2888端口。

ZAB(原子广播,Zookeeper Atomic Broadcast

https://zookeeper.apache.org/doc/current/zookeeperInternals.html

ZAB(Zookeeper Atomic Broadcast)原子广播是 Paxos分布式一致性协议算法(http://zh.wikipedia.org/zh-cn/Paxos) 的一个简化版本。

首先有以下概念,我们需要了解:

  • 数据包(Packet):通过 FIFO Channel 发送的字节数组。
  • 提案(Proposal):协议的单位。通过与ZooKeeper中的法定server交换数据包来达成协议。大多数提案都包含消息,但是 NEW_LEADER Proposal 提案是不包含消息。
  • 消息(Message):要自动广播到所有ZooKeeper服务器的字节数组。消息被包含在一个提案(Proposal)中,并且只有在提案(Proposal)被通过后消息才会最终交付delivered(提交到事务日志和更新内存的统一视图)。
  • 法定人员 (Quorum):有 Zookeeper集群中非observer 角色的所有服务器节点组成,具有投票通过提案(Proposal)的权力。

在 Zookeeper 中提供以下的保证数据的严格顺序:

  • 传递可靠性:如果一个消息被一个server最终交付delivered,那么这个消息最终也被其他所有的server最终交付delivered,这里指最终一致性。
  • 顺序全局性:如果一个消息a先于b被一个server最终交付delivered,那么消息a也是先于b被其他所有的server最终交付delivered
  • 顺序传递性:如果消息a先于b被发送到server,消息b先于c被发送到server,那么消息a也是先于c被server接收的。

如上所述,ZooKeeper保证消息的总顺序,也保证建议的总顺序。

ZooKeeper使用ZooKeeper transaction id (zxid) ,这是一个全局的唯一的ID。提出提案(Proposal)时,所有提案都将附上zxid,进而保证全局的顺序性。

  • leader 将提案(Proposal)将发送到所有ZooKeeper服务器。

  • 在法定人员(Quorum)收到后,会确认(acknowledge)回复这个提案(Proposal)给leader

其中确认acknowledge提案(Proposal)表示服务器已将提案(Proposal)持久化到日志中。

稍微注意一下:法定人员(Quorum)收到提案(Proposal),只存在确认(acknowledge),或者因为网络等原因超时响应,不存在反对(reject)。

  • 只要一但满足半数以上(大于所有法定人员的一半)确认acknowledge后,leader就会进入正式提交(Commit)。

  • 如果提案(Proposal)中包含一条消息,则在提交时将最终交付delivered该消息。

ZooKeeper消息传递包括两个阶段:

  • leader选举(Leader activation):在此阶段,leader被选举出来,集群开始变为对外可用状态,并准备开始提出提案(Proposal)。
  • 活动消息传递(Active messaging):在此阶段,leader开始接受消息(Message),并发起提案(Proposal),协调和决策以提交(Commit)提案(Proposal)。

leader选举

leader产生的条件:

  • 具有最新的 Zxid,如果 存在多个server都有最新的Zxid,在投票过程中选取建立网络连接中 myid最大的。
  • leader 和其连接的follower的个数必须满足半数以上(大于所有法定人员的一半)。

file

当集群中任意具有选举权的server发现leader挂了:

  • 该 server 会触发NEW_LEADER Proposal 提案,给自己投票,并通过 ZAB 广播给所有连接的 server。
  • 接受到 NEW_LEADER Proposal 提案的server,如果有被选举权,则会触发它的投票行为:
    • 先比较zxid,最新的胜出,如果zxid相同,再比较myid,最大的胜出。
    • 最后将胜出的内容,通过 ZAB 广播给所有连接的 server。
  • 最终满足leader条件的server,将被选出,同时 follower也被广播获得 Proposal 的提交。

以上中的 网络拓扑 为什么 node3能当选 leader 呢?

  • node1 启动时,给自己投票,因为其他server尚没启动,因为 node1 依然在LOOKING竞选状态。
  • node2 启动完,给自己投票,同时与 node1 交换了Zxid和myid,node2 胜出,但因为没有达到半数以上法定人员,所以node1,node2 依然处于LOOKING竞选状态。
  • node3 启动完,给自己投票,同时与 node1 ,node2 交换了Zxid和myid,node3 胜出,也达到半数以上法定人员(3 > 4/2),因此 node3 被选举为 leader
  • node4 启动完,给自己投票,同时与 node1 ,node2 ,node3交换了Zxid和myid,node3的Zxid最新,因此 node4 追随 node3。

活动消息传递

消息的传递一般指写请求。

file

  • follower 接收到 客户端的 写请求后,会转发给 leader顺序处理。
  • leader 收到写请求,会检查数据问题,如无问题,创建一个新的提案proposal加入toBeApplied FIFO 队列,内容是写请求的消息,并附上全局的ZXid。
  • leader每次toBeApplied FIFO 队列头部取到一个提案proposal,通过 ZAB 广播给所有的 follower,处于 pending 等待回复。
  • follower 收到提案proposal后,记录提案proposal持久化到磁盘的日志文件中,然后确认(acknowledge)回复这个提案(Proposal)给leader
  • leader处于 pending 等待回复,一旦收到follower 加上自己的确认(acknowledge)超过半数法定人员(Quorum),就会触发 Commit阶段,发送commit请求给所有的follower,发送info请求所有的observer
    同时,leader将提案proposal放入 committedRequest 队列,并从toBeApplied FIFO 队列移出该 提案proposal
  • follower 收到 Commit后,会更新自己的内存数据,统一数据视图。
  • observer收到info后,会更新自己的内存数据,统一数据视图。

file

针对客户端的读请求,则不需要转发给leader处理。
当然如果是客户端的sync命令,则会触发客户端连接的followerobserverleader请求同步数据状态。

@SvenAugustus(https://www.flysium.xyz/)
更多请关注微信公众号【编程不离宗】,专注于分享服务器开发与编程相关的技术干货:

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

Zookeeper 集群角色、原理

下载Word文档到电脑,方便收藏和打印~

下载Word文档

猜你喜欢

Zookeeper 集群角色、原理

Zookeeper 的集群角色集群中的 server 分为三种角色:leader, follower, observer。其中observer是配置zoo.cfg明确定义的,角色leader 在一个zookeeper集群中有且只能有一个,是通过内部的选举机制临
Zookeeper 集群角色、原理
2016-01-11

Zookeeper集群管理与选举怎么理解

本篇内容主要讲解“Zookeeper集群管理与选举怎么理解”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Zookeeper集群管理与选举怎么理解”吧!  1.集群机器监控  这通常用于那种对集群
2023-06-02

Azure golang SDK - 将 AcrPull 角色分配给 AKS 群集

php小编新一为您介绍Azure golang SDK中的一个重要功能:将AcrPull角色分配给AKS群集。这个功能可以帮助开发者在Azure云平台上更便捷地管理和使用容器镜像。通过使用golang SDK,开发者可以轻松地为AKS群集分
Azure golang SDK - 将 AcrPull 角色分配给 AKS 群集
2024-02-10

Zookeeper集群管理与选举方法是什么

这篇文章主要讲解了“Zookeeper集群管理与选举方法是什么”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Zookeeper集群管理与选举方法是什么”吧!  1.集群机器监控  这通常用于
2023-06-02

Redis 集群伸缩原理

Redis 节点分别维护自己负责的槽和对应的数据。伸缩原理:Redis 槽和对应数据在不同节点之间移动环境:CentOS7 搭建 Redis 集群一、集群扩容1. 手动扩容(1) 准备节点 9007,并加入集群192.168.11.40:9001> clust
Redis 集群伸缩原理
2019-10-16

Zookeeper的配置与集群管理方法是什么

这篇文章主要讲解了“Zookeeper的配置与集群管理方法是什么”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Zookeeper的配置与集群管理方法是什么”吧!4.1 配置文件ZooKeep
2023-06-04

运维必备:Zookeeper集群“脑裂”问题处理大全

本文重点分享Zookeeper脑裂问题的处理办法。ZooKeeper是用来协调(同步)分布式进程的服务,提供了一个简单高性能的协调内核,用户可以在此之上构建更多复杂的分布式协调功能。

Linux集群的原理是什么

Linux集群的原理是什么,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。Linux集群原理Linux集群系统包括集群节点和集群管理器两部分。集群节点有时简称为节点、服务器或
2023-06-13

Redis集群原理详细分析

Redis集群实现了对Redis的水平扩容,即启动N个redis节点,将整个数据库分布存储在这N个节点中,每个节点存储总数据的1/N。Redis集群通过分区来提供一定程度的可用,即使集群中有一部分节点失效或者无法进行通讯,集群也可以继续处理命令请求
2022-12-19

HDFS的HA集群原理分析

1.简单hdfs集群中存在的问题不能存在两个NameNode单节点问题   单节点故障转移2.解决单节点问题找额外一个NameNode备份原有的数据 会出现脑裂脑裂:一个集群中多个管理者数据不一致 这种情况称之为脑裂3.如何解决启动多个NameNode时保证同
HDFS的HA集群原理分析
2016-09-29

图解ZooKeeper,注册中心、负载均衡、通知机制、集群、写原理,一网打尽!

ZooKeeper是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,一旦这些数据的状态发生变化,Zookeeper 就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

解读MySQL Galera集群架构原理

MySQL Galera集群是一种高可用、高性能的MySQL集群解决方案,它采用了一种称为“多主复制”(Multi-Master Replication)的技术来实现数据的同步和共享。以下是MySQL Galera集群架构原理的详细解释:多
解读MySQL Galera集群架构原理
2024-09-03

Redis cluster集群Hash Tag原理分析

hash tag是一把双刃剑,在使用时需要考虑具体业务逻辑与场景,应当尽量避免上述问题。假设无法避免时,可以对key的粒度按照业务线或者场景进行细化,进而对key进行拆分,以便更均匀的分散到不同的slot上。

集群管理系统 Mesos 的设计原理

本文要介绍的是 2011 年 NSDI 期刊中的论文 —— Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center[^1],该论文实现的 Mesos 能够

Redis主从集群原理讲解和Docker-compose安装Redis主从集群

Linux 上我们可以从 Github 上下载它的二进制包来使用,选择适应Docker版本的docker compose,使用Docker info 查看Docker对应的Docker-Compose版本,我的机器对应的是v2.21.0。

编程热搜

目录