redis哨兵模式哨兵挂了(redis哨兵模式哨兵挂了怎么办)

redis哨兵模式哨兵挂了(redis哨兵模式哨兵挂了怎么办)前言 上篇博客谈到了 Spring 整合 redis 集群以及故障转移演示 会发现 redis 集群模式存在一个很明显的问题 当某个主节点及其所有从节点挂掉 整个集群因为缺少该节点负责范围的哈希槽 hash slot 而宕掉 不具高可用性 redis 引入了哨兵 sentinel 模式 能很好解决集群模式存在的不足 引用官网 redis 哨兵系统有三个作用 监控 Monitoring Sentinel 会不断地检查你的主服务器和从服务器是否运作正常 提醒 Notification




前言

上篇博客谈到了Spring整合redis集群以及故障转移演示,会发现redis集群模式存在一个很明显的问题:当某个主节点及其所有从节点挂掉,整个集群因为缺少该节点负责范围的哈希槽(hash slot)而宕掉,不具高可用性。redis引入了哨兵(sentinel)模式,能很好解决集群模式存在的不足。引用官网,redis哨兵系统有三个作用:

  • 监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
  • 提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
  • 自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。

本文主要讲解spring整合redis sentinel及故障转移示例,以此加深理解。

环境准备

笔者已经预先搭建好Redis Sentinel,环境如下:

  • OS:CentOS release 6.5 (Final)
  • Redis版本:4.0.1

客户端连接主节点,查看Redis Master相关信息

WIndows 下 redis 崩溃_spring

Redis Sentinel启动信息

WIndows 下 redis 崩溃_spring_02

客户端连接sentinel节点,查看Redis Sentinel相关信息

WIndows 下 redis 崩溃_服务器_03

spring整合redis sentinel

step1、maven依赖引入
step2、配置ConnectionFactory

构造JedisConnectionFactory实例,注入池配置poolConfig和哨兵配置sentinelConfig

step3、配置JedisPoolConfig

配置文件spring-redis.properties内容

step4、配置RedisSentinelConfiguration

和集群配置一样,sentinel也有两种配置方式

1.sentinels设值注入

2.propertySource构造注入

spring-redis-sentinel.properties内容:

RedisSentinelConfiguration源码中这两个配置属性常量:

WIndows 下 redis 崩溃_spring_04

step5、配置RedisTemplate

然后配置RedisTemplate,用于redis命令操作

step6、测试

由于主从复制,Master(48.31)、Slave1(48.32)、Slave0(48.33)能查看到相同的结果:

WIndows 下 redis 崩溃_WIndows 下 redis 崩溃_05


WIndows 下 redis 崩溃_redis_06


WIndows 下 redis 崩溃_spring_07

到此,spring整合redis sentinel完成,完整配置如下:

sentinel故障转移

为验证故障转移,我们关闭Master节点

WIndows 下 redis 崩溃_服务器_08

Sentinel监控日志:

WIndows 下 redis 崩溃_redis_09

简单解释下日志信息:

  • +sdown 表示监控节点主观下线(单个Sentinel实例对服务器做出的下线判断)
  • +odown 表示监控节点客观下线(多个Sentinel实例对服务器做出的sdown判断),sentinel.config中配置达到2个sdown(quorum参数配置)便判断为客观下线
  • +switch-master 从slave节点中选个作为新的主节点,Slave1(192.168.48.32:6379)

查看该节点信息,发现他的角色已经变为master,原先的Slave0(192.168.48.33:6379)变成新master的slave:

WIndows 下 redis 崩溃_WIndows 下 redis 崩溃_10

接下来再来测试一种情况:在故障节点重启之前发送写命令,故障节点重启后数据是否会复制过来?

结果:

WIndows 下 redis 崩溃_redis_11

重启原来的Master节点(192.168.48.31:6379)

WIndows 下 redis 崩溃_spring_12

原先的Master重启后变成了新Master的从节点了,试着查看foo1的值

WIndows 下 redis 崩溃_spring_13

可见,重启后,新的从节点会复制新的master节点,保证数据一致性。

编程小号
上一篇 2025-07-04 10:06
下一篇 2025-04-04 07:30

相关推荐

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/bian-cheng-ri-ji/72642.html