Redis 之六：Redis 的哨兵模式（Sentinel）

news2024/12/23 3:05:35

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.coloradmin.cn/o/1482322.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

泵站远程监控：智能化水利管理

泵站远程监控：智能化水利管理

一、泵站远程监控的背景与意义 泵站作为水利工程的重要设施，承担着灌溉、排水、供水等多重任务，是保障农业生产和城市供水的重要基础设施。然而，传统的泵站管理模式往往依赖于人工巡检和现场操作，这种方式不仅效率低下&#xff0c…
阅读更多...
基于SSM的高校竞赛和考级查询系统（有报告）。Javaee项目。ssm项目。

基于SSM的高校竞赛和考级查询系统（有报告）。Javaee项目。ssm项目。

演示视频： 基于SSM的高校竞赛和考级查询系统（有报告）。Javaee项目。ssm项目。 项目介绍： 采用M（model）V（view）C（controller）三层体系结构，通过Sp…
阅读更多...
如何安装ProtoBuf环境

如何安装ProtoBuf环境

1 🍑下载 ProtoBuf🍑 下载 ProtoBuf 前⼀定要安装依赖库：autoconf automake libtool curl make g unzip 如未安装，安装命令如下： Ubuntu ⽤⼾选择： sudo apt-get install autoconf automake libtool cur…
阅读更多...
NXP实战笔记（十一）：32K3xx基于RTD-SDK在S32DS上配置LPSPI(同步、异步、DMA、主机、从机、中断、轮询)

NXP实战笔记（十一）：32K3xx基于RTD-SDK在S32DS上配置LPSPI(同步、异步、DMA、主机、从机、中断、轮询)

目录 1、概述 2、RTD-SDK配置 2.1、配置目标 2.2、主、从机引脚配置 2.3、时钟配置 2.4、LPSPI配置 2.5、中断配置 2.6、DMA配置（使用DMA才会配置） 2、dma Logic Instance 2.7、RM配置（使用DMA的情况下必须配置此选项） 3、代码实现 1、概述 S32K3_低功耗LPSPI轮询…
阅读更多...
golang goroutine 如何退出？

golang goroutine 如何退出？

上一讲说到调度器将maingoroutine推上舞台，为它铺好了道路，开始执行runtime.main函数。这一讲，我们探索maingoroutine以及普通goroutine从执行到退出的整个过程。 //Themaingoroutine. funcmain(){ //gmaingoroutine，不再是g0了 …
阅读更多...
前端学习第三天-css基础

前端学习第三天-css基础

1. CSS简介 从HTML被发明开始，样式就以各种形式存在。不同的浏览器结合它们各自的样式语言为用户提供页面效果的控制。最初的HTML只包含很少的显示属性。 随着HTML的成长，为了满足页面设计者的要求，HTML添加了很多显示功能。但是随着这些功能…
阅读更多...
Linux命令行与shell脚本编程大全-2.2

Linux命令行与shell脚本编程大全-2.2

第二部分 shell脚本编程基础 第11章构建基础脚本 第12章结构化命令 第13章更多的结构化命令 第14章处理用户输入 第15章呈现数据 第16章脚本控制 第15章 呈现数据 15.1 理解输入和输出 15.1.1 标准文件描述符 Linux 系统会将每个对象当作文件来处理，这包括输入和…
阅读更多...
TCP为什么要三次握手？

TCP为什么要三次握手？

TCP三次握手协议是为了在不可靠的互联网环境中可靠地建立起一个连接，三次握手可以确保两端的发送和接收能力都是正常的。 那么，为什么是三次而不是二次或四次握手呢？ 为什么不是二次握手？ 如果是二次握手，即客户端发…
阅读更多...
带着问题阅读源码——Spring MVC是如何将url注册到RequestMappingHandlerMapping？

带着问题阅读源码——Spring MVC是如何将url注册到RequestMappingHandlerMapping？

背景 在 Spring MVC 中，DispatcherServlet 是前端控制器（front controller），它负责接收所有的 HTTP 请求并将它们映射到相应的处理器（handler）。为了实现这一点，Spring MVC 使用了适配器模式将…
阅读更多...
设计模式-结构型模式-外观模式

设计模式-结构型模式-外观模式

外观模式（Facade），为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。[DP] 首先，定义子系统的各个组件接口和具体实现类： // 子系统组件接…
阅读更多...
MySQL 用了哪种默认隔离级别，实现原理是什么？

MySQL 用了哪种默认隔离级别，实现原理是什么？

MySQL 的默认隔离级别是 RR - 可重复读，可以通过命令来查看 MySQL 中的默认隔离级别。 RR - 可重复读是基于多版本并发控制（Multi-Version Concurrency Control，MVCC ）实现的。MVCC，在读取数据时通过一种类似快照的方…
阅读更多...
if语句用法

if语句用法

if语句是单条件分支语句 定义：根据一个条件来控制程序执行流程(如图3.2)。 语法格式： if（表达式）{ 若干语句 } ★注意★： ① 表达式的值必须是boolean 型； ② 不能用0代表false；用1代表 true&am…
阅读更多...
qt 5.15版本安装

qt 5.15版本安装

1.qt5.15版本安装 2.安装慢时，切换到清华镜像源：.\qt-unified-windows-x64-online.exe --mirror https://mirrors.tuna.tsinghua.edu.cn/qt/ 3.没有qt 5.15版本在旁边进行筛选，只选archive
阅读更多...
MySql外连接

MySql外连接

目录 数据准备外连接 数据准备 -- 部门表 create table tb_dept (id int unsigned primary key auto_increment comment 主键ID,name varchar(10) not null unique comment 部门名称,create_time datetime not null comment 创建时间,update_time datetime…
阅读更多...
ABB双语言共享充电宝投资理财源码/共享充电宝系统源码/共享充电宝市场分析/五级分销返利+地图显示模式

ABB双语言共享充电宝投资理财源码/共享充电宝系统源码/共享充电宝市场分析/五级分销返利+地图显示模式

ABB双语言共享充电宝投资理财源码/五级分销返利地图显示模式/vue编译后前端 测试环境：Linux系统CentOS7.6、宝塔、PHP7.3、MySQL5.6，根目录public，伪静态laravel5， 源码下载：https://download.csdn.net/download/m0_…
阅读更多...
2022年CSP-J认证 CCF信息学奥赛C++ 中小学初级组 第一轮真题-完善程序题解析

2022年CSP-J认证 CCF信息学奥赛C++ 中小学初级组 第一轮真题-完善程序题解析

2022CCF认证第一轮&#xff08;CSP-J&#xff09;真题 三、完善程序题 第一题 枚举因数 从小到大打印正整数n的所有正因数。试补全枚举程序 #include <iostream> using namespace std;int main(){int n;cin >> n;vector<int> fac;fac.reserve((int)ceil(…
阅读更多...
备战蓝桥杯---线段树基础1

备战蓝桥杯---线段树基础1

引入&#xff1a;RMQ问题&#xff1a; 什么是RMQ&#xff1f; 显然&#xff0c;我们无法用前缀维护&#xff0c;因此&#xff0c;我们需要用到线段树的知识&#xff1a; 什么是线段树&#xff1f; 线段树是用一种树状结构存储一个连续区间信息的数据结构 下面我们用图解释用…
阅读更多...
2024全国水科技大会暨高氨氮废水厌氧氨氧化处理技术论坛（四）

2024全国水科技大会暨高氨氮废水厌氧氨氧化处理技术论坛（四）

一、会议背景 为积极应对“十四五”期间我国生态环境治理面临的挑战&#xff0c;加快生态环境科技创新&#xff0c;构建绿色技术创新体系&#xff0c;全面落实科学技术部、生态环境部等部委编制的《“十四五”生态环境领域科技创新专项规划》&#xff0c;积极落实省校合作&…
阅读更多...
物联网与智慧城市的融合：构建智能化、便捷化、绿色化的城市未来

物联网与智慧城市的融合：构建智能化、便捷化、绿色化的城市未来

一、引言 随着科技的飞速发展和城市化的不断推进&#xff0c;物联网技术正逐步渗透到城市的各个领域&#xff0c;成为推动智慧城市建设的核心力量。物联网与智慧城市的融合&#xff0c;不仅为城市治理提供了高效、智能的解决方案&#xff0c;也为市民的生活带来了前所未有的便…
阅读更多...
Docker Swarm全解析：实现微服务高可用与故障转移的秘密武器

Docker Swarm全解析：实现微服务高可用与故障转移的秘密武器

&#x1f407;明明跟你说过&#xff1a;个人主页 &#x1f3c5;个人专栏&#xff1a;《Docker入门到精通》 《k8s入门到实战》&#x1f3c5; &#x1f516;行路有良友&#xff0c;便是天堂&#x1f516; 目录 一、基本概念和介绍 1、Docker Swarm 是什么&#xff0c;它与 …
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023