【redis】哨兵：人工恢复主节点故障和哨兵自动恢复主节点故障

文章目录

基本概念
人工恢复主节点故障
- 操作流程
哨兵自动恢复主节点故障
- 哨兵集

Redis 的主从复制模式下，⼀旦主节点由于故障不能提供服务，需要⼈⼯进⾏主从切换，同时⼤量的客⼾端需要被通知切换到新的主节点上，对于上了⼀定规模的应⽤来说，这种⽅案是⽆法接受的，于是 Redis 从 2.8 开始提供了 Redis Sentinel（哨兵）加个来解决这个问题。本章主要内容如下：

Redis Sentinel 的概念
Redis Sentinel 的部署
Redis Sentinel 命令
Redis Sentinel 客⼾端
Redis Sentinel 实现原理

基本概念

哨兵机制，是通过独立的进程来体现的，和之前的 redis server 是不同的进程

![[Pasted Image 20250323223036_347.png]]

redis-sentinel：不负责存储数据，只是对其他的 redis-server 进程起到监控作用
通常哨兵节点也会搞一个集合（多个哨兵节点构成），避免单个哨兵挂了

人工恢复主节点故障

在实际开发中，对于服务器后端开发，监控程序是非常必要的

服务器要求有比较高的可用性，7*24 运行
服务器长期运行，总会有一些"意外"，具体什么时候出现意外，我们也不知道，同时，也不能全靠人工来盯着服务器运行
我们就可以写一个程序，用程序来盯着服务器的运行状态------监控程序

往往还需要搭配"报警程序"

发现服务器的运行状态出现状态异常了
给程序员报警，通知程序员，这个服务器挂了/出问题了（短信/电话/邮件/微信/钉钉/飞书...）

操作流程

运维人员通过监控系统，发现 redis 主节点故障宕机，程序员如何恢复？

先看看主节点还能不能抢救，好不好抢救
如果主节点这边是什么原因挂的，不好定位；或者原因知道，但是短时间内难以解决，就要挑一个从节点，设置为新的主节点
1. 把选中的从节点，通过 slaveof no one，自立山头
2. 把其他的从节点，修改 slaveof 的主节点 ip port，连上新的主节点
3. 告知客户端（修改客户端配置），让客户端能够连接新的主节点，用来完成修改数据的操作
- 当前的挂了的主节点，修好了之后，就可以作为一个新的从节点，挂到这组机器中

只要是涉及到人工干预，不说繁琐，至少很烦人。另外，这个操作过程如果出错了的话，可能会导致问题更加严重。通过人工干预的做法，就算程序员第一时间看到了报警信息，第一时间处理，也需要消耗较长时间

哨兵自动恢复主节点故障

哨兵节点集合就是多个单独的 redis sentinel 进程（部署在三台不同的服务器上）
并且这三个哨兵进程，就会监控现有的 redis master 和 slave
- 监控：这些进程之间，会建立 TCP 长连接，通过这样的长连接，定期发送心跳包
借助上述的监控机制，就可以及时发现某个主机是否挂了
- 如果从节点挂了，其实没关系
1. 如果可能是主节点挂了，哨兵就要发挥作用
  - 此时一个哨兵节点发现主节点挂了还不够，需要多个哨兵节点来共同认同这个事情（防止出现误判）
2. 主节点确实挂了，这些哨兵节点中，就会推举出一个 leader，由这个 leader 负责从现有的节点中，挑选一个作为新的主节点
3. 挑选出新的主节点之后，哨兵节点就会自动控制该被选中的节点，执行 slaveof no one，并且控制其他从节点，修改 slaveof 到新的主节点上
4. 哨兵节点会自动的通知客户端程序，告知新的主节点是谁，并且后续客户端再进行写操作，就会针对新的主节点进行操作了

redis 哨兵的核心功能：

监控

自动的故障转移

通知

哨兵集

redis 哨兵节点，有一个也是可以完场上述的需求的

但是：

如果哨兵节点只有一个，其自身也容易出现问题。万一这个哨兵节点挂了，redis 节点也挂了，就无法进行自动的恢复过程了
哨兵节点出现误判的概率也比较高。毕竟网络传输数据是很容易出现延迟或者丢包的，如果只有一个哨兵节点，出现上述问题之后，影响就比较大

哨兵节点最好是奇数个，所以最少也应该是 3 个

基本的原则：在分布式系统中，应该避免使用"单点"（冗余）