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

摘要

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

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

哨兵模式是一种特殊的模式，首先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操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。

架构说明

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，进而看需不需要更新自己的投票，若是需要，则自己的投票也要广播出去