redis主从，哨兵回忆手册

2022-03-09 12:03:22

redis主从

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

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

Replication的工作原理：

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

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

应用示例：

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

    #启动master服务器。
    [root@Stephen-PC 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服务器。
    [root@Stephen-PC 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