带你入门Redis 高可用架构之哨兵

哨兵群集的搭建

哨兵本质也是一个 redis 服务，只是跟普通的 redis 服务提供了不一样的功能。哨兵是一个分布式架构，因为你要保证 redis 高可用，首先需要保证自己高可用，所以如果我们需要搭建哨兵的话，最少需要部署三个实例，最好是奇数个，因为在后续的故障转移中会涉及到投票。

哨兵的配置文件我们可以在 redis 的 GitHub 项目下下载，在项目下有一个叫做 sentinel.conf 的文件，可以使用它作为我们哨兵的配置模板，当然你也可以使用 redis.conf 配置文件，只需要添加哨兵相关配置就好了。

哨兵相关的配置项不多，主要有以下几个配置项：

于每个 Sentinel 实例配置除了 port 和 logfile 不同之外，其他配置项都是一样的。修改好配置后，我们可以使用 ./redis-sentinel sentinel.conf 命令来启动哨兵，命令跟 redis 实例启动差不多，因为哨兵也是 redis 实例，所以我们



 

兵信息

问题：如何在只配置 master 服务器的情况下，发现从服务器和其他 Sentinel ?

从服务器的发现，Sentinel 可以通过询问主服务器来获取从服务器的信息，对于发现其他 Sentinel 节点，则通过发布与订阅功能实现，通过向频道 sentinel:hello 发送信息来实现的，主要有以下两步：

1、每个 Sentinel 每 2 秒会通过发布与订阅功能向所有的主服务和从服务器的 sentinel:hello 频道发送一条信息， 信息中包含了 Sentinel 的 IP 地址、端口号和运行 ID (runid)

2、每个 Sentinel 都订阅了被它监视的所有主服务器和从服务器的 sentinel:hello 频道， 查找之前未出现过的 sentinel (looking for unknown sentinels)。当一个 Sentinel 发现一个新的 Sentinel 时， 它会将新的 Sentinel 添加到一个列表中， 这个列表保存了 Sentinel 已知的， 监视同一个主服务器的所有其他 Sentinel

哨兵故障转移原理

故障转移是哨兵的主要工作，这背后的实现逻辑也是非常的复杂，具体的实现逻辑还请查看相关书籍，我对哨兵的故障转移总结了以下三点：

1、监听服务器

每个 Sentinel 节点每隔 1 秒对主节点、从节点、其他 Sentinel 节点发送 ping 命令做心跳检测，来判断服务器的状态。

节点也会对 Sentinel 进行相应的回复，在这些回复中，以下三种回复是有效回复：

• 返回 +PONG
• 返回 -LOADING
• 返回 -MASTERDOWN

如果节点在哨兵配置文件设置的 master-down-after-milliseconds 选项的值内，一直没有哪怕一次有效回复，那么 Sentinel 会把该服务器标记为下线状态，我们把这种下线称为主观下线，也就是说只有这个 sentinel 认为该服务器是下线状态。

如果被主观下线的服务器是主服务器时，sentinel 为了确认这个

（编辑：莆田站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!