【Redis】哨兵(Sentinel)

哨兵

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

基本概念

由于对 Redis 的许多概念都有不同的名词解释,所以在介绍 Redis Sentinel 之前,先对⼏个名词概念进⾏必要的说明,如表所⽰。

Redis Sentinel 相关名词解释

Redis Sentinel 是 Redis 的⾼可⽤实现⽅案,在实际的⽣产环境中,对提⾼整个系统的⾼可⽤是⾮常有帮助的,本节⾸先整体梳理主从复制模式下故障处理可能产⽣的问题,⽽后引出⾼可⽤的概念,最后重点分析 Redis Sentinel 的基本架构、优势,以及是如何实现⾼可⽤的。

主从复制的问题

Redis 的主从复制模式可以将主节点的数据改变同步给从节点,这样从节点就可以起到两个作⽤:第⼀,作为主节点的⼀个备份,⼀旦主节点出了故障不可达的情况,从节点可以作为后备 "顶" 上来,并且保证数据尽量不丢失(主从复制表现为最终⼀致性)。第⼆,从节点可以分担主节点上的读

压⼒,让主节点只承担写请求的处理,将所有的读请求负载均衡到各个从节点上。

但是主从复制模式并不是万能的,它同样遗留下以下⼏个问题:

  1. 主节点发⽣故障时,进⾏主备切换的过程是复杂的,需要完全的⼈⼯参与,导致故障恢复时间⽆法保障。
  2. 主节点可以将读压⼒分散出去,但写压⼒/存储压⼒是⽆法被分担的,还是受到单机的限制。

其中第⼀个问题是⾼可⽤问题,即 Redis 哨兵主要解决的问题。第⼆个问题是属于存储分布式的问题,留给 Redis 集群去解决,本章我们集中讨论第⼀个问题。

⼈⼯恢复主节点故障

  1. 运维⼈员通过监控系统,发现 Redis 主节点故障宕机。
  2. 运维⼈员从所有节点中,选择⼀个(此处选择了 slave 1)执⾏ slaveof no one,使其作为新的主节点。
  3. 运维⼈员让剩余从节点(此处为 slave 2)执⾏ slaveof {newMasterIp} {newMasterPort} 从新主节点开始数据同步。
  4. 更新应⽤⽅连接的主节点信息到 {newMasterIp} {newMasterPort}。
  5. 如果原来的主节点恢复,执⾏ slaveof {newMasterIp} {newMasterPort} 让其成为⼀个从节点。

上述过程可以看到基本需要⼈⼯介⼊,⽆法被认为架构是⾼可⽤的。⽽这就是 Redis Sentinel 所要做的。

哨兵⾃动恢复主节点故障

当主节点出现故障时,Redis Sentinel 能⾃动完成故障发现和故障转移,并通知应⽤⽅,从⽽实现真正的⾼可⽤。

Redis Sentinel 是⼀个分布式架构,其中包含若⼲个 Sentinel 节点和 Redis 数据节点,每个Sentinel 节点会对数据节点和其余 Sentinel 节点进⾏监控,当它发现节点不可达时,会对节点做下线表⽰。如果下线的是主节点,它还会和其他的 Sentinel 节点进⾏ "协商",当⼤多数 Sentinel 节点对主节点不可达这个结论达成共识之后,它们会在内部 "选举" 出⼀个领导节点来完成⾃动故障转移的⼯作,同时将这个变化实时通知给 Redis 应⽤⽅。整个过程是完全⾃动的,不需要⼈⼯介⼊。整体的架构如图所⽰。

Redis Sentinel 架构

Redis Sentinel 相⽐于主从复制模式是多了若⼲(建议保持奇数)Sentinel 节点⽤于实现监控数据节点,哨兵节点会定期监控所有节点(包含数据节点和其他哨兵节点)。针对主节点故障的情况,故障转移流程⼤致如下:

  1. 主节点故障,从节点同步连接中断,主从复制停⽌。
  2. 哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进⾏协商,达成多数认同主节点故障的共识。这步主要是防⽌该情况:出故障的不是主节点,⽽是发现故障的哨兵节点,该情况经常发⽣于哨兵节点的⽹络被孤⽴的场景下。
  3. 哨兵节点之间使⽤ Raft 算法选举出⼀个领导⻆⾊,由该节点负责后续的故障转移⼯作。
  4. 哨兵领导者开始执⾏故障转移:从节点中选择⼀个作为新主节点;让其他从节点同步新主节点;通知应⽤层转移到新主节点。

通过上⾯的介绍,可以看出 Redis Sentinel 具有以下⼏个功能:

  • 监控: Sentinel 节点会定期检测 Redis 数据节点、其余哨兵节点是否可达。
  • 故障转移: 实现从节点晋升(promotion)为主节点并维护后续正确的主从关系。
  • 通知: Sentinel 节点会将故障转移的结果通知给应⽤⽅。

结论

  • Redis 主节点如果宕机, 哨兵会把其中的⼀个从节点, 提拔成主节点.
  • 当之前的 Redis 主节点重启之后, 这个主节点被加⼊到哨兵的监控中, 但是只会被作为从节点使⽤.

选举原理

假定当前环境如上⽅介绍, 三个哨兵(sentenal1, sentenal2, sentenal3), ⼀个主节点(redis-master), 两个从节点(redis-slave1, redis-slave2).

当主节点出现故障, 就会触发重新⼀系列过程.

  1. 主观下线

当 redis-master 宕机,此时 redis-master 和三个哨兵之间的心跳包就没有了。

此时, 站在三个哨兵的⻆度来看, redis-master 出现严重故障. 因此三个哨兵均会把 redis-master 判定为主观下线 (SDown)

  1. 客观下线

此时, 哨兵 sentenal1, sentenal2, sentenal3 均会对主节点故障这件事情进⾏投票. 当故障得票数 >= 配置的法定票数之后,

sentinel monitor redis-master 172.22.0.4 6379 2

此时意味着 redis-master 故障这个事情被做实了. 此时触发客观下线 (ODown)

  1. 选举出哨兵的 leader

接下来需要哨兵把剩余的 slave 中挑选出⼀个新的 master. 这个⼯作不需要所有的哨兵都参与. 只需要选出个代表 (称为 leader), 由 leader 负责进⾏ slave 升级到 master 的提拔过程.

这个选举的过程涉及到 Raft 算法

假定⼀共三个哨兵节点, S1, S2, S3

  1. 每个哨兵节点都给其他所有哨兵节点, 发起⼀个 "拉票请求". (S1 -> S2, S1 -> S3, S2 -> S1, S2 -> S3,S3 -> S1, S3 -> S2)
  2. 收到拉票请求的节点, 会回复⼀个 "投票响应". 响应的结果有两种可能, 投 or 不投.
  3. ⼀轮投票完成之后, 发现得票超过半数的节点, ⾃动成为 leader.
  4. leader 节点负责挑选⼀个 slave 成为新的 master. 当其他的 sentenal 发现新的 master 出现了, 就说明选举结束了.

简⽽⾔之, Raft 算法的核⼼就是 "先下⼿为强". 谁率先发出了拉票请求, 谁就有更⼤的概率成为 leader.

这⾥的决定因素成了 "⽹络延时". ⽹络延时本⾝就带有⼀定随机性.

  1. leader 挑选出合适的 slave 成为新的 master

挑选规则:

  1. ⽐较优先级. 优先级⾼(数值⼩的)的上位. 优先级是配置⽂件中的配置项( slave-priority 或者replica-priority ).
  2. ⽐较 replication offset 谁复制的数据多, ⾼的上位.
  3. ⽐较 run id , 谁的 id ⼩, 谁上位.

当某个 slave 节点被指定为 master 之后,

  1. leader 指定该节点执⾏ slave no one , 成为 master
  2. leader 指定剩余的 slave 节点, 都依附于这个新 master

小结

上述过程, 都是 "无人值守", redis 自动完成的, 这样做就解决了主节点宕机之后需要人工干预的问题, 提高了系统的稳定性和可用性

注意事项:

  • 哨兵结点不能只有一个, 否则哨兵结点挂了也会影响系统可用性
  • 哨兵节点最好是奇数个, 方便选举 leader, 得票更容易超过半数
  • 哨兵结点不负责存储数据, 仍然是 redis 主从结点负责存储
  • 哨兵 + 主从复制解决的问题是 "提供可用性", 不能解决 "数据极端情况下写丢失" 的问题
  • 哨兵 + 主从复制不能提高数据的存储容量, 当我们需要的存的数据接近聒噪超过机器的物理内存, 这样的结构就难以胜任了.

为了能存储更多的数据, 就引入了集群

相关推荐
MonkeyKing_sunyuhua18 分钟前
ubuntu22.04 docker-compose安装postgresql数据库
数据库·docker·postgresql
天郁青18 分钟前
数据库交互的本地项目:后台管理系统
数据库·交互
马剑威(威哥爱编程)23 分钟前
MongoDB面试专题33道解析
数据库·mongodb·面试
小光学长1 小时前
基于vue框架的的流浪宠物救助系统25128(程序+源码+数据库+调试部署+开发环境)系统界面在最后面。
数据库·vue.js·宠物
掘金-我是哪吒1 小时前
微服务mysql,redis,elasticsearch, kibana,cassandra,mongodb, kafka
redis·mysql·mongodb·elasticsearch·微服务
零炻大礼包2 小时前
【SQL server】数据库远程连接配置
数据库
zmgst2 小时前
canal1.1.7使用canal-adapter进行mysql同步数据
java·数据库·mysql
随心............2 小时前
python操作MySQL以及SQL综合案例
数据库·mysql
€☞扫地僧☜€2 小时前
docker 拉取MySQL8.0镜像以及安装
运维·数据库·docker·容器
CopyDragon2 小时前
设置域名跨越访问
数据库·sqlite