redis哨兵机制

目录

前言

1.基本概念

2.安装部署(基于docker)

3.重新选举

4.选举原理

5.总结


前言

        Redis的主从复制模式下,一旦主节点由于故障不能提供服务,需要人工进行主从切换,同时大量的客户端需要被通知切换到新的主节点上,对于上了一定规模的应用来说,这种方案是无法接受的,于是Redis从2.8开始提供了Redis Sentinel (哨兵)加个来解决这个问题。本章主要内容如下:
●Redis Sentinel的概念
●Redis Sentinel的部署
●Redis Sentinel命令
●Redis Sentinel客户端
●Redis Sentinel实现原理

1.基本概念

由于对Redis的许多概念都有不同的名词解释,所以在介绍Redis Sentinel之前,先对几个名词
概念进行必要的说明,如表所示。
Redis Sentinel相关名词解释

Redis Sentinel是Redis的高可用实现方案,在实际的生产环境中,对提高整个系统的高可用是非常有帮助的,本节首先整体梳理主从复制模式下故障处理可能产生的问题,而后引出高可用的概念,最后重点分析Redis Sentinel的基本架构、优势,以及是如何实现高可用的。

主从复制的问题
Redis的主从复制模式可以将主节点的数据改变同步给从节点,这样从节点就可以起到两个作用:
第一,作为主节点的一个备份,一旦主节点出了故障不可达的情况,从节点可以作为后备“顶” 上
来,并且保证数据尽量不丢失(主从复制表现为最终一致性) 。第二,从节点可以分担主节点上的读
压力,让主节点只承担写请求的处理,将所有的读请求负载均衡到各个从节点上。
但是主从复制模式并不是万能的,它同样遗留下以下几个问题:
1.主节点发生故障时,进行主备切换的过程是复杂的,需要完全的人工参与,导致故障恢复时间无法保障。
2.主节点可以将读压力分散出去,但写压力/存储压力是无法被分担的,还是受到单机的限制。
其中第一个问题是高可用问题,即Redis哨兵主要解决的问题。第二个问题是属于存储分布式的问题,留给Redis集群去解决,本章我们集中讨论第一个问题。
人工恢复主节点故障
Redis主从复制模式下,主节点故障后需要进行的人工工作是比较繁琐的,我们在图中大致展示了整体过程。

redis主节点故障后需要进行的操作

1)运维人员通过监控系统,发现Redis主节点故障宕机。
2)运维人员从所有节点中,选择- -个(此处选择了slave 1)执行slaveof no one,使其作为新的主
节点。
3)运维人员让剩余从节点(此处为slave 2)执行slaveof {newMasterlp} {newMasterPort}从新主节
点开始数据同步。
4)更新应用方连接的主节点信息到{newMasterlp} {newMasterPort}。
5)如果原来的主节点恢复,执行slaveof {newMasterlp} {newMasterPort}让其成为一个从节点。
上述过程可以看到基本需要人工介入,无法被认为架构是高可用的。而这就是Redis Sentinel所要做的。

哨兵自动恢复主节点故障
当主节点出现故障时,Redis Sentinel能自动完成故障发现和故障转移,并通知应用方,从而实现
真正的高可用。
Redis Sentinel是一个分布式架构,其中包含若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线表示。如果下线的是主节点,它还会和其他的Sentinel节点进行“协商” ,当大多数Sentinel节点对主节点不可达这个结论达成共识之后,它们会在内部“选举” 出一 个领导节点来完成自动故障转移的工作,同时将这个变化实时通知给Redis应用方。整个过程是完全自动的,不需要人工介入。整体的架构如图所示。

这里的分布式架构是指: Redis 数据节点、Sentinel 节点集合、客户端分布在多个物理节点上,不要与后边章节介绍的Redis Cluster分布式混淆。

Redis Sentinel架构

Redis Sentinel相比于主从复制模式是多了若干(建议保持奇数) Sentinel 节点用于实现监控数据节
点,哨兵节点会定期监控所有节点(包含数据节点和其他哨兵节点)。针对主节点故障的情况,故障
转移流程大致如下:
1) 主节点故障,从节点同步连接中断,主从复制停止。
2)哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进行协商,达成多数认同主节点故障的共识。这步主要是防止该情况:出故障的不是主节点,而是发现故障的哨兵节点,该情况经常发生于哨兵节点的网络被孤立的场景下。
3)哨兵节点之间使用Raft算法选举出一个领导角色,由该节点负责后续的故障转移工作。
4)哨兵领导者开始执行故障转移:从节点中选择一个作为新主节点;让其他从节点同步新主节点;通
知应用层转移到新主节点。

通过上面的介绍,可以看出Redis Sentinel具有以下几个功能:
●监控: Sentinel节点会定期检测Redis数据节点、其余哨兵节点是否可达。
●故障转移:实现从节点晋升(promotion) 为主节点并维护后续正确的主从关系。
●通知:Sentinel节点会将故障转移的结果通知给应用方。

2.安装部署(基于docker)

准备工作
1)安装docker和docker-compose

docker-compose的安装

# ubuntu
apt install docker-compose
# centos
yum install docker-compose

2)停止之前的redis-server

# 停⽌ redis-server
service redis-server stop
# 停⽌ redis-sentinel 如果已经有的话.
service redis-sentinel stop

3)使用docker获取redis镜像

docker pull redis:5.0.9 

编排redis主从节点
1)编写docker-compose. yml
创建 /root/redis/docker-compose. yml ,同时cd到yml所在目录中.
注意: docker中可以通过容器名字,作为ip地址,进行相互之间的访问.

  1 version: '3.7'2 services:3   master:4     image: 'redis:5.0.9'5     container_name: redis-master6     restart: always7     command: redis-server --appendonly yes8     ports:9       - 6379:637910 slave1:11     image: 'redis:5.0.9'12     container_name: redis-slave113     restart: always14     command: redis-server --appendonly yes --slaveof redis-master 637915     ports:16       - 6380:637917 slave2:18     image: 'redis:5.0.9'19     container_name: redis-slave220     restart: always21     command: redis-server --appendonly yes --slaveof redis-master 637922     ports:23       - 6381:6379 

2)启动所有容器

docker-compose up -d

如果启动后发现前面的配置有误,需要重新操作,使用docker-compose down即可停止并删除
刚才创建好的容器.

3)查看运行日志

docker-compose logs 

上述操作必须保证工作目录在yml的同级目录中,才能工作.

4)验证
连接主节点
redis-cli -p 6379

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.22.0.3,port=6379,state=online,offset=348,lag=1
slave1:ip=172.22.0.4,port=6379,state=online,offset=348,lag=1
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:348
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:348

连接从节点
redis-cli -p 6380

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:redis-master
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:446
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:446
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:446

redis-cli -p 6381

127.0.0.1:6381> info replication
# Replication
role:slave
master_host:redis-master
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_repl_offset:516
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:516
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:516

编排redis-sentinel 节点
也可以把redis-sentinel放到和.上面的redis的同一个yml中进行容器编排.此处分成两组,主要是为
了两方面:
●观察日志方便
●确保redis主从节点启动之后才启动redis-sentinel.如果先启动redis-sentinel的话,可能触发额
外的选举过程,混淆视听. (不是说先启动哨兵不行,而是观察的结果可能存在一定随机性).
1)编写docker-compose.yml
创建 /root/redis-sentinel/docker- compose.yml ,同时cd到yml所在目录中.
注意:每个目录中只能存在一个docker-compose.yml文件.

version: '3.7'
services:sentinel1:image: 'redis:5.0.9'container_name: redis-sentinel-1restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel1.conf:/etc/redis/sentinel.confports:- 26379:26379sentinel2:image: 'redis:5.0.9'container_name: redis-sentinel-2restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel2.conf:/etc/redis/sentinel.confports:- 26380:26379sentinel3:image: 'redis:5.0.9'container_name: redis-sentinel-3restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel3.conf:/etc/redis/sentinel.confports:- 26381:26379
networks:default:external:name: redis-data_default

2)创建配置文件
创建sentinel1.conf sentinel2.conf sentinel3.conf . 三份文件的内容是完全相同
的.
都放到/root/redis-sentinel/ 目录中.

bind 0.0.0.0
port 26379
sentinel monitor redis-master redis-master 6379 2
sentinel down-after-milliseconds redis-master 1000

理解 sentinel monitor

sentinel monitor 主节点名 主节点ip 主节点端⼝ 法定票数 

●主节点名,这个是哨兵内部自己起的名字.
●主节点ip,部署redis-master的设备ip.此处由于是使用docker,可以直接写docker的容器名,会被自动DNS成对应的容器ip
●主节点端口,不解释.
●法定票数, 哨兵需要判定主节点是否挂了.但是有的时候可能因为特殊情况,比如主节点仍然工作正常,但是哨兵节点自己网络出问题了,无法访问到主节点了.此时就可能会使该哨兵节点认为主节点
下线,出现误判.使用投票的方式来确定主节点是否真的挂了是更稳妥的做法.需要多个哨兵都认为
主节点挂了,票数>=法定票数之后,才会真的认为主节点是挂了.
理解sentinel down-after-milli seconds
主节点和哨兵之间通过心跳包来进行沟通.如果心跳包在指定的时间内还没回来,就视为是节点出现
故障.

既然内容相同,为啥要创建多份配置文件?
redis-sentinel在运行中可能会对配置进行rewrite,修改文件内容.如果用一份文件,就可能出现修改
混乱的情况.

3)启动所有容器

docker-compose up -d 

如果启动后发现前面的配置有误,需要重新操作,使用docker-compose down 即可停止并删除刚才创建好的容器.

4)查看运行日志

docker-compose logs 

上述操作必须保证工作目录在yml的同级目录中,才能工作.
可以看到,哨兵节点已经通过主节点,认识到了对应的从节点.

5)观察redis-sentinel的配置rewrite
再次打开哨兵的配置文件,发现文件内容已经被自动修改了.

bind 0.0.0.0
port 26379
sentinel myid 4d2d562860b4cdd478e56494a01e5c787246b6aa
sentinel deny-scripts-reconfig yes
# Generated by CONFIG REWRITE
dir "/data"
sentinel monitor redis-master 172.22.0.4 6379 2
sentinel down-after-milliseconds redis-master 1000
sentinel config-epoch redis-master 1
sentinel leader-epoch redis-master 1
sentinel known-replica redis-master 172.22.0.2 6379
sentinel known-replica redis-master 172.22.0.3 6379
sentinel known-sentinel redis-master 172.22.0.7 26379 f718caed536d178f5ea6d1316d
sentinel known-sentinel redis-master 172.22.0.5 26379 2ab6de82279bb77f8397c309d3
sentinel current-epoch 1

# Generated by CONFIG REWRITE这里的内容就是自动修改的.
对比这三份文件,可以看到配置内容是存在差异的.

3.重新选举

redis-master宕机之后
手动把redis-master干掉

docker stop redis-master 

观察哨兵的日志

可以看到哨兵发现了主节点sdown,进一步的由于主节点宕机得票达到3/2 ,达到法定得票,于是
master被判定为odown.
●主观下线(Subjectively Down, SDown):哨兵感知到主节点没心跳了判定为主观下线.
●客观下线(Objectively Down, ODown):多个哨兵达成一致意见,才能认为master确实下线了.
接下来,哨兵们挑选出了一个新的master.在上图中,是172.22. 04:6379这个节点.

此时,对于Redis来说仍然是可以正常使用的.
redis-master重启之后
手动把redis-master 启动起来

docker start redis-master 

观察哨兵日志
可以看到刚才新启动的redis-master 被当成了slave

使用redis-cli也可以进一步的验证这一点

127.0.0.1:6379> info replication
# Replication
role:slave
master_host:172.22.0.4
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:324475
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:ececc285a2892fba157318c77ebe1409f9c2254e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:324475
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:318295
repl_backlog_histlen:6181

结论
●Redis 主节点如果宕机,哨兵会把其中的一个从节点,提拔成主节点.
●当之前的 Redis主节点重启之后,这个主节点被加入到哨兵的监控中,但是只会被作为从节点使用.

4.选举原理

假定当前环境如上方介绍,三个哨兵(sentenal1, sentenal2, sentenal3), 一个主节点(redis-master),两个从节点(redis-slave1, redis-slave2).
当主节点出现故障,就会触发重新一系列过程.

1)主观下线
当redis-master宕机,此时redis- master和三个哨兵之间的心跳包就没有了.
此时,站在三个哨兵的角度来看,redis-master出现严重故障.因此三个哨兵均会把redis-master判定为主观下线(SDown)

2)客观下线
此时,哨兵sentenal1, sentenal2, sentenal3均会对主节点故障这件事情进行投票.当故障得票数>=配置的法定票数之后

sentinel monitor redis-master 172.22.0.4 6379 2 

在这个地方配置的2 ,即为法定票数
此时意味着redis-master故障这个事情被做实了.此时触发客观下线(ODown)

3)选举出哨兵的leader
接下来需要哨兵把剩余的slave中挑选出- -个新的master.这个工作不需要所有的哨兵都参与.只需要
选出个代表(称为leader), 由leader负责进行slave升级到master的提拔过程.
这个选举的过程涉及到Raft算法

假定一共三个哨兵节点,S1,S2, S3
1.每个哨兵节点都给其他所有哨兵节点,发起一一个"拉票请求". (S1->S2, S1->S3, S2-> S1,S2-> S3,S3-> S1,S3-> S2)
2.收到拉票请求的节点,会回复一个"投票响应".响应的结果有两种可能,投or不投.
比如S1给S2发了个投票请求,S2就会给S1返回投票响应.
到底S2是否要投S1呢?取决于S2是否给别人投过票了. (每个哨兵只有一票).
如果S2没有给别人投过票,换而言之,S1是第一个向S2拉票的,那么S2就会投S1.否则则不投.
3. 一轮投票完成之后,发现得票超过半数的节点,自动成为leader.
如果出现平票的情况(S1投S2, S2投S3,S3投S1,每人一票), 就重新再投一次即可.
这也是为啥建议哨兵节点设置成奇数个的原因.如果是偶数个,则增大了平票的概率,带来不必要的开销.
4. leader节点负责挑选一个slave成为新的master.当其他的sentenal发现新的master出现了,就
说明选举结束了.

简而言之,Raft算法的核心就是"先下手为强".谁率先发出了拉票请求,谁就有更大的概率成为leader.
这里的决定因素成 了"网络延时".网络延时本身就带有一定随机性.
具体选出的哪个节点是leader,这个不重要,重要的是能选出一个节点即可.

4) leader挑选出合适的slave成为新的master
挑选规则:
1.比较优先级.优先级高(数值小的)的上位.优先级是配置文件中的配置项( slave-priority或者
replica-priority).
2.比较replication offset谁复制的数据多,高的上位.
3.比较run id,谁的id小,谁上位.

当某个slave节点被指定为master之后,
1. leader 指定该节点执行slave no one ,成为master
2. leader 指定剩余的slave节点,都依附于这个新master

5.总结

●哨兵节点最好是奇数个.方便选举leader,得票更容易超过半数.
●哨兵节点不负责存储数据.仍然是redis主从节点负责存储.
●哨兵+主从复制解决的问题是"提高可用性",不能解决"数据极端情况下写丢失"的问题.
●哨兵+主从复制不能提高数据的存储容量.当我们需要存的数据接近或者超过机器的物理内存,这样的结构就难以胜任了.

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

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

相关文章

MATLAB:数组与矩阵

2.1 数组运算 数组运算时MATLAB计算的基础。由于MATLAB面向对象的特性,这种数值数组称为MATLAN最重要的一种内建数据类型,而数组运算就是定义这种数据结果的方法。 2.1.1 数组的创建和操作 在MATLAB中一般使用方括号“[]”、逗号“,”、空格和分号“;…

详解 CSS 选择器

详解 CSS 选择器 选择器的功能 选中页面中指定的标签元素。 要先选中元素,才能设置元素的属性,就好比策略类指挥游戏,比如海岛奇兵这类的, 需要先选中单位, 再指挥该单位行动。 CSS 选择器的种类 注:以下介绍的选择器只是CSS2标…

Redis分布式锁的正确使用姿势

前言 分布式锁在日常开发中,用处非常的多。包括但不限于抢红包,秒杀,支付下单,幂等,等等场景。 分布式锁的实现方式有多种,包括redis实现,mysql实现,zookeeper实现等等。而其中redis…

【生活】浅浅记录

各位小伙伴们好鸭,今天不是技术文章,浅浅记录一下最近几个月的收获😊 新的一年,一起努力,加油加油!

解决IDEA搜不到插件

File -> Settings -> Plugins https://plugins.jetbrains.com/ 完成以上操作即可搜到插件

R cox回归 ggDCA报错

临床预测模型的决策曲线分析(DCA):基于ggDCA包 决策曲线分析法(decision curve analysis,DCA)是一种评估临床预测模型、诊断试验和分子标记物的简单方法。 我们在传统的诊断试验指标如:敏感性&a…

OpenGL ES (OpenGL) Compute Shader 计算着色器是怎么用的?

OpenGL ES (OpenGL) Compute Shader 是怎么用的? Compute Shader 是 OpenGL ES(以及 OpenGL )中的一种 Shader 程序类型,用于在GPU上执行通用计算任务。与传统的顶点着色器和片段着色器不同,Compute Shader 被设计用于在 GPU 上执行各种通用计算任务,而不是仅仅处理图形…

压缩感知常用的测量矩阵

测量矩阵的基本概念 在压缩感知(Compressed Sensing,CS)理论中,测量矩阵(也称为采样矩阵)是实现信号压缩采样的关键工具。它是一个通常为非方阵的矩阵,用于将信号从高维空间映射到低维空间&…

二蛋赠书十六期:《高效使用Redis:一书学透数据存储与高可用集群》

很多人都遇到过这么一道面试题:Redis是单线程还是多线程?这个问题既简单又复杂。说他简单是因为大多数人都知道Redis是单线程,说复杂是因为这个答案其实并不准确。 难道Redis不是单线程?我们启动一个Redis实例,验证一…

深度学习系列59:文字识别

1. 简单文本: 使用google加的tesseract,效果不错。 首先安装tesseract,在mac直接brew install即可。 python调用代码: import pytesseract from PIL import Image img Image.open(1.png) pytesseract.image_to_string(img, lan…

【算法与数据结构】1971、LeetCode寻找图中是否存在路径

文章目录 一、题目二、解法三、完整代码 所有的LeetCode题解索引,可以看这篇文章——【算法和数据结构】LeetCode题解。 一、题目 二、解法 思路分析:本题应用并查集的理论直接就可以解决:【算法与数据结构】回溯算法、贪心算法、动态规划、图…

相机图像质量研究(35)常见问题总结:图像处理对成像的影响--运动噪声

系列文章目录 相机图像质量研究(1)Camera成像流程介绍 相机图像质量研究(2)ISP专用平台调优介绍 相机图像质量研究(3)图像质量测试介绍 相机图像质量研究(4)常见问题总结:光学结构对成像的影响--焦距 相机图像质量研究(5)常见问题总结:光学结构对成…

Oracle迁移到mysql-表结构的坑

1.mysql中id自增字段必须是整数类型 id BIGINT AUTO_INCREMENT not null, 2.VARCHAR2改为VARCHAR 3.NUMBER(16)改为decimal(16,0) 4.date改为datetime 5.mysql范围分区必须int格式,不能list类型 ERROR 1697 (HY000): VALUES value for partition …

为什么在MOS管开关电路设计中使用三极管容易烧坏?

MOS管作为一种常用的开关元件,具有低导通电阻、高开关速度和低功耗等优点,因此在许多电子设备中广泛应用。然而,在一些特殊情况下,我们需要在MOS管控制电路中加入三极管来实现一些特殊功能。然而,不同于MOS管&#xff…

redis的缓存穿透,缓存并发,缓存雪崩,缓存问题及解决方案

缓存穿透 问题原因 解决方案 缓存并发 缓存雪崩 缓存失效时间设置一致导致的。 解决方案: 1)方案一 2)方案二 如何设计一个缓存策略,缓存热点数据?

网卡本质,网络发展(局域网,广域网概念)

目录 引入 网卡的本质 网络的发展 引入 早期 局域网LAN(Local Area Network) 广域网WAN(Wide Area Network) 注意 引入 前面我们已经学习了很多关于linux系统的知识,其中文件系统和线程尤为繁杂 而网络其实也算系统的一部…

C/C++暴力/枚举/穷举题目持续更新(刷蓝桥杯基础题的进!)

目录 前言 一、百钱买百鸡 二、百元兑钞 三、门牌号码(蓝桥杯真题) 四、相乘(蓝桥杯真题) 五、卡片拼数字(蓝桥杯真题) 六、货物摆放(蓝桥杯真题) 七、最短路径(蓝…

Day20_网络编程(软件结构,网络编程三要素,UDP网络编程,TCP网络编程)

文章目录 Day20 网络编程学习目标1 软件结构2 网络编程三要素2.1 IP地址和域名1、IP地址2、域名3、InetAddress类 2.2 端口号2.3 网络通信协议1、OSI参考模型和TCP/IP参考模型2、UDP协议3、TCP协议 2.4 Socket编程 3 UDP网络编程3.1 DatagramSocket和DatagramPacket1、Datagram…

【Android安全】Windows 环境下载 AOSP 源码

准备环境 安装 git 安装 Python 硬盘剩余容量最好大于 100G 打开 Git Bash,用 git 克隆源代码仓库 git clone https://android.googlesource.com/platform/manifest.git //没有梯子使用清华源 git clone https://aosp.tuna.tsinghua.edu.cn/platform/manifest.git…

fastApi笔记04-查询参数和字符串校验

额外校验 使用Query可以对查询参数添加校验 from typing import Unionfrom fastapi import FastAPI, Queryapp FastAPI()app.get("/items/") async def read_items(q: Union[str, None] Query(defaultNone, max_length50)):results {"items": [{"…