Redis 的哨兵机制 --- 兵王是这样选出的

最新推荐文章于 2025-03-26 13:05:02 发布

BUG制造机.

最新推荐文章于 2025-03-26 13:05:02 发布

阅读量600

点赞数 9

分类专栏： Redis 文章标签： redis 数据库缓存

本文链接：https://blog.youkuaiyun.com/weixin_73757824/article/details/145629383

版权

Redis 专栏收录该内容

4 篇文章

订阅专栏

序言

上篇文章我们说到过，Redis 使用了主从复制的机制来保证了相对的高可用，以及使用读写分离缓解了主机的压力。但是，如果我们的主机如果因为各种因素掉线了，此时从机不会主动的去上位当老大，必须我们手动的去提升从机。
如果我们长时间没有及时的去调整，那我们的系统就会一直处于 只可读 的状态，这显然不是合理的。为了更加智能的管理，我们需要额外的机制来监督主机并发生故障的时候及时地替换主机。

一、哨兵集群的架构

哨兵在部署时一般会部署多台并且会采用奇数个，是因为：

不仅避免了单台下线导致监控失效，还避免了因为网络因素误判主机下线
采用奇数个哨兵是因为后续会有投票的过程，尽量避免出现平局的情况

整体的结构如下：
在这里插入图片描述
每隔一定的时间哨兵会向主从设备发送心跳包探测对方的状态。

二、哨兵结点的配置

如果你的系统里面找不到默认的 sentinel.conf 文件，没关系，我们自己配置一个，整体的选项内容没多少个，下面一一介绍：

# 监控主节点（格式：sentinel monitor <主节点名> <IP> <端口> <法定票数>）
# 法定票数（quorum）就是进行故障判定，一般设置为 哨兵数量 / 2 + 1
sentinel monitor mymaster 192.168.1.100 6379 2  

# 主节点密码（若设置）
sentinel auth-pass mymaster your_master_password

# 故障判定时间（毫秒，默认 30 秒）
sentinel down-after-milliseconds mymaster 30000

# 故障转移超时时间（毫秒）
sentinel failover-timeout mymaster 180000

配置好文件之后我们以这样的方式启动服务器端：

redis-server /path/to/sentinel.conf --sentinel

之后我们可以查看日志或者是其他方式来查看是否启动成功，在这里因为笔者手上硬件设备的限制不能很好的演示。

三、哨兵机制的工作原理

首先哨兵结点不负责任何的业务逻辑处理，而专注于四件事：

监控：sentinel 不断检查主从设备是否按照预期工作
通知：可以通知其他的 sentinel 其中一个受监控的 Redis 实例有问题
自动故障转移：明确主机出现问题后，会选出一个 sentinel 来执行故障转移，将一个从机提升为主机并让其他的从机重新认主
配置提供：将新的主机的地址通知到客户端

那么我们围绕着一个完整的过程来尝试理解吧：

1. 监控主从

Redis 哨兵的核心功能之一是监控主节点和从节点的健康状态。哨兵会定期向主节点和从节点发送 PING 请求，并等待响应，以确定节点是否健康。

2. 主观下线

当我们的请求发出在指定时间（down-after-milliseconds）内没有得到回复时，该哨兵会认为主机故障了，这就是主观下线。但是我们需要知道，网络是不可靠的有可能我们的这个信息因为各种因素没有收到，所以不能直接判定该主机确实是故障了，这也是为什么需要多个哨兵的原因。

3. 客观下线

当某个哨兵结点认为主机故障时，会发起一个投票来查看其他哨兵的情况。如果票数的值满足了 quorum，那么我们就客观的认为这个主机确实是故障了。相反，如果票数不满足的话，就不会进一步操作。

4. 兵王之争

现在就需要触发故障转移了，问题来了，哪一个哨兵结点来进行这个操作呢？是发现那个人吗？但是万一两个哨兵同时发现呢？那我们就投投出一个人来吧！
投票的过程大致是如下的，发现主机故障的哨兵会自动变为候选人，候选人会投自己一票，然后向其他的哨兵发起投票请求，当他的票数累积到 quorum 时，他就会通告其他哨兵自己正式成为了 leader。
如果过程是这样的话就好了，但是万一有多个候选人呢？多个候选人会向其他的哨兵发起投票请求，但是每一个人只有一张票。最终如果出现了平局的情况（所以我们一般设置奇数个数量的哨兵避免这个尴尬的情况），那只有再来一次了。