Redis主从复制、哨兵、cluster集群原理+实验(好好等,会晚些,但会更好)(二)

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
简介: Redis主从复制、哨兵、cluster集群原理+实验(好好等,会晚些,但会更好)(二)

二、Redis哨兵模式


主从切换技术的方法是:当服务器宕机后,需要手动一台从机切换为主机,这需要人工干预,不仅费时费力而且还会造成一段时间内服务不可用。为了解决主从复制的缺点,就有了哨兵机制。


哨兵的核心功能:在主从复制的基础上,哨兵引入了主节点的自动故障转移。


2.1 哨兵模式的作用

监控:哨兵会不断地检查主节点和从节点是否运作正常。

自动故障转移:当主节点不能正常工作时,哨兵会开始自动故障转移操,它会将失效主节点的其中一个从节点升级为新的主节点,并让其它从节点改为复制新的主节点。

通知(提醒):哨兵可以将故障转移的结果发送给客户端。

2.2 哨兵结构

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

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

2.3 故障转移机制

1.由哨兵节点定期监控发现主节点是否出现了故障


每个哨兵节点每隔1秒会问主节点、从节点及其它哨兵节点发送一次ping命令做一次心检测。如果主节点在一定时间范围内不回复或者是回复一个错误消息,那么这个哨兵就会认为这个主节点主观下线了(单方面的)。当超过半数哨兵节点认为该主节点主观下线了,这样就客观下线了。


2.当主节点出现故障,此时哨兵节点会通过Raft算法(选举算法)实现选举机制共同选举出一个哨兵节点为leader,来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。


3.由leader哨兵节点执行故障转移,过程如下:


将某一个从节点升级为新的主节点,让其它从节点指向新的主节点;

若原主节点恢复也变成从节点,并指向新的主节点;

通知客户端主节点已经更换。

需要特别注意的是,客观下线是主节点才有的概念;如果从节点和哨兵节点发生故障,被哨兵主观下线后,不会再有后续的客观下线和故障转移操作


2.4 主节点的选举

1.过滤掉不健康的(己下线的),没有回复哨兵ping响应的从节点。


2.选择配置文件中从节点优先级配置最高的。(replica-priority,默认值为100)


3.选择复制偏移量最大,也就是复制最完整的从节点。


哨兵的启动依赖于主从模式,所以须把主从模式安装好的情况下再去做哨兵模式


2.5 搭建Redis哨兵模式


2.5.1 实验环境

主/从/哨兵 虚机 IP地址
master centos7-1 192.168.109.131
slave1 centos7-2 192.168.109.132
slave2 centos7-3 192.168.109.133
Sentinel-1 centos7-4 192.168.109.134
Sentinel-2 centos7-5 192.168.109.135
Sentinel-3 centos7-7 192.168.109.137

生产环境中哨兵节点再使用对应数量节点的服务器作为哨兵节点,实验环境中如果电脑性能不够可以把哨兵搭建在原虚机上


2.5.2 部署主从复制

参照1.3节部署


2.5.3 修改Redis哨兵模式的配置文件(所有哨兵节点操作)

vim /opt/redis-5.0.7/sentinel.conf
......
protected-mode no                #17行,关闭保护模式
port 26379                       #21行,Redis哨兵默认的监听端口
daemonize yes                    #26行,指定sentinel为后台启动
logfile "/var/log/sentinel.log"  #36行,指定日志存放路径
dir "/var/lib/redis/6379"        #65行,指定数据库存放路径
sentinel monitor mymaster 192.168.109.131 6379 2  #84行,修改
#指定该哨兵节点监控192.168.109.131:6379这个主节点,该主节点的名称是mymaster,最后的2的含义与主节点的故障判定有关:至少需要2个哨兵节点同意,才能判定主节点故障并进行故障转移
sentinel down-after-milliseconds mymaster 3000  #113行,判定服务器down掉的时间周期,默认30000毫秒(30秒)
sentinel failover-timeout mymaster 180000  #146行,同一个sentinel对同一个master两次failover之间的间隔时间(180秒)






2.5.3 启动哨兵模式

#启动三台哨兵
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &



2.5.4 查看哨兵信息

redis-cli -p 26379 info Sentinel
#在哨兵节点查看
[root@localhost redis-5.0.7]# redis-cli -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.109.131:6379,slaves=2,sentinels=3
[1]+  完成                  redis-sentinel sentinel.conf


2.5.5 模拟故障

#在Master 上查看redis-server进程号:
[root@localhost ~]# ps -ef | grep redis
root      56591      1  0 09:19 ?        00:00:29 /usr/local/redis/bin/redis-server 0.0.0.0:6379
root      60440  13098  0 16:11 pts/1    00:00:00 grep --color=auto redis
#杀死 Master 节点上redis-server的进程号
[root@localhost ~]# kill -9 56591   #Master节点上redis-server的进程号
[root@localhost ~]# netstat -natp | grep redis
#在哨兵上验证master是转换至从服务器
tail -f /var/log/sentinel.log
[root@localhost redis-5.0.7]# tail -f /var/log/sentinel.log
20000:X 10 Jun 2022 16:12:49.635 # +failover-state-reconf-slaves master mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:49.709 * +slave-reconf-sent slave 192.168.109.133:6379 192.168.109.133 6379 @ mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:50.193 # -odown master mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:50.665 * +slave-reconf-inprog slave 192.168.109.133:6379 192.168.109.133 6379 @ mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:50.665 * +slave-reconf-done slave 192.168.109.133:6379 192.168.109.133 6379 @ mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:50.741 # +failover-end master mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:50.741 # +switch-master mymaster 192.168.109.131 6379 192.168.109.132 6379
20000:X 10 Jun 2022 16:12:50.742 * +slave slave 192.168.109.133:6379 192.168.109.133 6379 @ mymaster 192.168.109.132 6379
20000:X 10 Jun 2022 16:12:50.742 * +slave slave 192.168.109.131:6379 192.168.109.131 6379 @ mymaster 192.168.109.132 6379
20000:X 10 Jun 2022 16:13:20.781 # +sdown slave 192.168.109.131:6379 192.168.109.131 6379 @ mymaster 192.168.109.132 6379
#在哨兵上查看是否转换成功
[root@localhost redis-5.0.7]# redis-cli -p 26379 INFO Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.109.132:6379,slaves=2,sentinels=3



相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
4月前
|
监控 NoSQL Redis
看完这篇就能弄懂Redis的集群的原理了
看完这篇就能弄懂Redis的集群的原理了
141 0
|
2月前
|
存储 NoSQL 大数据
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
35 3
|
3月前
|
NoSQL 网络协议 Redis
Redis的主从复制和哨兵模式
本文详细介绍了Redis的主从复制配置、原理(包括全量复制和增量复制)以及如何搭建一主二从的Redis集群,同时还探讨了Redis哨兵模式的概念、配置文件、以及如何配置一主二从三哨兵的Redis哨兵模式,以实现高可用性。
|
4月前
|
NoSQL Redis
Redis——单机迁移cluster集群如何快速迁移
Redis——单机迁移cluster集群如何快速迁移
139 0
|
2月前
|
存储 缓存 NoSQL
数据的存储--Redis缓存存储(一)
数据的存储--Redis缓存存储(一)
|
2月前
|
存储 缓存 NoSQL
数据的存储--Redis缓存存储(二)
数据的存储--Redis缓存存储(二)
数据的存储--Redis缓存存储(二)
|
2月前
|
消息中间件 缓存 NoSQL
Redis 是一个高性能的键值对存储系统,常用于缓存、消息队列和会话管理等场景。
【10月更文挑战第4天】Redis 是一个高性能的键值对存储系统,常用于缓存、消息队列和会话管理等场景。随着数据增长,有时需要将 Redis 数据导出以进行分析、备份或迁移。本文详细介绍几种导出方法:1)使用 Redis 命令与重定向;2)利用 Redis 的 RDB 和 AOF 持久化功能;3)借助第三方工具如 `redis-dump`。每种方法均附有示例代码,帮助你轻松完成数据导出任务。无论数据量大小,总有一款适合你。
78 6
|
18天前
|
缓存 NoSQL 关系型数据库
大厂面试高频:如何解决Redis缓存雪崩、缓存穿透、缓存并发等5大难题
本文详解缓存雪崩、缓存穿透、缓存并发及缓存预热等问题,提供高可用解决方案,帮助你在大厂面试和实际工作中应对这些常见并发场景。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:如何解决Redis缓存雪崩、缓存穿透、缓存并发等5大难题
|
19天前
|
存储 缓存 NoSQL
【赵渝强老师】基于Redis的旁路缓存架构
本文介绍了引入缓存后的系统架构,通过缓存可以提升访问性能、降低网络拥堵、减轻服务负载和增强可扩展性。文中提供了相关图片和视频讲解,并讨论了数据库读写分离、分库分表等方法来减轻数据库压力。同时,文章也指出了缓存可能带来的复杂度增加、成本提高和数据一致性问题。
【赵渝强老师】基于Redis的旁路缓存架构
|
12天前
|
缓存 NoSQL PHP
Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出
本文深入探讨了Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出。文章还介绍了Redis在页面缓存、数据缓存和会话缓存等应用场景中的使用,并强调了缓存数据一致性、过期时间设置、容量控制和安全问题的重要性。
33 5