高可用之战:Redis Sentinal(哨兵模式)

Redis24篇集合

1 背景

在我们的《Redis高可用之战:主从架构》篇章中,介绍了Redis的主从架构模式,可以有效的提升Redis服务的可用性,减少甚至避免Redis服务发生完全宕机的可能。
它主要包含如下能力:
1. 故障隔离和恢复:无论主节点或者从节点宕机,其他节点依然可以保证服务的正常运行,并可以手动或自动切换主从。

  • 如果Slave库故障,则读写操作全部走到Master库中
  • 如果Master库故障,则将Slave转成Master库,仅丢失Master库来不及同步到Slave的小部分数据

2. 读写隔离:Master 节点提供写服务,Slave 节点提供读服务,分摊流量压力,均衡流量的负载。
3. 提供高可用保障:主从模式是高可用的最基础版本,也是 sentinel 哨兵模式和 cluster 集群模式实施的前置条件。

主从架构模式虽然很强大,但依然存在一些的问题,我们知道,在衡量系统可用性这方面有个指标叫做MTTR,即平均修复时间。虽然主从模式支持手动切换,但是我们从接收到服务故障预警到手动切换止损到恢复,这可能是一个比较长的过程。这期间的损失将难以计量,对于超高并发大系统是一个绝对灾难。所以我们需要系统能自动的感知到Master故障,并选择一个 Slave 切换为 Master,实现故障自动转移的能力,提升RTO指数。这时候哨兵模式就可以支棱起来了。

平均修复时间(Mean time to repair,MTTR),是描述产品由故障状态转为工作状态时修理时间的平均值。
复原时间目标(Recovery Time Objective,RTO):是描述产品从故障到恢复原状的时间,优质架构要求我们尽量在1分钟左右恢复,一线互联网大厂的高并发场景0容忍。

2 什么是哨兵模式

在实际生产环境中,服务器难免会遇到一些突发状况:服务器宕机,停电,硬件损坏等等,一旦发生,后果不堪设想。
哨兵模式的核心还是主从模式的演变,只不过相对于主从模式,在主节点宕机导致不可写的情况下,多了探活,以及竞选机制:从所有的从节点竞选出新的主节点,然后自动切换。竞选机制的实现,是依赖于在系统中启动Sentinel进程,对各个服务器进行监控。如下图所示:
image

3 哨兵模式的职责能力

哨兵模式作为Redis高可用的一种运行机制,专注于对 Redis 实例(master、slaves)运行状态进行监控,并能够在主节点发生故障时通过一系列的操作,实现新的master竞选、主从切换、故障转移,确保整个 Redis 服务的可用性。

整体来说它有如下能力:

  • 集群监控
  • 故障监测与通知
  • 自动故障转移(主从切换)

3.1 集群监控

哨兵模式的主要任务之一是监控Redis主从复制集群中的各个节点。它会定期检查主节点和从节点的健康状态,确保它们都在正常运行。

3.1.1 前置知识

1. 主观下线(sdown):

  • sdown(主观不可用)是单个哨兵自己主观上检测到的关于Master的状态,从哨兵的角度来看,如果发送PING心跳后,在一定的时间内没有得到应有的回复,就达到了sdown的条件。
  • 哨兵配置文件sentinel.confdown-after-milliseconds属性设置了判断主观下线的回复时间。

image

# sentinel down-after-milliseconds mymaster 30000  默认30s
sentinel down-after-milliseconds <masterName> <timeout>

这种机制是为了保证多个哨兵实例可以一起综合判断,避免单个哨兵(因为自身请求超时、网络抖动等问题)的误判,导致主库被下线。

2. 客观下线 (odown):
上面说了,Master是否下线不是单个Sentinel能够决定的,一般来说需要一定数量的哨兵,多个哨兵达成一致意见才能认为一个Master客观上已经宕机了。
上面的图可以看到,我们一般会有个Sentinel集群 ,这时候这个集群就发挥作用了,通过投票机制,超过指定数量(一般为半数)的Sentinel 都判断了『主观下线』 ,这时候我们就把 Master 标记为『客观下线』,代表它确实不可用了。
投票判定的数量是通过sentinel.conf配置的:

image

# sentinel monitor <master-name> <master-host> <master-port> <quorum>
# 举例如下:
sentinel monitor master 127.0.0.1 6379 2

这条配置项用于告知哨兵需要监听的主节点:
1、sentinel monitor:监控标识
2、mymaster:这边可以放上主节点的名称
3、192.168.11.128 6379:代表监控的主节点 ip,port。6379是redis常规端口。
4、2:判定的sentinel数量,果你有3个 Sentinel,并且 quorum 设置为 2,那么至少需要有2个 Sentinel 认定 Master 节点不可用时(sdown),才会触发故障转移,执行 failover 操作。

image

3.1.2 监控和通信逻辑

1. 哨兵(Sentinel)与主节点(Master)之间

  • Sentinel通过定期(1s一次心跳包)向主节点发送PING命令来检查其状态
  • Sentinel启动后根据配置向Master发送 INFO 指令,获取并保存所有哨兵(Sentinel)状态,主节点(Master)和从节点(Slave)信息。
  • 主节点(Master)会记录所有从节点(Slave)和与它连接的哨兵(Sentinel)实例的信息。

2. 哨兵(Sentinel)与从节点(Slave)之间

  • 从上面得知,Sentinel向Master发送 INFO 命令,并获取所有Slave的信息
  • Sentinel 根据 Master 返回的 Slave 列表,逐个与 Salve 建立连接,同样的定期向从节点发送PING命令来检查它们的状态

3. 集群中的哨兵(sentinel)之间实现通信

使用Redis的pub/sub 订阅能力实现哨兵间通信 和 Slave 发现。

哨兵之间可以相互通信,主要归功于 Redis 的 pub/sub (发布/订阅)机制。Master 有一个 __sentinel__:hello 的专用通信通道,用于哨兵之间发布和订阅消息。哨兵与 Master 建立通信之后,就可以利用 Master 提供发布/订阅机制发布自己的IP、Port等信息,同时订阅其他Sentinel发布的Name、IP、Port消息。

  • Sentinel 建立与 Master 的通信
  • 通过订阅Master的__sentinel__:hello频道,当自身节点启动或更新其状态时,重新发布自己的当前状态和信息(Name、IP、Port消息)
  • 同时订阅其他哨兵发布的Name、IP、Port消息
  • 互相发现之后建立起了连接,后续的消息通信就可以直接进行交互

★ 有没有觉得套路很熟悉,这个与微服务中的服务注册与发现,以及RPC通信类似的做法。请理解清楚图中1、2、3步骤。
image

4. 标记下线的过程
我们上面说过了,Sentinel进程启动之后,会定期(1s一次心跳包)向主节点发送PING命令来检查其状态,检查看状态是否正常响应。

  • 如果Slave 没有在规定的时间内响应 Sentinel 的 PING 命令 , Sentinel 会认为该实例已经挂了,将它tag为下线状态(offline)。
  • 同理,如果Master 没有在规定时间响应 Sentinel 的 PING 命令,也会被判定为 offline 状态,为后续的主从自动切换做好准备工作。

3.2 主从动态切换(故障转移)

当master出现故障之后,Sentinel 的一个很核心的作用,就是从多个Slave中选举出一个新的Master,以达到故障转移的目的。核心步骤如下:

  1. 哨兵会心跳包定时给主节点发送 publish sentinel :hello,如果超时不响应则标记 主观下线(sdown)。超时时间配置 down-after-milliseconds前面说过了。
  2. 哨兵标记主节点 sdown 只是单个哨兵行为,需要往Sentinel集群发布消息说明这个主节点挂了,发送的指令 sentinel is-master-down-by-address-port
  3. 其余的哨兵接收到指令后,也对Master进行探活,如果收不到响应同样标记 sdown,同时发送指令 sentinel is-master-down-by-address-port 到Sentinel内网,这样哨兵内部群会再收到 Master 挂了的消息。
  4. 汇总计票,超过半数(通过quorum配置)就认为Master节点确实不行了,然后修改其状态为 odown, 既客观下线。注意哨兵总数尽量为单数,避免『脑裂』。
  5. 一旦认为主节点odown后,哨兵就会进行选举新Master的工作,这很重要。
  6. 选举新的Master,由指定的哨兵进行选举。选举条件:
    • 响应慢的过滤掉,Sentinel会给所有的Redis从节点发送信息,响应速度慢的就会被优先过滤掉,说明健壮性不够。
    • 判断 offset 偏移量,选择数据偏移量差距最小的,即slave_repl_offsetmaster_repl_offset 的进度差距,其实就是比较 Slave 与 原 Master 复制进度差距。 假如 slave2 的 offset 为90, slave1 偏移量 为100 那么哨兵就会认为slave2的网络不佳,优先选择slave1为新的主节点。
    • slave runID,在优先级和复制进度都相同的情况下,选用runID最小的,runID越小说明创建时间越早,优先选为Master,先来后到原则。

等这几个条件都评估完,我们就会选择出最合适的Slave,把他推举为新的Master。
image

3.3 信息通知

等推选出最新的Master之后,后续所有的写操作都会进入这个Master中。所以需要尽快广播通知到所有的Slave,让他们重新 replacaof 到 Master上,重新建立runIDslave_repl_offset ,来保证数据的正常传输和主从一致性。

4 总结

Redis 哨兵机制是实现 Redis 高可用的核心手段,相比之前的《Redis高可用之战:主从架构》更具自动化和时效性。
它的核心功能职责如下:

  • 集群监控:哨兵模式的主要任务之一是监控Redis主从复制集群中的各个节点。它会定期检查主节点和从节点的健康状态,确保它们都在正常运行。
  • 故障检测与通知:当检测到主节点出现故障或不可用时,哨兵会立即发送报警通知给其他哨兵。这有助于及时发现并处理潜在的问题。
  • 自动故障转移:在检测到主节点故障后,哨兵会自动触发故障转移机制。它会选择一个健康的从节点,将其提升为新的主节点,并通知其他从节点更新复制目标。这样,整个系统可以在主节点故障时保持可用性。
  • 配置更新与通知:在故障转移完成后,哨兵会更新相关配置,并将新的主节点地址通知给客户端。这确保了客户端可以连接到新的主节点并继续进行操作。
posted @ 2024-04-10 09:15  Hello-Brand  阅读(922)  评论(0编辑  收藏  举报