一文读懂 Redis 哨兵

哨兵是什么？

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

俗称，无人值守运维。

干什么？

• 主从监控：监控主从 redis 库运行是否正常

• 消息通知：哨兵可以将故障转移的结果发送给客户端

• 故障转移：将其中一个 Slave 作为新的 Master

• 配置中心：客户端通过连接哨兵来获得当前 Redis 服务的主节点地址

案例

架构

3 个哨兵：自动监控和维护集群，不存放数据，只是吹哨人。

1 主 2 从：用于读取和存放数据

步骤

• 将 redis 安装路径下的 sentinel.conf 拷贝到 myredis 目录下

• 修改配置文件

• 设置要监控的 master 服务器

• quorum：确认客观下线的最少哨兵数量。同意故障迁移的法定票数。

• 设置连接 master 服务的密码

• 我们知道，网络是不可靠的，有时候一个 sentinel 会因为网络堵塞而误以为一个 master redis 已经死掉了，在 sentinel 集群环境下需要多个 sentinel 互相沟通来确认某个 master 是否真的死了，quorum 这个参数是进行客观下线的一个依据，意思是至少有 quorum 个 sentinel 认为这个 master 有故障，才会对这个 master 进行下线以及故障转移。因为有的时候，某个 sentinel 节点可能因为自身网络原因，导致无法连接 master，而此时 master 并没有出现故障，所以，这就需要多个 sentinel 都一致认为该 master 有问题，才可以进行下一步操作，这就保证了公平性和高可用。

安装三台 linux

ip 和 port 分别为

# sentinel00192.168.157.112    26379# sentinel01192.168.157.113    26380# sentinel02192.168.157.118    26381

配置三台哨兵

sentinelxxxx.conf 文件

sentinel00

sentinel26379.conf

bind 0.0.0.0daemonize yesprotected-mode noport 26379logfile "/myredis/sentinel26379.log"pidfile /var/run/redis-sentinel26379.piddir /myredissentinel monitor mymaster 192.168.157.115 6379 2sentinel auth-pass mymaster 1234

sentinel01

sentinel26380.conf

bind 0.0.0.0daemonize yesprotected-mode noport 26380logfile "/myredis/sentinel26380.log"pidfile /var/run/redis-sentinel26380.piddir /myredissentinel monitor mymaster 192.168.157.115 6379 2sentinel auth-pass mymaster 1234

sentinel02

sentinel26381.conf

bind 0.0.0.0daemonize yesprotected-mode noport 26381logfile "/myredis/sentinel26381.log"pidfile /var/run/redis-sentinel26381.piddir /myredissentinel monitor mymaster 192.168.157.115 6379 2sentinel auth-pass mymaster 1234

测试

• 基于之前的 redis 复制，启动 1 主 2 从测试是否主从复制是否正常，输入 info replication 查看是否正常

• 启动三台哨兵，完成监控

• 测试主从复制，一切良好

• 查看日志

• 
  

• 查看配置文件 sentinel.conf

• 后面为自动新增内容

模拟 master 宕机

• master 主机

• 问题

• 两台从机数据是否正常？（yes）

• 会不会从剩下的两台机器中选出新的 master?（yes）

• 之前的 master 重启之后会不会重新上位，重新成为 master？（no）

• salve 获取数据

• 查看新的 master

• 重写启动原 master

• master 不会重新上位。

​

对比配置文件

文件的内容，在运行期间会被 sentinel 动态修改。master—slave 主从关系切换后，配置文件内容会自动发生改变。

• sentinel6379.conf 文件

• 旧 master

• 新 master

​

哨兵运行流程和选举原理

当一个主从配置中的 master 失效后，sentinel 可以选举出一个新的 master 用于自动替换原 master 的工作，主从配置中的其他 redis 服务自动指向新的 master 同步数据，一般建议 sentinel 采取奇数台，防止某一台 sentinel 无法连接到 master 导致误切换。

SDown 主观下线(Subjectively Down)

SDOWN（主观不可用）是单个哨兵自己主观检测到的关于 master 的状态，从 sentinel 的角度来看，如果发送了 PING 心跳后，在一定时间内没有收到合法的回复，就到达了 SDOQN 的条件。

sentinel 配置文件中的 down-after-milliseconds 设置了主观下线的时间长度（默认 30 秒）。

# sentinel down-after-milliseconds <masterName> <timeout>sentinel down-after-milliseconds mymaster 30000

ODown 客观下线(Objectively Down)

ODOWN 需要一定数量的 sentinel，多个哨兵达成一致意见才能确认一个 master 客观上已经宕机了。

# sentinel monitor <master-name> <ip> <redis-port> <quorum>sentinel monitor mymaster 127.0.0.1 6379 2

选举出领导者哨兵

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

领导者哨兵如何选出来的？

Raft 算法

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是 Raft 算法；Raft 算法的基本思路是先到先得，即在一轮选举中，哨兵 A 向 B 发送成为领导者的申请，如果 B 没有同意过其他哨兵，则会同意 A 成为领导者。

选新的 master（im）

整个过程由 sentinel 自己独立完成，无需人工干涉。

新主登基

某一个 slave 被选中成为 master

选出新的 master 的规则，剩余 slave 节点健康的前提下

1. redis.conf 文件中，优先级 slave-priority 或者 replica-priority 最高节点（数字越小优先级越高）

2. 复制偏移量 offset 最大的从节点。

3. 最小 Run ID 的从节点。

群臣俯首

• 执行 slaveof no one 命令让选出来的从节点成为新的主节点，并通过 slaveof 命令让其他节点成为其从节点。

• sentinel leader 会对选举出来的新 master 执行 slaveof no one，将其提升为 master 节点

• sentinel leader 向其他 slave 发送命令，让剩余的 slave 成为新的 master 节点的 slave。

旧主拜服

• 将之前的已经下线的旧 master 设置为新选出的新 master 的从节点，当旧 master 重新上线后，它会成为新 master 的从节点

• sentinel leader 会让原来的 master 降级为 slave 并恢复正常工作。

哨兵使用建议

• 哨兵节点数量应该为多个，哨兵本身应该为集群，保证高可用

• 哨兵节点数量应该是奇数

• 各个哨兵节点的配置应该一致

• 如果哨兵节点部署在 docker 等容器里面，尤其要注意端口的正确映射

• 哨兵集群 + 主从复制，并不能保证数据零丢失