Redis哨兵模式（故障转移测试）

Posted 2023-05-12

参考技术A 哨兵模式是在主备模式的基础上，加上哨兵，实现redis集群的故障转移。哨兵负责监控集群状态，当redis主节点发生故障，哨兵通过选举，选出替代的master节点。一般需要单数的哨兵进行选举，大多数达成一致。

问题：如果哨兵集群也有部分实例down了，出现偶数哨兵，或者只剩下一个哨兵会如何，还能进行故障转移吗。

为什么会出现这个问题：哨兵其实也是redis实例，一般情况下，哨兵是为了保证redis集群的故障转移。由于资源，以及网络通信的性能考虑，一般哨兵和redis会部署在同一物理机。如果一台物理机出现了物理故障，哨兵实例和redis服务实例会一起down掉。

本文章针对这个问题做一下实验。

使用3+3模式，3redis+3sentinel。

三台虚拟机，每台虚拟机运行1个redis+1个sentinel

ip、角色规划

    192.168.237.101：master，sentinel

    192.168.237.100：slave，sentinel

    192.168.237.103：slave，sentinel

安装redis、redis sentinel

    apt-get install redis-server

    apt-get install redis-sentinel

redis-server配置修改(/etc/redis/redis.conf)

   

redis-server slave配置修改

启动redis-server

    /etc/init.d/redis-server restart

查看redis-server主从集群情况

修改sentinel配置(/etc/redis/sentinel.conf)

    sentinel monitor mymaster 192.168.237.101 6379 2

    sentinel known-slave mymaster 192.168.237.100 6379

    protected-mode no

启动sentinel

    /etc/init.d/redis-sentinel start

查看redis-sentinel情况

   

预期：故障转移，哨兵选举出新的master

关掉redis-server（192.168.237.101）

查看sentinel日志（/var/log/redis/redis-sentinel.log）

可以看到，+odown master，哨兵检测master客观下线

然后进行投票：vote-for-leader

选出新的master：switch-master mymaster 192.168.237.101 6379 192.168.237.103 6379

192.168.237.101的sentinel日志：

查看redis和sentinel集群状态，确认master变成了192.168.237.103（master host）

恢复192.168.237.101的redis-server，查看日志，192.168.237.101转换成slave

预期：有两个sentinel，可能会出现，剩下两个slave各得一票的情况，按照哨兵原理，会等待一段时间进行再选举，直到某个slave有两票，完成故障转移。

经过3.1实验，master转换到了192.168.237.103，现在先后关掉103上的sentinel和redis-server

查看两台sentinel的redis-sentinel日志，可以选出master，进行故障转移：

查看redis集群状态，确认master（192.168.237.100）

预期：无法切换

依次关掉两个sentinel，一个redis-server master。3.2节master转移到了100，恢复环境后，依次关掉103,100的sentinel，100的redis-server master

查看101上的sentinel日志，由于只有一个sentinel，只有101上的sentinel投票

恢复一个redis-sentinel，现有两个redis-sentinel

查看sentinel日志，选出101为master

      有两个sentinel或以上可以进行故障切换。单数sentinel更容易选出master，进行故障转移。

+sdown：主观down机

+odown：客观down机

+new-epoch：集群递增版本号

+vote-for-leader：在哨兵集群中投票选举出一个哨兵，作为本次执行故障转移操作的leader

+try-failover：开始对某ip进行故障转移

voted for：另一个哨兵进行投票

+elected-leader：在哨兵集群中再次确认进行即将执行故障转移的leader是哪一个哨兵。 

+selected-slave slave：选出leader

 +failover-state-send-slaveof-noone slaveLeader：向目标slave发送"slaveof-noone"指令，令其不要再做其它任何节点的slave了，从现在开始，它就是老大，完成从slave到master的转换。

+failover-state-wait-promotion slave：等待其它的sentinel确认slave

+promoted-slave slave：其它的sentinel全部确认成功

+failover-state-reconf-slaves：开始对集群中的所有slave做reconf操作(更新配置信息)

+slave-reconf-sent：向指定的slave发送"slaveof"指令，令其跟随新的master

+switch-master：故障转移完毕后，各个sentinel开始监控新的master

Redis哨兵(Sentinel)模式，带你快速入门

1.是什么，能干嘛？

在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。

通俗来讲哨兵模式的出现是就是为了解决我们主从复制模式中需要我们人为操作的东西变为自动版，并且它比人为要更及时

2.哨兵主要功能（做了哪些事）

监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。

自动故障转移（Automatic Failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。

通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

3.架构

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的Redis节点，不存储数据。

数据节点：主节点和从节点都是数据节点。

4.怎么玩（实战）？

1.部署主从节点哨兵系统中的主从节点，与普通的主从节点配置是一样的，并不需要做任何额外配置。下面分别是主节点（port=8000）和2个从节点（port=8001/8002）的配置文件；我们刚才搭建的主从复制就是主从节点

2.部署哨兵节点

哨兵节点本质上是特殊的Redis节点。

3个哨兵节点的配置几乎是完全一样的，主要区别在于端口号的不同（26379 / 26380 / 263 81）下面以26379节点为例介绍节点的配置和启动方式；配置部分尽量简化：

sentinel-26379.conf

port 26379

daemonize yes

logfile "26379.log"

sentinel monitor mymaster 192.168.0.104 6379 2

其中，sentinel monitor mymaster 192.168. 92.128 6379 2配置的含义是：该哨兵节点监92.168.0.104 6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。

哨兵节点的启动有两种方式，二者作用是完全相同的：

redis-sentinel sentinel-26379.conf

redis-server sentinel-26379.conf --sentinel

5.故障转移演示（哨兵的监控和自动故障转移功能）

使用kill命令杀掉主节点

6.客户端（jedis）访问哨兵系统（自动故障转移功能）

 public static void main(String[] args)  {
        Logger logger= LoggerFactory.getLogger(TestJedisSentinel.class);        Set<String> set=new HashSet<>();
        set.add("192.168.0.104:28000");
        set.add("192.168.0.104:28001");
        set.add("192.168.0.104:28002");
        JedisSentinelPool jedisSentinelPool=new JedisSentinelPool("mymaster",set,"123456");
        while (true) {
                      Jedis jedis=null;
            try {
                jedis = jedisSentinelPool.getResource();                String s = UUID.randomUUID().toString();
                jedis.set("k" + s, "v" + s);
                System.out.println(jedis.get("k" + s));
                Thread.sleep(1000);
            }catch (Exception e){
                logger.error(e.getMessage());            }finally {
                if(jedis!=null){
                    jedis.close();                }            }        }    

7.基本原理

关于哨兵的原理，关键是了解以下几个概念：

主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。

客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。

需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：

1.每10秒通过向主从节点发送info命令获取最新的主从结构；

发现slave节点

确定主从关系

2.每2秒通过发布订阅功能获取其他哨兵节点的信息；SUBSCRIBE c2 PUBLISH c2 hello-redis交互对节点的“看法”和自身情况

3.每1秒通过向其他节点发送ping命令进行心跳检测，判断是否下线（monitor）。

心跳检测，失败判断依据

选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：

即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。

故障转移：选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：

在从节点中选择新的主节点：选择的原则是，

1.首先过滤掉不健康的从节点；

2.然后选择优先级最高的从节点（由replica-priority指定）；如果优先级无法区分，

3.则选择复制偏移量最大的从节点；如果仍无法区分，

4.则选择runid最小的从节点。

更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。

将已经下线的主节点（即6379）保持关注，当6379从新上线后设置为新的主节点的从节点

8.实践建议

哨兵节点的数量应不止一个。一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈；另一方面减少对下线的误判。此外，这些不同的哨兵节点应部署在不同的物理机上。

哨兵节点的数量应该是奇数，便于哨兵通过投票做出“决策”：领导者选举的决策、客观下线的决策等。

各个哨兵节点的配置应一致，包括硬件、参数等；此外应保证时间准确、一致。

9.总结

在主从复制的基础上，哨兵引入了主节点的自动故障转移，进一步提高了Redis的高可用性；但是哨兵的缺陷同样很明显：哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要我们对从节点做额外的监控、切换操作。此外，哨兵仍然没有解决写操作无法负载均衡、及存储能力受到单机限制的问题