高可用之战:Redis Sentinal(哨兵模式)
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进程,对各个服务器进行监控。如下图所示:
3 哨兵模式的职责能力
哨兵模式作为Redis高可用的一种运行机制,专注于对 Redis 实例(master、slaves)运行状态进行监控,并能够在主节点发生故障时通过一系列的操作,实现新的master竞选、主从切换、故障转移,确保整个 Redis 服务的可用性。
整体来说它有如下能力:
- 集群监控
- 故障监测与通知
- 自动故障转移(主从切换)
3.1 集群监控
哨兵模式的主要任务之一是监控Redis主从复制集群中的各个节点。它会定期检查主节点和从节点的健康状态,确保它们都在正常运行。
3.1.1 前置知识
1. 主观下线(sdown):
- sdown(主观不可用)是单个哨兵自己主观上检测到的关于Master的状态,从哨兵的角度来看,如果发送PING心跳后,在一定的时间内没有得到应有的回复,就达到了sdown的条件。
- 哨兵配置文件
sentinel.conf
中down-after-milliseconds
属性设置了判断主观下线的回复时间。
# sentinel down-after-milliseconds mymaster 30000 默认30s
sentinel down-after-milliseconds <masterName> <timeout>
这种机制是为了保证多个哨兵实例可以一起综合判断,避免单个哨兵(因为自身请求超时、网络抖动等问题)的误判,导致主库被下线。
2. 客观下线 (odown):
上面说了,Master是否下线不是单个Sentinel能够决定的,一般来说需要一定数量的哨兵,多个哨兵达成一致意见才能认为一个Master客观上已经宕机了。
上面的图可以看到,我们一般会有个Sentinel集群 ,这时候这个集群就发挥作用了,通过投票机制,超过指定数量(一般为半数)的Sentinel 都判断了『主观下线』 ,这时候我们就把 Master 标记为『客观下线』,代表它确实不可用了。
投票判定的数量是通过sentinel.conf
配置的:
# 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 操作。
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步骤。
4. 标记下线的过程
我们上面说过了,Sentinel进程启动之后,会定期(1s一次心跳包)向主节点发送PING命令来检查其状态,检查看状态是否正常响应。
- 如果Slave 没有在规定的时间内响应 Sentinel 的 PING 命令 , Sentinel 会认为该实例已经挂了,将它tag为下线状态(offline)。
- 同理,如果Master 没有在规定时间响应 Sentinel 的 PING 命令,也会被判定为 offline 状态,为后续的主从自动切换做好准备工作。
3.2 主从动态切换(故障转移)
当master出现故障之后,Sentinel 的一个很核心的作用,就是从多个Slave中选举出一个新的Master,以达到故障转移的目的。核心步骤如下:
- 哨兵会心跳包定时给主节点发送
publish sentinel :hello
,如果超时不响应则标记 主观下线(sdown)。超时时间配置down-after-milliseconds
前面说过了。 - 哨兵标记主节点 sdown 只是单个哨兵行为,需要往Sentinel集群发布消息说明这个主节点挂了,发送的指令
sentinel is-master-down-by-address-port
。 - 其余的哨兵接收到指令后,也对Master进行探活,如果收不到响应同样标记
sdown
,同时发送指令sentinel is-master-down-by-address-port
到Sentinel内网,这样哨兵内部群会再收到 Master 挂了的消息。 - 汇总计票,超过半数(通过
quorum
配置)就认为Master节点确实不行了,然后修改其状态为odown
, 既客观下线。注意哨兵总数尽量为单数,避免『脑裂』。 - 一旦认为主节点
odown
后,哨兵就会进行选举新Master的工作,这很重要。 - 选举新的Master,由指定的哨兵进行选举。选举条件:
- 响应慢的过滤掉,Sentinel会给所有的Redis从节点发送信息,响应速度慢的就会被优先过滤掉,说明健壮性不够。
- 判断 offset 偏移量,选择数据偏移量差距最小的,即
slave_repl_offset
与master_repl_offset
的进度差距,其实就是比较 Slave 与 原 Master 复制进度差距。 假如 slave2 的 offset 为90, slave1 偏移量 为100 那么哨兵就会认为slave2的网络不佳,优先选择slave1为新的主节点。 - slave runID,在优先级和复制进度都相同的情况下,选用runID最小的,runID越小说明创建时间越早,优先选为Master,先来后到原则。
等这几个条件都评估完,我们就会选择出最合适的Slave,把他推举为新的Master。
3.3 信息通知
等推选出最新的Master之后,后续所有的写操作都会进入这个Master中。所以需要尽快广播通知到所有的Slave,让他们重新 replacaof
到 Master上,重新建立runID
和slave_repl_offset
,来保证数据的正常传输和主从一致性。
4 总结
Redis 哨兵机制是实现 Redis 高可用的核心手段,相比之前的《Redis高可用之战:主从架构》更具自动化和时效性。
它的核心功能职责如下:
- 集群监控:哨兵模式的主要任务之一是监控Redis主从复制集群中的各个节点。它会定期检查主节点和从节点的健康状态,确保它们都在正常运行。
- 故障检测与通知:当检测到主节点出现故障或不可用时,哨兵会立即发送报警通知给其他哨兵。这有助于及时发现并处理潜在的问题。
- 自动故障转移:在检测到主节点故障后,哨兵会自动触发故障转移机制。它会选择一个健康的从节点,将其提升为新的主节点,并通知其他从节点更新复制目标。这样,整个系统可以在主节点故障时保持可用性。
- 配置更新与通知:在故障转移完成后,哨兵会更新相关配置,并将新的主节点地址通知给客户端。这确保了客户端可以连接到新的主节点并继续进行操作。
高可用之战:Redis Sentinal(哨兵模式)的更多相关文章
- Redis-Sentinel Redis的哨兵模式
Redis-Sentinel Redis的哨兵模式Redis Sentinel 模式简介Redis-Sentinel是官方推荐的高可用解决方案,当redis在做master-slave的高可用方案时, ...
- Redis进阶:Redis的哨兵模式搭建
Redis进阶:Redis的哨兵模式搭建 哨兵机制介绍 单机版的Redis存在性能瓶颈,Redis通过提高主从复制实现读写分离,提高了了Redis的可用性,另一方便也能实现数据在多个Redis直接的备 ...
- redis的哨兵模式
我是在一台服务器上安装了三个redis 一主两从 想安装gcc gcc-c++ make tcl lrzsz yum -y install gcc gcc-c++ make tcl lrzsz ...
- redis主从+redis的哨兵模式
三台机器分布 192.168.189.129 // master的角色 192.168.189.130 // slave1的角色 192.168.189.131 // salve2的角色 ...
- Nginx+keepalived 高可用双机热备(主从模式/双主模式)
基础介绍负载均衡技术对于一个网站尤其是大型网站的web服务器集群来说是至关重要的!做好负载均衡架构,可以实现故障转移和高可用环境,避免单点故障,保证网站健康持续运行. 关于负载均衡介绍,可以参考:li ...
- redis主从+哨兵模式(借鉴)
三台机器分布 192.168.189.129 // master的角色 192.168.189.130 // slave1的角色 192.168.189.131 // salve2的角色 ...
- redis主从+ 哨兵模式(sentinel)+漂移VIP实现高可用系统
原文:https://www.jianshu.com/p/c2ab606b00b7 客户端程序 客户端程序(如PHP程序)连接redis时需要ip和port,但redis-server进行故障转移时, ...
- redis架构~哨兵模式
一 哨兵模式稳定版本 redis哨兵模式是redis自带的高可用框架,稳定版本为redis2.8以上二 哨兵模式建立 1 避免单点故障,建立启动多个哨兵进程 2 哨兵模式启动命令 redis-s ...
- redis主从+哨兵模式
主从模式配置分为手动和配置文件两种方式进行配置,我现在有192.168.238.128(CentOS1).192.168.238.131(CentOS3).192.168.238.132(CentOS ...
- 【集群】Redis的哨兵模式和集群模式
哨兵模式 哨兵模式是redis高可用的实现方式之一 使用一个或者多个哨兵(Sentinel)实例组成的系统,对redis节点进行监控,在主节点出现故障的情况下,能将从节点中的一个升级为主节点,进行故障 ...
随机推荐
- java字节、位移以及进制转换
数据存储方式 众所周知,java中的数据都是以二进制的形式存储在计算机中的,但是我们看到的数据怎么是10进制的,因为java提供了很多进制自动转换的方式. 位移 向左位移是*2的幂次,一般都是正数操作 ...
- 【Azure 环境】通过Python SDK收集所有订阅简略信息,例如订阅id 名称, 资源组及组内资源信息等,如何给Python应用赋予相应的权限才能获取到信息呢?
问题描述 通过Python SDK收集所有订阅简略信息,例如订阅id 名称, 资源组及组内资源信息等,如何给Python应用赋予相应的权限才能获取到信息呢?在一个企业的账号中,同一个组织有一个相同的 ...
- protocol buffer 知识整理(备份)
定义消息: 最简单的例子: 1 // 下面是a.proto文件的内容 2 syntax = "proto3"; //必须指明proto3,否则会被认为是proto2 3 ...
- [程序] C++实现 http和https的反向代理程序
目录 前言 代理原理 http代理 https代理 实现 客户端 服务端 遇到的所有问题记录 Python对于回复不响应 接受的数据只有4字节 最终数据已经发给Python了 但是Python还是阻塞 ...
- Java 多态 案列
1 package com.bytezreo.duotai; 2 3 //多态性的使用 举例一 4 public class AnimalTest 5 { 6 public static void m ...
- Redis单线程为什么如此之快
一.概述 Redis的高并发和快简单可以归结为一下几点: 1.Redis是基于内存的: 2.Redis是单线程的: 3.Redis使用多路复用技术. 4.高效的数据结构 但具体怎么做的呢,下面来详细看 ...
- 精贴总结 - 万字长文带你入门Istio
原文 - 万字长文带你入门Istio 一.个人看法 背景:以docker+k8s普及,支持快速部署,通过k8s允许统一管理 解决:1)设计分布式系统,导致开发难度提高:2)统一多语言的服务治理方案 目 ...
- 没有 Release 文件的解决方法
https://blog.csdn.net/weixin_44903509/article/details/108825738 sudo apt-get update 出现问题 E: 仓库 " ...
- Python中的join()函数的用法实例分析
一.join()函数 语法: 'sep'.join(seq) 参数说明sep:分隔符.可以为空seq:要连接的元素序列.字符串.元组.字典上面的语法即:以sep作为分隔符,将seq所有的元素合并成一 ...
- 基于python源码的啸叫抑制算法解析
一 原理解析 从下图一中可以看出,该算法的原理也是先检测出来啸叫,然后通过陷波器来进行啸叫抑制的,和笔者以前分析的所用方法基本耦合. 二 源码分析 函数PAPR:计算峰值功率和平均功率的比 ...