Redis——哨兵模式与Zookeeper选举的异同点

摘要

当我们使用主从复制出现的问题:手动故障转移:写能力和存储能力受限:主从复制 -master 宕机故障处理。

主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。

Redis——哨兵模式与Zookeeper选举的异同点_第1张图片

哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。

哨兵主要有两个作用

  • 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。

  • 当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。

哨兵模式(raft)与Zookeeper模式(zab)选主的总结

  1. Redis中的Sentinel选主相对来说更简单,因为不涉及事务状态的一致性
  2. Sentinel选主是基于raft协议,Zookeeper则基于Zab协议
  3. 二者都是收到半数的选票就选举成功
  4. Sentinel投票发消息主要内容是Sentinel id和配置纪元,Zookeeper则是 zxid和 sid
  5. Sentinel谁先来找他投票他就投谁,Zookeeper中则是要细细检查比较一番,检查内容包括epoch和节点状态,检查完毕后再跟自己的投票进行pk,进而看需不需要更新自己的投票,若是需要,则自己的投票也要广播出去

故障切换(failover)的过程。

假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票(与Zookeeper的过半机制有什么不同 ),投票的结果由一个哨兵发起,进行failover操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线。这样对于客户端而言,一切都是透明的。

架构说明

Redis——哨兵模式与Zookeeper选举的异同点_第2张图片

  1. 多个sentinel 发现并确认master有问题。
  2. 选举出一个sentinel作为领导(怎么选举?)
  3. 选出一个slave作为master
  4. 通知其余的slave成为新的master的slave
  5. 通知客户端主从变化
  6. 等待老的master复活成新的master的slave

领导者选举

  • 只需要一个sentinel节点完成故障转移

  • 通过sentinel is - master -down -by-addr 命令都希望成为领导者

  •   -1. 每个主观下线都Sentitle 节点向其他Sentinel节点发送命令,要求将它设置为领导者
  •   -2. 收到命令对Sentinel节点如果没有同一通过其他Sentinel节点发送的命令,那么就将同一该请求,否则拒绝
  •   -3. 如果该Sentinel节点发现直接的票数已经超过Sentinel集合半数且超过quorum,那么它将成为领导者
  •   -4. 如果此过程由多个Sentinel节点成为领导者,那么将来等待一段时间重新进行选举

需要说明的问题

  • 尽可能在不同物理机上和同一个网络部署Redis sentinel的所有节点
  • Redis sentinel中的sentinel节点个数应该大于等于3且最好是奇数。(节点数多可以保证高可用)
  • Redis sentinel中的数据节点和普通数据节点没有区别。每个sentinel节点在本质上还是一个Redis实例,只不过和Redis数据节点不同的是,其主要作用是监控Redis数据节点
  • 客户端初始化时连接的是sentinel节点集合,不再是具体的Redis节点,但sentinel只是配置中心不是代理。

哨兵模式与Zookeeper选举的异同点

zk 选举

假设有两个server

(1) 发起投票

每个Server发出一个投票投给自己。由于是初始情况,Server1和Server2都会将自己作为Leader服务器来进行投票,每次投票会包含所推举的服务器的myid和ZXID,使用(myid, ZXID)来表示,此时Server1的投票为(1, 0),Server2的投票为(2, 0),然后各自将这个投票发给集群中其他机器。

(2) 接受投票

来自各个服务器的投票。集群的每个服务器收到投票后,首先判断该投票的有效性,如检查是否是本轮投票(通过logicalclock确定是否轮次比当前大)、是否来自LOOKING状态的服务器。

(3) 处理投票

轮次比较:

  • 如果轮次比当前大,则清空本地投票箱recvset,并将自己和收到的投票PK,谁大投谁,并广播。
  • 如果轮次跟当前一样,则比较本地投票箱里产生的leader和接受到的投票信息,谁大投谁,如果更新了就广播。
  • 如果轮次比当前小,则忽略

选票PK:

1、优先检查ZXID。ZXID比较大的服务器胜出。

2、如果ZXID相同,那么就比较myid。myid较大的服务器胜出。

例如:对于Server1而言,它的投票是(1, 0),接收Server2的投票为(2, 0),首先会比较两者的ZXID,均为0,再比较myid,此时Server2的myid最大,于是更新自己的投票为(2, 0),然后重新投票,对于Server2而言,其无须更新自己的投票,只是再次向集群中所有机器发出上一次投票信息即可。

(4) 统计投票

每次投票后,服务器都会统计投票信息,判断是否已经有过半机器接受到相同的投票信息,对于Server1、Server2而言,都统计出集群中已经有两台机器接受了(2, 0)的投票信息,此时便认为已经选出了Leader。

(5) 改变服务器状态

一旦确定了Leader,每个服务器就会更新自己的状态,如果是Follower,那么就变更为FOLLOWING,如果是Leader,就变更为LEADING。

redis 选举

如果需要从redis集群选举一个节点为主节点,首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。

每一个Sentinel节点都可以成为Leader,当一个Sentinel节点确认redis集群的主节点主观下线后,会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求,则同意该请求(选举票数+1),否则不同意。

如果一个Sentinel节点获得的选举票数达到Leader最低票数(quorum和Sentinel节点数/2+1的最大值),则该Sentinel节点选举为Leader;否则重新进行选举。

当Sentinel集群选举出Sentinel Leader后,由Sentinel Leader从redis从节点中选择一个redis节点作为主节点:

  1. 过滤故障的节点
  2. 选择优先级slave-priority最大的从节点作为主节点,如不存在则继续
  3. 选择复制偏移量(数据写入量的字节,记录写了多少数据。主服务器会把偏移量同步给从服务器,当主从的偏移量一致,则数据是完全同步)最大的从节点作为主节点,如不存在则继续
  4. 选择runid(redis每次启动的时候生成随机的runid作为redis的标识)最小的从节点作为主节点

Redis选举领头Sentinel(raft算法)

Sentinel是Redis实现高可用的保证。Sentinel系统作用就是监视Redis服务器集群,它可以不停的获得redis集群状态,当一个主节点挂了,故障转移操作会在从节点中选出一个新的主节点,这里故障转移就是由Sentinel来主导完成的。不要把Sentinel想的太复杂,它其实就是一个特殊工作模式的Redis服务器而已,Redis是集群部署的,这里的Sentinel也是要集群部署的,要是非单点部署,你的Sentinel挂了,此时的Redis集群就GG了。接着上边说,当主服务器节点挂了,Sentinel系统就会选出一个领头的Sentinel来完成故障转移工作。选举规则如下: - 监视这个挂了的主节点的所有Sentinel都有被选举为领头的资格

  • 每进行一次选举,不论是否成功,配置纪元+1,配置纪元就是个计数器
  • 每个Sentinel在每个配置纪元中有且仅有一次选举机会,一旦选好了该节点认为的主节点,在这个纪元内,不可以再更改
  • 每个发现服务器挂了的Sentinel都会配置纪元+1并投自己一票,接着发消息要求其他Sentinel设置自己为领头人1,每个Sentinel都想成为领头的
  • 每个Sentinel会将最先发来请求领头的节点设为自己的领头节点并发送回复,谁先来我选谁
  • 当源Sentinel收到回复,并且回复中的配置纪元和自己的一致且领头Id是自己的Sentinel Id时,表明目标Sentinel已经将自己设为领头
  • 在一个配置纪元内,当某个Sentinel收到半数以上的同意回复时,它就是领头的了
  • 如果在给定时间内,没有被成功选举的Sentinel,那么过段时间发起新的选举

选举领头Sentinel的过程和规则大概就如上所述,需要注意的是只有集群出现节点挂了才需要选举出领头Sentinel,平时每个Sentinel还是平等身份~

Zookeeper选举

Zookeeper是一个很强的分布式数据一致性解决方案,比如dubbo中的注册中心就使用的Zookeeper。当然,这也是集群部署的,但是它没有采用传统的Master/Slave结构,而是引入了Leader、Follwer和Observer。Leader和Follower类似于Master/Slave,新增的Observer作用仅仅只是增加集群的读性能,它不参与Leader的选举。

节点的状态有以下几种:

  • LOOKING: 节点正处于选主状态,不对外提供服务,直至选主结束;
  • FOLLOWING: 作为系统的从节点,接受主节点的更新并写入本地日志;
  • LEADING: 作为系统主节点,接受客户端更新,写入本地日志并复制到从节点

Zookeeper的状态同步是基于Zab协议实现的,Zab协议有两种模式,它们分别是崩溃恢复(选主)和消息广播(同步)。当服务启动或者在Leader崩溃后,Zab就进入了恢复模式,当Leader被选举出来,且超过一半机器完成了和 leader的状态同步以后,恢复模式就结束了。

首先明确几个概念: - Sid:服务器id;

  • Zxid:服务器的事务id,数据越新,zxid越大;zxid的高32位是epoch,低32位是zpoch内的自增id,由0开始。每次选出新的Leader,epoch会递增,同时zxid的低32位清0。

整个选主流程如下

  1. 状态变更。服务器启动的时候每个server的状态时Looking,如果是leader挂掉后进入选举,那么余下的非Observer的Server就会将自己的服务器状态变更为Looking,然后开始进入Leader的选举状态;
  2. 发起投票。每个server会产生一个(sid,zxid)的投票,系统初始化的时候zxid都是0,如果是运行期间,每个server的zxid可能都不同,这取决于最后一次更新的数据。将投票发送给集群中的所有机器;
  3. 接收并检查投票。server收到投票后,会先检查是否是本轮投票,是否来自looking状态的server;
  4. 处理投票。对自己的投票和接收到的投票进行PK:
先检查zxid,较大的优先为leader;如果zxid一样,sid较大的为leader;根据PK结果更新自己的投票,再次发送自己的投票
  1. 统计投票。每次投票后,服务器统计投票信息,如果有过半机器接收到相同的投票,那么leader产生,如果否,那么进行下一轮投票;
  2. 改变server状态。一旦确定了Leader,server会更新自己的状态为Following或者是Leading。选举结束。

我们要保证选主完成后,原来的主节点已经提交的事务继续完成提交;原主节点只是提出而没提交的事务要抛弃。这也是为什么倾向于选zxid最大的从节点为主节点,因为它上边的事务最新,最与原主节点保持一致。

哨兵模式(raft)与Zookeeper模式(zab)选主的总结

  1. Redis中的Sentinel选主相对来说更简单,因为不涉及事务状态的一致性
  2. Sentinel选主是基于raft协议,Zookeeper则基于Zab协议
  3. 二者都是收到半数的选票就选举成功
  4. Sentinel投票发消息主要内容是Sentinel id和配置纪元,Zookeeper则是 zxid和 sid
  5. Sentinel谁先来找他投票他就投谁,Zookeeper中则是要细细检查比较一番,检查内容包括epoch和节点状态,检查完毕后再跟自己的投票进行pk,进而看需不需要更新自己的投票,若是需要,则自己的投票也要广播出去

你可能感兴趣的:(redis,zookeeper,数据库)