正规品牌网站设计图片,网站建设合同按什么交印花税,深圳网站制作工具,长春免费建站Zookeeper 集群及其选举机制 1.安装 Zookeeper 集群2.如何选取 Leader 1.安装 Zookeeper 集群
我们之前说了#xff0c;Zookeeper 集群是由一个领导者#xff08;Leader#xff09;和多个追随者#xff08;Follower#xff09;组成#xff0c;但这个领导者是怎么选出来的… Zookeeper 集群及其选举机制 1.安装 Zookeeper 集群2.如何选取 Leader 1.安装 Zookeeper 集群
我们之前说了Zookeeper 集群是由一个领导者Leader和多个追随者Follower组成但这个领导者是怎么选出来的呢我们貌似没有在配置文件中看到有关领导者和追随者的参数啊
在此之前先来看看 Zookeeper 内部的一些机制
半数机制只要有半数以上的节点存活则集群可用所以 Zookeeper 集群的节点数量适合为奇数。虽然在配置文件中没有指定领导者和追随者但 Zookeeper 在工作时有一个节点为 Leader其它则为 Follower而 Leader 是通过内部的选举机制临时产生的。
那么领导者到底是怎么选出来的呢很简单每台服务器都有一个 id这里的 id 后面说当启动的服务器超过半数的时候就会选择 id 最大的 Server 成为领导者。比如有五台服务器半数就是 2.5 2.5 2.5因此当启动三台的时候就可以选出领导者。至于剩余的两台启动之后只能成为追随者因为领导者已经选出来了。关于这里的细节一会儿再详细聊。
那么怎么指定服务器的 id 呢还记得配置文件中的 dataDir 参数吗在该参数指定的目录下创建一个 myid 文件文件必须叫这个名字然后在里面写上服务器的 id 即可。
[rootsatori zkData]# echo 2 myid这里给 id 设置为 2因为一会要搭建由三个节点组成的集群而我希望当前节点成为 Leader所以它的 id 应该为 2其它的两个节点的 id 显然分别为 1 和 3。这样按着 id 从小到大的顺序启动时该节点就会成为 Leader。
下面来我们来搭建 zookeeper 集群总共三个节点
IP82.157.146.194主机名satoriIP121.37.165.252主机名koishiIP123.60.7.226主机名marisa
satori 节点就是当前一直在用的节点剩余的两个节点的 Zookeeper 也已经安装完毕。那么问题来了我们要如何将这三个节点组成一个集群呢显然还需要修改配置文件先在 satori 节点进行修改。
# koishi 节点
server.1121.37.165.252:2888:3888
# satori 节点
server.20.0.0.0:2888:3888
# marisa 节点
server.3123.60.7.226:2888:3888将集群中都有哪些节点写在 zoo.cfg 中解释一下具体含义首先两个冒号把等号右边分成了三部分第一部分就不用说了IP 地址或者主机名用于定位节点 2888 2888 2888 是 Leader 和 Follower 交换信息 的端口因为副本要进行同步 3888 3888 3888 是 交换选举信息 的端口因为要选出 Leader。
然后我们注意到 satori 节点的 IP 设置成了 0.0.0.0这是因为当前的三个节点不在同一个网段IP 用的都是公网 IP而公网 IP 在绑定服务的时候会失败。所以在绑定的时候其它节点的 IP 要写成公网 IP自身节点的 IP 要写成 0.0.0.0。因此其它两个节点的 zoo.cfg 文件就应该这么改
########## koishi 节点配置 ##########
# koishi 节点
server.10.0.0.0:2888:3888
# satori 节点
server.282.157.146.194:2888:3888
# marisa 节点
server.3123.60.7.226:2888:3888########## marisa 节点配置 ##########
# koishi 节点
server.1121.37.165.252:2888:3888
# satori 节点
server.282.157.146.194:2888:3888
# marisa 节点
server.30.0.0.0:2888:3888但是在 生产中一个集群内的节点应该都位于同一网段然后将配置文件中的 IP 全部换成内网 IP 即可。这样彼此之间可以通过内网访问而内网的访问速度要远远快于公网并且还不需要走公网的流量。但我当前的三台云服务器不在同一个网段所以只能用公网 IP并且绑定的时候将节点自身的 IP 换成 0.0.0.0。
至于等号左边的 server. 是固定的后面的数字表示节点的 id而节点 id 我们说了通过在 myid 文件中进行指定。而节点 id 决定了最终由谁担任领导者。其中 satori 节点的 id 为 2 2 2刚刚已经改过了然后将 koishi 和 marisa 两个节点的 id 分别改为 1 1 1 和 3 3 3然后就大功告成了。
然后我们来启动 Zookeeper由于 satori 节点的 Zookeeper 已经启动了我们在修改完配置文件之后需要重新启动。 但是我们查看状态的时候发现出错了相信原因很好想。因为配置文件中指定了三个节点而剩余两个节点的 Zookeeper 还没启动。下面我们来启动一下然后再次查看状态。 当剩余的两个节点启动之后再次查看状态发现 Mode 变成了 Leader。显然集群已经启动成功至于剩余的两个节点显然就是 Follower。 此时集群就启动成功了但是关于领导者和追随者的选举问题我们还得再说一说。
2.如何选取 Leader
领导者选举分为两种情况
集群第一次启动的时候选举领导者。运行过程中领导者挂了从追随者当中选择一个作为领导者。
我们先来看第一种情况假设集群当中有 5 个节点id 分别为 1 到 5来看看选举过程是怎样的这里 5 个节点按照 id 从小到大顺序启动。
首先 server1 启动发起一次选举每个节点都有投票权并且默认都会投给自己。此时 server1 有 1 1 1 票但还不够半数以上 3 3 3 票)选举无法完成于是 server1 将状态保持为 LOOKING然后 server2 启动再发起一次选举重新投票。server1 和 server2 仍会把票投给自己然后再交换选票信息。由于 server1 发现 server2 的 id 比自己大于是会将自己的票改投给 server2。此时 server1 有 0 0 0 票server2 有 2 2 2 票但仍然没有哪个节点拥有超过半数的票选举无法完成server1 和 server2 状态都保持为 LOOKING接下来 server3 启动再发起一次选举相信整个过程不需要解释了。老规矩还是先投给自己再交换选票信息然后 server1 和 server2 发现自己的 id 都没有 server3 大于是都会将票改投给 server3。此时 server1 和 server2 的票数为 0 0 0server3 的票数为 3 3 3由于 server3 的票数已超过半数所以成功当选为 Leader状态变为 LEADING。而 server1、server2 则成为 Follower状态改为 FOLLOWING。所以 5 5 5 个节点启动 3 3 3 个之后就能选择出 Leader。然后 server4 又启动了于是也发起一次选举并把票投给自己。但 server1、server2、server3 已经不是 LOOKING 状态所以它们不会更改自己的选票信息最终结果 server3 仍有 3 3 3 票server4 只有 1 1 1 票。少数服从多数于是会再将自己的选票交给 server3成为 Follower状态改为 FOLLOWING。同理最后 server5 启动结果就是 server3 有 4 4 4 票自己只有 1 1 1 票。少数服从多数于是将自己的选票交给 server3成为 Follower。
所以整个过程关键点有两个
每个 server 启动之后都会发起选举并将票投给自己。然后交换选票信息并将票投给 id 最大的 server。一旦选择出 Leader其它节点自动成为 Follower。而后启动的 server不论 id 多大也只能成为 Follower。
以上就是集群第一次启动的时候选举领导者。
但如果在运行过程中领导者挂了该怎么办呢显然要再选举出一个新的领导者。所以当集群中的追随者发现自己连接不上领导者的时候就会开始进入 Leader 选举但此时是存在两种可能的。
领导者真的挂了。领导者没有挂只是追随者因为某些原因无法和领导者建立连接。比如 server5 发现连接不上 server3 了于是它认为领导者挂了便开启 Leader 选举。但事实上 server3 并没有挂其它追随者都能正常连接只是 server5 因为某些原因连接不上罢了。
先来解释第二种情况server5 认为 server3 挂了之后便会发起 Leader 选举呼吁其它追随者进行投票。但是其它追随者发现领导者并没有挂于是会拒绝 server5 的选举申请并告知它当前已存在的领导者信息。对于 server5 而言只需要和已存在的领导者重新建立连接并进行数据同步即可。 server3老子还没挂呢 但如果是第一种情况领导者真的挂了该怎么办比如这里的领导者 server3在运行的时候节点突然宕机了。
要解释这个问题我们需要引入一些新的概念。
sid就是我们一直说的服务器 id用于唯一标识集群中的节点。zxid事务 id客户端在发起一次写请求的时候都会带有 zxid用于标识一次服务器状态的变更。所以 Zookeeper 也是有事务的保证每次写数据的时候要么全部写完要么不写不会出现只写一半的情况。另外每个节点都有自己的 zxid它们的值也不一定相同。epochLeader 任期的编号就好比古代皇帝每个皇帝在当政的时候都有自己的年号。并且每投完一次票这个编号就会增加。
现在假设 server3 挂了那么要重新选举 Leader而选举规则如下
先比较节点之间的 epochepoch 大的直接当选。epoch 相同再比较 zxidzxid 大的当选。epoch 和 zxid 都相同则比较 sidsid 大的当选。
关于这么做背后的原理我们先暂且不表等到后面介绍 Paxos 协议的时候再细说。而且这里的 epoch 具体是干什么用的估计也有人不太清楚这些我们也留到后面再说。
