本文共 1477 字，大约阅读时间需要 4 分钟。

在redis集群中，当主机宕机了，我们除了手动修复之外，也可以通过配置哨兵（Sentinel），让其自动选举出主机节点，保证集群的可靠性。

例子

哨兵可以 以独立进程的方式，监控着主机和从机的运行情况。如下在redis的配置目录中增加sentinel.conf文件，在文件内输入如下内容：

# sentinel monitor 监视的主机名 ip地址 端口号 sentinel monitor redis6379 127.0.0.1 6379 1

• redis6379，可以自己命名
• 数字1，代表当主机奔溃了，在重新选举出主机的过程中，至少需要1台sentinel进行投票。

接着，在bin目录下，输入如下命令，启动哨兵：

./redis-sentinel /data/fsn/redis6/conf/sentinel.conf

可以看到如下图，哨兵开始监控主机及从机的运行情况：

哨兵模式之下如监听主机

以启动一个哨兵为例，哨兵启动之后，初始化时，会向主机创建两个异步的网络连接：

• 命令连接，用于向主服务器发送命令，并接收命令回复。
• 订阅连接，用于订阅主服务器的sentinel:hello频道。

通过订阅链接，sentinel可以比较及时知道主机及其从机的状况，包括增加新的sentinel监视改主机时，新的sentinel信息可以被现有的sentinel所知道。

默认情况下，Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例（包括主服务器、从服务器、其他Sentinel在内）发送PING命令，并通过实例返回的PING命令来判断实例是否下线。

# 该配置表明主机如果在5000ms内没有进行回复，该Sentinel会认为该主机下线sentinel down-after-milliseconds redis6379 5000

注意，当有多个哨兵时，只有超过半数的哨兵认为该主机下线了，才是真的下线。

哨兵模式之下如选取主机

• 哨兵首先会删除列表中所有处于下线或者断线状态的从服务器，保证剩余的从服务器都是正常在线的。
• 删除列表中所有最近五秒内没有回复过领头Sentinel的INFO命令的从服务器，保证列表中剩余的从服务器都是最近成功进行过通信的。
• 删除所有与已下线主服务器连接断开超过down-after-milliseconds*10
  毫秒的从服务器，保证列表中剩余的从服务器都没有过早地与主服务器断开连接。

down-after-milliseconds: 该选项指定了判断主服务器下线所需的事件

• 领头Sentinel根据从服务器的优先级，对列表中剩余的从服务器进行排序，并选出其中优先级最高的从服务器。如果有多个具有相同最高优先级的从服务器，那么领头Sentinel将按照从服务器的复制偏移量，对具有相同最高优先级的所有从服务器进行排序，并选出其中偏移量最大的从服务器。

关于复制偏移量，可以参靠之前的Redis主从复制一文，偏移量最大的从服务器代表着保存着最新数据的从服务器。

• 如果有多个优先级最高、复制偏移量最大的从服务器，那么领头Sentinel将按照运行ID对这些从服务器进行排序，并选出其中运行ID最小的从服务器。

关于领头Sentinel的说明

当有多个sentinel的时候，对于主机下线后的故障转移工作（包括重新选取主机）是由领头Sentinel完成的。而领头Sentinel同样是通过投票机制进行选取的，只得到超过半数的sentinel认可才能成为领头Sentinel。