前言
上篇博客谈到了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相关信息

Redis Sentinel启动信息

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

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源码中这两个配置属性常量:

step5、配置RedisTemplate
然后配置RedisTemplate,用于redis命令操作
step6、测试
由于主从复制,Master(48.31)、Slave1(48.32)、Slave0(48.33)能查看到相同的结果:



到此,spring整合redis sentinel完成,完整配置如下:
sentinel故障转移
为验证故障转移,我们关闭Master节点

Sentinel监控日志:

简单解释下日志信息:
- +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:

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

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

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

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