Redis哨兵（sentinel）

巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务。

作用

主从监控：监控主从redis库运行是否正常
消息通知：哨兵可以将故障转移的结果发送给客户端
故障转移：如果master异常，则会进行主从切换，将其中一个slave作为新master
配置中心：客户端通过连接哨兵来获得当前redis服务的主节点地址

示例

在sentinel.conf文件中，使用如下命令设置要监控的master服务器，quorum表示确认客观下线的最少的哨兵数量

sentinel monitor <master-name> <ip> <redis-port> <quorum>

使用如下命令连接master服务的密码

复制代码

sentinel auth-pass <master-name> <password>

其他配置

bash 复制代码

sentinel down-after-milliseconds <master-name> <milliseconds>
指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线

sentinel parallel-syncs <master-name> <nums>：
表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据

sentinel failover-timeout <master-name> <milliseconds>：
故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败

sentinel notification-script <master-name> <script-path> ：
配置当某一事件发生时所需要执行的脚本

sentinel client-reconfig-script <master-name> <script-path>：
客户端重新配置主节点参数脚本

启动哨兵

查看sentinel.log，哨兵启动成功

将主机shutdown模拟主机故障

此时从机get数据时会失去连接，再次get数据重新发起连接，哨兵会从从机中选取新的master

查看主机的sentinel.log，选取了ip为192.168.229.102的从机作为新的master

重新启动原来的主机，可以看到原主机从master变为slave，新的master并不会改变

sdown：主观下线，单个sentinel自己主观上检测到的关于master的状态在发送PING心跳后一定时间内（默认30s）没有收到合法回复

odown：客观下线，多个sentinel达成一致意见认为一个master客观上已经宕机

当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者哨兵，并由该哨兵进行故障迁移

哨兵选取新的master时，优先选取原master的直接slave，如果直接slave不可用，才会去寻找slave的slave

领导者哨兵选取算法------Raft算法

基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者

新master选取机制

选出新的master，在健康的slave中，通过优先级（redis.conf中slave-priority或replica-priority，数字越小优先级越高）、复制偏移量、id三层比较选取新的master

重新认定master，领导者哨兵会对选举出的新master执行slaveof no one；对其他slave发送命令使剩余slave称为新master的slave
原master成为新master的slave，领导者哨兵会让原master降级为slave并恢复正常工作