什么是哨兵模式
哨兵模式是Redis提供的一种高可用性解决方案，通过引入一组哨兵实例来监控和管理Redis主从服务器，以实现自动故障转移和高可用性。
在哨兵模式中，有一个或多个独立的哨兵进程运行在不同的机器上，它们负责监测主服务器和从服务器的健康状态。每个哨兵进程定期向Redis实例发送PING命令来检查其可用性，并根据预定义的条件判断实例是否故障。
当某个哨兵发现主服务器不可用时，它会与其他哨兵进行协商，通过多数派（quorum）原则选举出一个新的主服务器。一旦新的主服务器被选出，哨兵会通知所有的从服务器将它们切换到新的主服务器，并进行相应的重连操作。
哨兵的主要功能包括：
- 监视：哨兵周期性地检查主从服务器的健康状态，以确保它们正常运行。
- 自动故障检测和转移：哨兵能够自动检测主服务器的故障，并触发自动故障转移过程，选举出一个新的主服务器。
- 配置提供和更新：哨兵可以提供配置信息给客户端，使客户端能够获取到正确的主服务器地址和端口。
- 集群监听：哨兵可以监控多个Redis实例组成的集群，并在有需要时对集群进行重新配置。
在redis主从模式的基础上搭建哨兵
在这里我们本地部署三台redis服务主服务监听端口6379，两个从服务分别监听6380和6381端口。具体部署流程请参考：
Linux 搭建redis 主从模式_who_am_i__的博客-优快云博客
为什么至少需要三个哨兵
在哨兵模式中，建议至少使用三个哨兵实例，而不是两个或更少。这是因为在分布式系统中，使用一个奇数个哨兵实例可以提供更好的高可用性和决策一致性。
以下是一些原因：
-
Quorum（法定人数）：在哨兵模式中，哨兵之间使用quorum来进行投票和决策。quorum是指与实现最终决策所需的最小正确人数。使用奇数个哨兵可以确保有足够的哨兵参与决策，并且决策结果能够达到多数派的一致性。如果使用偶数个哨兵，可能会导致决策无法达成一致，进而影响自动故障转移和高可用性。
-
消除脑裂问题：哨兵模式中的脑裂问题是指当主服务器与哨兵之间的网络分区时，可能会导致不同的哨兵产生不同的决策，从而导致集群的不一致状态。使用奇数个哨兵可以有效降低脑裂问题的发生概率，因为在网络分区发生时，仍然有一个多数派的哨兵能够达成共识。
-
容错性和可扩展性：使用三个或更多的哨兵可以增加系统的容错性和可扩展性。如果某个哨兵实例发生故障，仍然有足够多的哨兵来监控和管理Redis实例。此外，当需要添加新的哨兵实例时，使用奇数个哨兵可以更好地保持quorum的正确性。
创建三个哨兵实例
哨兵配置文件
port 6383
# 无需配置可自动生成
#sentinel myid efcb8e5cb708ec46fcf5cf611797035370b16318
sentinel deny-scripts-reconfig yes
# 监控主服务的ip 端口 故障转移的投票数量
sentinel monitor dev-master ::1 6381 2
# 主服务器2秒内无响应，下线主服务器
sentinel down-after-milliseconds dev-master 2000
# 故障转移最大时间，如果超过10秒仍没有找出一个合适的新master故障转移失败
sentinel failover-timeout dev-master 10000
上面是哨兵配置的模板，分别添加三个配置文件：sentinel.conf、sentinel2.conf、sentinel3.conf。添加后只需要修改不同的端口号即可。三个哨兵分别使用端口：6383、6384、6385
启动哨兵
使用下面命令启动哨兵1和2：
redis-sentinel sentinel.conf --daemonize yes
redis-sentinel sentinel2.conf --daemonize yes
使用--daemonize no启动哨兵3，主要为了是监控其运行状态：
redis-sentinel sentinel3.conf --daemonize no
哨兵3启动日志：
验证
验证，需要我们关闭master服务，并查看哨兵状态和从服务状态变化：
关闭前查看master的info replication：
此时6379为master节点，有两个slave分别是6380和6381.
关闭master后：
哨兵控制台变化：
此时可以看到哨兵以重新选出6381节点为master节点。
查看6381节点变化（role从slave变为master有一个从节点6380）：
再重启6379节点（原master服务），可以发现6379变成了6381（新master）的从节点：
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
