redis主从,哨兵回忆手册

内容预览:
  • 缺点主节点挂了,那么就只能提供读操作了~
  • # redis-cli -p 6380 #查看Slave中的Keys是否和Master中一致,从结果看...~
  •   或者使用两个哨兵集群进行解决,每个集群一个主,几个从~

 redis主从

  持久化的开启与主从集群是否生效无关系

  Slave Server同样是以非阻塞的方式完成数据同步。在同步期间,如果有客户端提交查询请求,Redis则返回同步之前的数据(注意初次同步则会阻塞)

Replication的工作原理:

 

如果Master和Slave之间的链接出现断连现象,Slave可以自动重连Master,但是在连接成功之后,一次完全同步将被自动执行。

缺点主节点挂了,那么就只能提供读操作了。

应用示例:

这里我们假设Master-Slave已经建立。

    #启动master服务器。

[[email protected] redis]# redis-cli -p 6379
redis 127.0.0.1:6379>
#清空Master当前数据库中的所有Keys。
redis 127.0.0.1:6379> flushdb
OK
#在Master中创建新的Keys作为测试数据。
redis 127.0.0.1:6379> set mykey hello
OK
redis 127.0.0.1:6379> set mykey2 world
OK
#查看Master中存在哪些Keys。
redis 127.0.0.1:6379> keys *
1) "mykey"
2) "mykey2"

#启动slave服务器。
[[email protected] redis]# redis-cli -p 6380
#查看Slave中的Keys是否和Master中一致,从结果看,他们是相等的。
redis 127.0.0.1:6380> keys *
1) "mykey"
2) "mykey2"

#在Master中删除其中一个测试Key,并查看删除后的结果。
redis 127.0.0.1:6379> del mykey2
(integer) 1
redis 127.0.0.1:6379> keys *
1) "mykey"

#在Slave中查看是否mykey2也已经在Slave中被删除。
redis 127.0.0.1:6380> keys *
1) "mykey"

 

哨兵模式

哨兵模式就是监控redis系统的运行情况,主要功能有两点:

1,监控主数据库和从数据库是否正常运行。

2,主数据库出现故障时,可以自动将从数据库转换为主数据库,实现自动切换。

实现步骤

  在其中一台从服务器(比如192.168.19.131)中配置sentinel.conf

vi sentinel.conf

sentinel monitor name(监控的主从集群的名称) 192.168.19.131 8089 1 #名称,ip,端口(主从集群中master的地址),投票选举次数

sentinel down-after-milliseconds name 5000 #默认1s检测一次,这里配置超时5000毫秒为宕机
sentinel failover-timeout name 900000
sentinel parallel
-syncs name 2
sentinel can
-fallover name yes
port
26379 #哨兵默认的端口

启动哨兵

/user/intsmaze/redis/bin/redis-server /user/intsmaze/redis/etc/sentinel.conf --sentinel &
查看哨兵相关信息
/user/intsmaze/redis/bin/redis-cli -h 192.168.19.131 -p 26379 Info sentinell
关闭主服务器查看集群信息
/user/intsmaze/redis/bin/redis-cli -h 192.168.19.131 -p 8089 shutdonwn

  缺点:主节点宕机了,再切换节点时,中间有几秒无法提供服务,这几秒是用来切换的,且是无法解决的。这个时候只能在java代码中对redis的操作进行异常捕获,如果发现是宕机异常,则在catch中睡眠一秒,在重试几次即可。

  或者使用两个哨兵集群进行解决,每个集群一个主,几个从。使用keepalive进行漂移,如果某个主宕机了,则keepalive则将ip飘到另一个主节点上。不需要等待从节点变为主节点。

  Redis Sentinel是一个分布式系统,可以部署多个Sentinel实例来监控同一组Redis实例,它们通过Gossip协议来确定一个主实例宕机,通过Agreement协议来执行故障恢复和配置变更,一般在生产环境中部署多个实例来提高系统可用性,只要有一个Sentinel实例运行正常,就能保证被监控的Redis实例运行正常(类似Zookeeper,通过多个Zookeeper来提高系统可用性);

redis的主从读写

  redis的主从读写,redis自己是无法做到的,即我们要在java客户端通过代码指定写操作请求master,读操作请求slave。

  jedis提供的连接池不支持主从读写的,只支持哨兵模式。就是连接池地址是哨兵,然后所有的读写请求都是走向master,只是做到了当主节点宕机,从升级为主后,jedis的连接池会自动更改当前master的地址。

HA的关键在于避免单点故障及故障恢复

  在Redis Cluster未发布之前,Redis一般以主/从方式部署(这里讨论的应用从实例主要用于备份,主实例提供读写,有不少应用是读写分离的,读写操作需要取不同的Redis实例,该方案也可用于此种应用,原理都是相通的,区别在于数据操作层如何封装),该方式要实现HA主要有如下几种方案: 

  1,keepalived:通过keepalived的虚拟IP,提供主从的统一访问,在主出现问题时,通过keepalived运行脚本将从提升为主,待主恢复后先同步后自动变为主,该方案的好处是主从切换后,应用程序不需要知道(因为访问的虚拟IP不变),坏处是引入keepalived增加部署复杂性; 

  2,zookeeper:通过zookeeper来监控主从实例,维护最新有效的IP,应用通过zookeeper取得IP,对Redis进行访问; 

  3,sentinel:通过Sentinel监控主从实例,自动进行故障恢复,该方案有个缺陷:因为主从实例地址(IP&PORT)是不同的,当故障发生进行主从切换后,应用程序无法知道新地址,故在Jedis2.2.2中新增了对Sentinel的支持,应用通过redis.clients.jedis.JedisSentinelPool.getResource()取得的Jedis实例会及时更新到新的主实例地址。 

  笔者所在的公司先使用了方案1一段时间后,发现keepalived在有些情况下会导致数据丢失,keepalived通过shell脚本进行主从切换,配置复杂,而且keepalived成为新的单点,后来选用了方案3,使用Redis官方解决方案;(方案2需要编写大量的监控代码,没有方案3简便,网上有人使用方案2读者可自行查看)

原文和作者一起讨论: http://www.cnblogs.com/intsmaze/p/6819091.html

 

以上就是:redis主从,哨兵回忆手册 的全部内容。

本站部分内容来源于互联网和用户投稿,如有侵权请联系我们删除,谢谢。
Email:[email protected]


0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论