redis sentinel 配置
2016-04-19 20:10
357 查看
在最小配置:master、slave各一个节点的情况下,不管是master还是slave down掉一个,“完整的”读/写功能都将受影响,这在生产环境中显然不能接受。幸好redis提供了sentinel(哨兵)机制,通过sentinel模式启动redis后,自动监控master/slave的运行状态,基本原理是:心跳机制+投票裁决
每个sentinel会向其它sentinal、master、slave定时发送消息,以确认对方是否“活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的“主观认为宕机” Subjective Down,简称SDOWN)。
若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称ODOWN),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。
View Code
4-6行是关键,这里指定了sentinel节点信息。但这段代码在运行时发现一个问题:对于1主1从的最小化配置,如果连续发生两次写操作,第1次set成功后,如果断点停在这里,down掉master,这时剩下的slave会提升为master,但是第2次set时,会抛异常,类似:连接已断开。(注:通过Spring-Data-Redis整合Jedis与redis时,利用RedisTemplate调用不会有这个问题,看来Spring-Data-Redis针对这个问题做过优化,所以建议正式项目中,通过Spring-Data-Redis整合Redis来调用相关功能,而不是自己直接引用Jedis的jar包来使用)
二、Redisson
View Code
同样做类似的测试,二次写,二次读,如果第1次写后,人工down掉master,剩下的slave会提升成master,第二次写ok,但此时redis节点中,只剩master,没有slave了,从测试结果上看,第二次get还是尝试去找slave节点,但是此时已经不存在了,所以一直在等候,导致后面的的处理被阻塞。
这不是redis的问题,而是Redisson客户端设计不够智能。
鉴于这种现状,如果要使用Redisson,最好做成1主2从的部署结构:(sentinel.conf中的“法定人数”,建议调整成2)
这样的好处是,1个master挂掉后,剩下的2台slave中,会有1台提升为master,整体仍然保证有1个master和1个slave,读写均不受影响。
关于Sentinel的更多细节,可参考官网文档:http://www.redis.io/topics/sentinel
每个sentinel会向其它sentinal、master、slave定时发送消息,以确认对方是否“活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的“主观认为宕机” Subjective Down,简称SDOWN)。
若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称ODOWN),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。
View Code
4-6行是关键,这里指定了sentinel节点信息。但这段代码在运行时发现一个问题:对于1主1从的最小化配置,如果连续发生两次写操作,第1次set成功后,如果断点停在这里,down掉master,这时剩下的slave会提升为master,但是第2次set时,会抛异常,类似:连接已断开。(注:通过Spring-Data-Redis整合Jedis与redis时,利用RedisTemplate调用不会有这个问题,看来Spring-Data-Redis针对这个问题做过优化,所以建议正式项目中,通过Spring-Data-Redis整合Redis来调用相关功能,而不是自己直接引用Jedis的jar包来使用)
二、Redisson
View Code
同样做类似的测试,二次写,二次读,如果第1次写后,人工down掉master,剩下的slave会提升成master,第二次写ok,但此时redis节点中,只剩master,没有slave了,从测试结果上看,第二次get还是尝试去找slave节点,但是此时已经不存在了,所以一直在等候,导致后面的的处理被阻塞。
这不是redis的问题,而是Redisson客户端设计不够智能。
鉴于这种现状,如果要使用Redisson,最好做成1主2从的部署结构:(sentinel.conf中的“法定人数”,建议调整成2)
这样的好处是,1个master挂掉后,剩下的2台slave中,会有1台提升为master,整体仍然保证有1个master和1个slave,读写均不受影响。
关于Sentinel的更多细节,可参考官网文档:http://www.redis.io/topics/sentinel
相关文章推荐
- 基于redis的分布式ID生成器
- 基于Redis实现分布式锁,Redisson使用及源码分析
- 10 个 Redis 建议/技巧
- 基于Redis实现分布式锁
- Redis client的jar包和源码
- redis自动安装脚本(只安装redis)
- Redis-x64-2.8.2400存档
- 跟我学REDIS-REDIS(三)----常用数据类型之Hash
- 跟我学REDIS-REDIS(二)----常用数据类型之Lists
- redis crackit 漏洞 过程还原
- Redis测试分析(pipeline模式)
- Redis-3.0.7主从简单复制的配置
- java 对redis 的基本操作
- redis获取的集合转换成普通list/map集合
- centos安装redis3.0
- MySQL数据导入Redis
- Linux安装redis
- Java测试Redis
- Redis
- windows下安装使用redis实用教程