Redis 之六:Redis 的哨兵模式(Sentinel)

Redis 哨兵(Sentinel)模式是一种高可用性解决方案,用于监控和自动故障转移的集群系统。

在 Redis Sentinel 架构中,哨兵是一组运行在特殊模式下的 Redis 进程,它们可以监控一个或多个主从复制结构中的 Redis 主服务器以及其他从服务器的状态。

sentinel 哨兵模式已经被集成在 redis2.4 之后的版本中,哨兵的核心功能是主节点的自动故障转移

特点与工作原理

以下是Redis哨兵模式的主要特点与工作原理:

  1. 监控功能
    • 哨兵会持续不断地通过心跳检测机制检查主节点和其他从节点的健康状态。
    • 如果主节点无法响应,哨兵会根据预设的超时规则判断主节点是否宕机。
  2. 自动故障转移
    • 当哨兵确定主节点不可达后,它会执行自动故障转移操作。
    • 选择一个从节点提升为主节点,并负责更新其他从节点的配置,让它们切换到新的主节点进行同步。
  3. 协商机制
    • 在多个哨兵组成的集群中,哨兵间会相互通信并达成共识,确保只有在足够数量的哨兵同意的情况下才会执行故障转移。
    • 这种多哨兵集群设计增强了系统的鲁棒性和正确性。
  4. 通知机制
    • 哨兵不仅负责故障转移,还会通过发布订阅功能向客户端或者其他系统发送通知,告知Redis主节点的状态变化。
  5. 配置持久化
    • 哨兵会将集群的当前配置信息持久化存储,即使哨兵自身重启也能恢复其监控状态。

通过这种模式,Redis能够实现无中心化的、高可用的服务部署,当主节点出现故障时,能够在无需人工干预的情况下快速恢复服务,保证了Redis服务的稳定性和可靠性。

架构

哨兵节点:哨兵系统由一个或多个哨兵节点组成,哨兵节点是特殊的 Redis 节点,不存储数据。

数据节点:主节点和从节点都是数据节点

作用

哨兵模式在Redis中主要用于提供高可用性和故障恢复功能。具体作用如下:

  1. 监控:哨兵(Sentinel)进程会持续监控主服务器和从服务器的运行状态,包括但不限于检查服务是否正常响应、判断主从复制是否正常进行等。
  2. 自动故障检测与转移:当主服务器发生故障(如宕机或网络断开),哨兵能及时发现并确定主服务器是否真的不可达。如果达到预设条件,哨兵将自动执行故障转移操作,选择一个从服务器升级为主服务器,并通知其他从服务器开始复制新的主节点。
  3. 配置更新:哨兵不仅负责切换主从角色,还会自动更新相关的配置信息,确保整个集群中的所有节点都知道新的主服务器是谁,从而维持集群的正确配置和数据同步。
  4. 系统通知:哨兵可以向管理员或者其他应用程序发送报警信息,报告关于Redis服务器的各种状态变化,通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。
配置步骤

主要操作的文件是 /usr/local/bin/redis-sentinel ;

修改启动配置文件:sentinel.conf

配置文件

复制和修改配置文件

到原 redis 解压目录下复制 sentinel.conf

[root@localhost bin]# ls
dump.rdb  redis81.conf  redis82.conf  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis.conf  redis-sentinel  redis-server  sentinel.conf
[root@localhost bin]# cd /opt/soft/redis-6.0.6/
[root@localhost redis-6.0.6]# ls
00-RELEASENOTES  CONTRIBUTING  deps     Makefile   README.md   runtest          runtest-moduleapi  sentinel.conf  tests   utils
BUGS             COPYING       INSTALL  MANIFESTO  redis.conf  runtest-cluster  runtest-sentinel   src            TLS.md
[root@localhost redis-6.0.6]# cp sentinel.conf /usr/local/bin     ## 把哨兵配置文件 拷贝到 安装目录
cp: overwrite ‘/usr/local/bin/sentinel.conf’? y   
[root@localhost redis-6.0.6]# #### 切换到安装目录 检查
[root@localhost redis-6.0.6]# cd /usr/local/bin/
[root@localhost bin]# ls
dump.rdb  redis81.conf  redis82.conf  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis.conf  redis-sentinel  redis-server  sentinel.conf
[root@localhost bin]# 
监控主节点

编辑修改配置文件,监控主节点

sentinel monitor mymaster 127.0.0.1 6379 1 ###注意监控主节点

修改 把 2 修改为 1。如果有一个哨兵节点认为主节点宕机了,则开始选举机制。

启动哨兵进程

思路:启动三个节点 > 并指定主从关系 > 然后启动哨兵节点来监控主节点

[root@localhost bin]# redis-server redis.conf 
2417:C 05 Aug 2021 20:50:27.725 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2417:C 05 Aug 2021 20:50:27.725 # Redis version=6.0.6, bits=64, commit=00000000, modified=0, pid=2417, just started
2417:C 05 Aug 2021 20:50:27.725 # Configuration loaded
[root@localhost bin]# ^C
[root@localhost bin]# redis-cli -p 6379#### 上面启动成功后,下面查看自己当前角色
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=56,lag=1
slave1:ip=127.0.0.1,port=6382,state=online,offset=56,lag=0
master_replid:2a3410fe212ea06a10413e6c93b59b9746a55d7a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:56
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:56
指定主从节点

启动 6381 端口和6382 端口,并指定从节点:

[root@localhost bin]# redis-cli -p 6381
127.0.0.1:6381> slaveof 127.0.0.1 6379    ####指定主从节点####
OK
127.0.0.1:6381> info replication
# Replication
role:slave                                #####从节点#####
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:42
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:2a3410fe212ea06a10413e6c93b59b9746a55d7a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:42

启动6382 并指定主从节点

[root@localhost bin]# redis-server redis82.conf 
2441:C 05 Aug 2021 20:51:19.197 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2441:C 05 Aug 2021 20:51:19.197 # Redis version=6.0.6, bits=64, commit=00000000, modified=0, pid=2441, just started
2441:C 05 Aug 2021 20:51:19.197 # Configuration loaded
127.0.0.1:6382> slaveof 127.0.0.1 6379
OK
127.0.0.1:6382> info replication
启动哨兵节点

redis-sentinel sentinel.conf

[root@localhost bin]# redis-sentinel sentinel.conf 
2485:X 05 Aug 2021 20:54:16.497 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2485:X 05 Aug 2021 20:54:16.497 # Redis version=6.0.6, bits=64, commit=00000000, modified=0, pid=2485, just started
2485:X 05 Aug 2021 20:54:16.497 # Configuration loaded
2485:X 05 Aug 2021 20:54:16.497 * Increased maximum number of open files to 10032 (it was originally set to 1024).
选举机制

Redis Sentinel(哨兵)模式下的选举

在Redis Sentinel系统中,确实存在一种高级的选举和故障转移机制:

  1. 主观下线(Subjectively Down, SDOWN):单个Sentinel监控到主节点不可达时,标记该节点为SDOWN。
  2. 客观下线(Objectively Down, ODOWN):多个Sentinel(通常是一个多数派集合)都确认主节点不可达时,将主节点状态改为ODOWN。
  3. Leader Sentinel选举:当主节点被确定为ODOWN后,Sentinel集群内部会进行一次Leader Sentinel的选举。这个选举通常是通过协商一致的方式达成,其中一个Sentinel充当领导者并负责执行故障转移操作。
  4. 新主节点选举:Leader Sentinel会根据预定义的规则选择一个从节点作为新的主节点。这可能基于优先级、复制偏移量等因素决定,选择最优的从节点晋升为主节点。
  5. 故障转移与配置更新:选定从节点升级为主节点后,Leader Sentinel会通知其他Sentinel及从节点更新配置信息,使得整个集群重新达到一致状态。

总之,在Redis Sentinel模式下,选举机制主要用于确保即使在主节点发生故障时,也能快速地选出一个新的主节点以恢复服务的可用性,并保证数据的一致性和完整性。

测试选举机制:停止主节点后,哨兵节点会输出日志,监控到变化和启动选举机制

127.0.0.1:6379> shutdown
not connected> quit
2485:X 05 Aug 2021 20:55:34.787 # +sdown master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.787 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
2485:X 05 Aug 2021 20:55:34.787 # +new-epoch 1
2485:X 05 Aug 2021 20:55:34.787 # +try-failover master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.788 # +vote-for-leader fe3f7dda47b7a9ca63194aeaeb31660c30a7316a 1
2485:X 05 Aug 2021 20:55:34.788 # +elected-leader master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.788 # +failover-state-select-slave master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.860 # +selected-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.860 * +failover-state-send-slaveof-noone slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.919 * +failover-state-wait-promotion slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:35.924 # +promoted-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:35.924 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:35.999 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:36.992 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:36.992 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:37.093 # +failover-end master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:37.093 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6382
2485:X 05 Aug 2021 20:55:37.093 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6382
2485:X 05 Aug 2021 20:55:37.093 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6382
2485:X 05 Aug 2021 20:56:07.186 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6382
多哨兵模式

然而一个哨兵进程对 Redis 服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。 各个哨兵之间还会进行监控,这样就形成了多哨兵模式。

多哨兵模式通常指的是在Redis Sentinel(哨兵)系统中部署多个Sentinel节点,以实现对主从复制集群的高可用性和故障转移功能。

优缺点

以下是多哨兵模式的优缺点:

优点:

  1. 高可用性:通过部署多个Sentinel节点,即使有个别Sentinel发生故障,其他Sentinel也能继续监控和管理Redis集群,确保系统的整体稳定性和可用性。
  2. 自动故障检测与恢复:当主服务器出现故障时,多个Sentinel可以通过协商机制达成一致意见,并选举出一个Leader Sentinel执行故障转移操作,将新的主服务器推举出来,从而实现快速恢复服务。
  3. 容错能力增强:由于有多个哨兵并行工作,可以减少单点故障的风险,增加对网络波动、机器宕机等异常情况的容忍度。
  4. 分布式决策:通过投票机制确定主服务器是否下线以及选择哪个从服务器升级为主服务器,避免了单一节点决策可能带来的误判或延迟。

缺点:

  1. 复杂性增加:配置和维护多哨兵架构会比单个哨兵更为复杂,需要考虑哨兵之间的通信、配置一致性等问题。
  2. 资源消耗:每个哨兵都是一个独立运行的进程,因此需要额外的计算资源和网络带宽来支持其运行。
  3. 潜在的问题点增多:随着哨兵数量的增加,可能出现更多潜在的故障点,例如如果所有哨兵同时无法正确监测到主节点状态,可能会导致集群不能正常进行故障切换。
  4. 一致性问题:虽然Sentinel之间通过协议保证了一致性,但在实际部署中,如若配置不当或网络分区等因素,仍有可能引发一致性问题,比如脑裂现象,即不同哨兵群组认为不同的节点是主服务器。

总结来说,多哨兵模式增强了Redis集群的健壮性和可靠性,但也相应增加了管理和运维的复杂度,因此在设计和部署时需要权衡这些因素,确保系统的稳健运行。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/720774.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

小脑萎缩患者必备营养指南

亲爱的读者朋友们,您是否了解小脑萎缩这一疾病?这是一种逐渐发展的神经退行性疾病,对患者的生活质量影响重大。面对这样的挑战,除了必要的医疗干预外,日常饮食和营养管理也扮演着至关重要的角色。今天,让我…

Excel中筛选合并单元格后,只显示第一行怎么办?

Excel中筛选合并单元格后,只显示第一行怎么办? 我们日常的Excel数据在展示的时候为了数据的清晰和美观往往部分相同的单元格进行合并,但是合并之后在筛选时会发现结果会显示异常。 现在我们筛选下国籍为中国的员工信息,发现只显示了一条数据,解决这个异常只需要五Excel步:…

06-prometheus的数据存储

一、本地存储prometheus收集的监控数据 就是将默认的存储,修改为“我们指定”的目录下; 1,配置systemctl启动文件 [rootprometheus-server32 ~]# vim /etc/systemd/system/prometheus-server.service [Unit] DescriptionPrometheus Server D…

站群服务器租用需要考虑哪些?

站群服务器租用是指租用服务器来托管多个网站或应用,通常用于实现网站优化、提高搜索引擎排名等目的。在选择站群服务器租用服务时可以考虑以下几点,RAKsmart小编为您整理发布。 1. 多IP支持:站群服务器应具备多个独立IP地址,以便…

NERF论文笔记(1/2)

NeRF:Representing Scene as Neural Radiance Fields for View Synthesis 笔记 摘要 实现了一个任意视角视图生成算法:输入稀疏的场景图像,通过优化连续的Volumetric场景函数实现;用全连接深度网络表达场景,输入是一个连续的5维…

[Android] MediaPlayer SDK API glance

参考: https://developer.android.com/reference/android/media/MediaPlayer 概述: 音视频的 playback。创建 MediaPlayer 的线程必须和调用 SDK 接口的线程是同一个。注册 callback 给 MediaPlayer SDK 的 thread 必须自带一个 running Looper&#x…

Unity3D 阴影的计算原理详解

前言 阴影是游戏中的重要特效之一,可以增加游戏的真实感和立体感。在Unity3D中,阴影的计算原理主要包括阴影的产生、投影和渲染。 对惹,这里有一个游戏开发交流小组,希望大家可以点击进来一起交流一下开发经验呀! 首…

面试经典150题——逆波兰表达式求值

Man cannot live like a beast, he should pursue knowledge and virtue. -- Dante 1. 题目描述 2. 题目分析与解析 2.1 思路一 这个波兰式我记得在之前上编译原理的时候学过,是对输入的代码进行解析用的。可能有一部分读者对于波兰表达式并不太熟悉,…

对接华泰极速行情丨DolphinDB INSIGHT 插件使用教程

INSIGHT 是华泰证券依托大数据存储、实时分析等领域的技术积累,整合接入国内多家交易所高频行情数据,为投资者提供集行情接入、推送、回测、计算及分析等功能于一体的行情数据服务解决方案。基于 INSIGHT 官方提供的行情数据服务 C SDK(TCP 版…

题目 1476: 蓝桥杯-龟兔赛跑预测

题目描述: 话说这个世界上有各种各样的兔子和乌龟,但是 研究发现,所有的兔子和乌龟都有一个共同的特点——喜欢赛跑。于是世界上各个角落都不断在发生着乌龟和兔子的比赛,小华对此很感兴趣,于是决定研究不同兔 子和乌龟的赛跑。…

【FastChat】用于训练、服务和评估大型语言模型的开放平台

FastChat 用于训练、服务和评估大型语言模型的开放平台。发布 Vicuna 和 Chatbot Arena 的存储库。 隆重推出 Vicuna,一款令人印象深刻的开源聊天机器人 GPT-4! 🚀 根据 GPT-4 的评估,Vicuna 达到了 ChatGPT/Bard 90%* 的质量&…

最短路径Floyd算法

第一题&#xff1a;[USACO08OPEN] Clear And Present Danger S #include<bits/stdc.h> using namespace std; int n,m; int g[105][105]; int arr[100005]; long long sum; int main() {scanf("%d%d",&n,&m);for(int i1;i<m;i){scanf("%d"…

聚观早报 | 2024款腾势D9将发布;岚图汽车2月销量

聚观早报每日整理最值得关注的行业重点事件&#xff0c;帮助大家及时了解最新行业动态&#xff0c;每日读报&#xff0c;就读聚观365资讯简报。 整理丨Cutie 3月2日消息 2024款腾势D9将发布 岚图汽车2月销量 苹果Vision Pro防汗新专利 真我12 Pro正式开售 Redmi K70/Pro…

​LeetCode解法汇总232. 用栈实现队列

目录链接&#xff1a; 力扣编程题-解法汇总_分享记录-CSDN博客 GitHub同步刷题项目&#xff1a; GitHub - September26/java-algorithms: 算法题汇总&#xff0c;包含牛客&#xff0c;leetCode&#xff0c;lintCode等网站题目的解法和代码&#xff0c;以及完整的mode类&#…

终极排序(快排,归并,库函数)

一、快速排序 1、确定分界点&#xff1a;q [ l ] , q [ ( l r ) / 2 ] , q [ r ] ,或者其它区间之中的随机数。&#xff08;左 l 右 r &#xff09; 2、调整区间&#xff1a;&#xff08;较难理解的部分&#xff09; &#xff08;1&#xff09;、暴力做法 …

Linux 学习笔记(12)

十二、 系统服务 1 、系统服务分类&#xff0c;根据其使用的方法来分&#xff0c;可以被分为三类 a、由 init 控制的服务&#xff1a;基本都是系统级别的服务&#xff0c;运行级别这一章讲的就是这一类的服务 b、由 System V 启动脚本启动的服务&#xff1a;和我们打交道最多…

Spring Security-快速开始(Spring Security 身份认证流程)

文章目录 spring security基本原理springSecurity 拦截器链Spring Security 的核心元素spring security如何进行用户认证(重要)spring security使用流程demo@EnableWebSecurity 注解@EnableGlobalMethodSecurity 注解spring security controller层实现登陆spring security 自定…

爬虫入门到精通_实战篇10(使用Redis+Flask维护动态代理池)

1 目标 为什么要用代理池 许多网站有专门的反爬虫措施&#xff0c;可能遇到封IP等问题。互联网上公开了大量免费代理&#xff0c;利用好资源。通过定时的检测维护同样可以得到多个可用代理。 代理池的要求 多站抓取&#xff0c;异步检测定时筛选&#xff0c;持续更新提供接…

自然语言处理(NLP)

自然语言处理&#xff08;NLP&#xff09;技术是研究和开发使计算机能够理解和处理人类语言的方法。下面是几个例子说明NLP技术的应用&#xff1a; 语音识别&#xff1a;语音识别技术允许计算机将人类的口头语言转换为机器可理解的文本。例如&#xff0c;智能助理如Siri和Alexa…

Linux系统部署Discuz论坛并发布至公网随时随地可远程访问

目录 ​编辑 前言 1.安装基础环境 2.一键部署Discuz 3.安装cpolar工具 4.配置域名访问Discuz 5.固定域名公网地址 6.配置Discuz论坛 结语 作者简介&#xff1a; 懒大王敲代码&#xff0c;计算机专业应届生 今天给大家聊聊Linux系统部署Discuz论坛并发布至公网随时随地…