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地址,以便…

面试经典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 版…

【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…

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

一、快速排序 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;和我们打交道最多…

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

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

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

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

基于Golang客户端实现Nacos服务注册发现和配置管理

基于Golang客户端实现Nacos服务注册发现和配置管理 背景 最近需要把Golang实现的一个web项目集成到基于Spring Cloud Alibaba的微服务体系中&#xff0c;走Spring Cloud Gateway网关路由实现统一的鉴权入口。 软件版本 组件名称组件版本Nacos2.2.0Go1.21.0Ginv1.9.1Nacos-s…

《汇编语言》- 读书笔记 - 第16章-直接定址表

《汇编语言》- 读书笔记 - 第16章-直接定址表 16.1 描述了单元长度的标号&#xff08;数据标号&#xff09;检测点 16.1 16.2 在其他段中使用数据标号assume通过标号取地址检测点 16.2 16.3 直接定址表&#xff08;Direct Addressing Table&#xff09;例1分析代码效果 例2分析…

代购集运公司需要什么样的信息化技术服务|集运系统对接主流电商API接口以实现客户丰富的代购体验

代购集运公司可以考虑以下信息化服务&#xff1a; 1、网络平台 代购集运公司可以建立一个在线平台&#xff0c;让客户能够浏览商品、下单、查询订单状态等操作。 平台也可以提供在线支付和快递跟踪等功能&#xff0c;方便客户和公司的沟通和交流。接入主流电商平台API接口&am…

应用在智能空调触摸屏中的高精度触摸芯片

智能空调是具有自动调节功能的空调。智能空调系统能根据外界气候条件&#xff0c;按照预先设定的指标对温度、湿度、空气清洁度传感器所传来的信号进行分析、判断、及时自动打开制冷、加热、去湿及空气净化等功能的空调。适合放在卧室&#xff0c;客厅等地方。 在中央控制系统…

中国电子学会2021年3月份青少年软件编程Sc ratch图形化等级考试试卷四级真题

【 单选题 】 1.运行如下图所示的程序后&#xff0c;以下描述正确的是&#xff1f; A&#xff1a;角色停留在&#xff08;0,0&#xff09;的位置&#xff0c;不会移动。 B&#xff1a;角色会在舞台上沿水平方向不停地左右往返移动&#xff0c;碰到边缘就反弹。 C&#xff1a…

k8s部署mysql

&#xff08;作者&#xff1a;陈玓玏&#xff09; 一、前置条件 已部署k8s&#xff0c;服务端版本为1.21.14 二、部署mysql 拉取镜像&#xff1b; docker pull mysql将账号密码等信息写到configmap&#xff0c;创建configmap&#xff1b; apiVersion: v1 kind: ConfigM…

亚信安慧AntDB:融合架构下的数据管理利器

AntDB的独特架构将集中式和分布式部署模式巧妙融合&#xff0c;为用户提供了全方位的数据管理解决方案。这种一站式的特性使得用户无需在不同系统间来回切换&#xff0c;极大地提高了工作效率。 AntDB同时具备集中式和分布式系统的优点&#xff0c;集中式架构拥有简单易用、管…

贪心算法练习题(最小化战斗力差距、谈判、纪念品分组、分糖果)

目录 一、贪心算法的介绍 二、贪心算法的实现步骤 三、最小化战斗力差距 四、谈判 五、纪念品分组 六、分糖果 一、贪心算法的介绍 贪心的基本原理:每一步都选择局部最优解&#xff0c;而尽量不考虑对后续的影响&#xff0c;最终达到全局最优解。 贪心的局限性:贪心算法…