redis-哨兵

版权声明：转载请声明转自http://blog.csdn.net/thewindkee https://blog.csdn.net/thewindkee/article/details/83507696

哨兵

Redis Sentinel是Redis的高可用实现方案，可以解决主从复制模式下可能出现的问题。

主从复制问题

1. 主节点出现故障，需要手动将从节点晋升为主节点，修改应用方主节点地址，命令其他从节点去复制新的主节点。
2. 主节点的写、储存能力受到单机的限制。
   1主2从的Redis主从复制模式下,如master 有两个从节点，分别为slave-1,slave-2。如何手动进行故障转移:
3. 当master故障后，需要选中一个从节点slave-1作为新的master。
4. 使用slaveof no one 使其成为新的主节点new master。
5. 客户端重启连接new master。
6. 使用命令让slave-2复制新的主节点 slaveof new master --例如SLAVEOF 127.0.0.1 6379 6379为新master的端口
7. 待原来的主节点回复后，让它复制新的主节点， slaveof new master 。
   ####Redis Sentinel的高可用性
   Redis Sentinel 可以将上述步骤及时，准确的完成。
   首先，Redis Sentinel 并没有针对Redis节点做特殊处理，只是在主从节点外加了若干个Sentinel节点对定期对所有节点（主从节点和除自己外的其余Sentinel节点）进行监控，并对主节点的故障实现自动转移。
   假如，现在是1主2从，3个Sentinel节点。
   Sentinel自动处理故障转移逻辑步骤：
8. 主节点出现故障，两个从节点市区连接，主从复制失败。
9. 每个Sentinel节点通过定期监控发现了主节点出现了故障。
10. 多个Sentinel节点对主节点故障达成一致，选举出Sentinel-3作为领导者负责故障转移。
11. Sentinel领导者节点执行了故障转移，并将结果通知应用客户端。这一操作与之前手动操作一样，不过是自动完成的。
    Redis Sentinel的功能有 监控、通知（应用方)、主节点故障转移、配置提供者。
    此外多个Sentinel节点去判断节点是否故障，有效防止误判，Sentinel集合保持本身的健壮。

哨兵的配置

1.配置1主2从节点，配置信息一样，只不过从节点多了slaveof 配置。2.启动三个哨兵。
Sentinel 本身就是单独的Redis节点，不过有些特殊：不存储数据，只支持部分命令。
哨兵配置文件redis-sentinel1-26379.conf

port 26379
daemonize yes #windows下不支持
logfile "26379.log"
dir "./data"  #需要创建对应目录
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 3000  #Sentinel节点定期发送ping命令，超过该时间认为节点不可达
sentinel parallel-syncs mymaster 1  #故障转移后，1时从节点轮询发起复制。3时，同时发起复制。
sentinel failover-timeout mymaster 18000  #故障转移超时时间

sentinel monitor mymaster 127.0.0.1 6379 2 表示监控127.0.0.1:6379这个主节点
，判断主节点失败至少需要2个节点同意，mymaster是主节点的别名。
26379是哨兵默认端口。

sentinel down-after-milliseconds 虽然以master-name作为参数，但实际上对Sentinel、主、从节点的失败判定同时有效。
接下来会配置三个哨兵，但配置信息除了端口和日志位置，其他都一样。
这是因为哨兵不只是对 sentinel monitor mymaster 127.0.0.1 6379 2指定的节点监控，而是从主节点中获得其他节点（包括sentinel节点）的配置信息，因此会对所有节点进行监控。 —可以通过在其他节点上，开启monitor查看哨兵发来的ping信息。
两种方式启动哨兵

1. 使用redis-sentinel命令:
   redis-sentinel redis-sentinel1-26379.conf
2. redis-server redis-sentinel1-26379.conf --sentinel
   我在windows上启动如下
   D:\Program Files\redis\Redis-x64-3.2.100 - 2>redis-server.exe redis-sentinel1-26379.conf --sentinel
   如果在主节点上有monitor ，会发现 一直在输出

1494402722.938312 [0 127.0.0.1:13740] "PING"
1494402723.976372 [0 127.0.0.1:13740] "INFO"
1494402724.065377 [0 127.0.0.1:13740] "PING"
1494402724.166383 [0 127.0.0.1:13740] "PUBLISH" "__sentinel__:hello" "127.0.0.1,26379,d00a619bc84286
658541b3e50a2ba2095dc601f2,0,mymaster,127.0.0.1,6379,0"

使用Info sentinel查看信息

# Sentinel
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=1

再添加了两个哨兵。
查看哨兵配置文件，发现信息已经改变。
程序已经自动追加了从节点和哨兵的配置了。

port 26379
daemonize yes
logfile "26379.log"
dir "D:\\Program Files\\redis\\Redis-x64-3.2.100 - 2\\data"
sentinel myid d00a619bc84286658541b3e50a2ba2095dc601f2
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 18000
# Generated by CONFIG REWRITE
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
sentinel known-slave mymaster 127.0.0.1 6382 #添加slave后自动出现
sentinel known-slave mymaster 127.0.0.1 6380
sentinel known-sentinel mymaster 127.0.0.1 26382 e48f0f48332024cdaa3f7d844c53f312af721834 #添加sentinel后自动出现
sentinel known-sentinel mymaster 127.0.0.1 0 f9ded3b16fbaaa46a31db6c6e4aa7f33ff2c05c2
sentinel known-sentinel mymaster 127.0.0.1 26380 077913ed510e0d38c6530b6bd1534b6c6f115899
sentinel current-epoch 0

D:\Program Files\redis\Redis-x64-3.2.100 - 12>redis-cli.exe -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3 #可看出1主2从3哨兵的配置

Sentinel 命令

以下列出的是 Sentinel 的部分命令：

PING ：返回 PONG 。
sentinel masters ：展示所有被监控的主节点状态以及相关的统计信息。
sentinel sentinels <master name> ：展示指定<master name>的Sentinel节点集合，不包括当前Sentinel节点。
sentinel remove <master name> ：取消当前Sentinel节点对指定<master name>主节点的监控。
sentinel masters ：列出所有被监视的主服务器，以及这些主服务器的当前状态。
sentinel slaves <master name> ：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态。
sentinel get-master-addr-by-name <master name> ： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的故障转移操作已经完成， 那么这个命令返回新的主服务器的 IP 地址和端口号。
sentinel reset <pattern> ： 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel 。
sentinel failover <master name> ： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移 （不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。
SENTINEL ckquorum<master name>：检测当前可达的Sentinel节点总数是否达到<quorum>的个数。例如
quorum=3，而当前可达的Sentinel节点个数为2个，那么将无法进行故障转
移，Redis Sentinel的高可用特性也将失去。
sentinel flushconfig：将Sentinel节点的配置强制刷到磁盘上，这个命令Sentinel节点自身用得
比较多，对于开发和运维人员只有当外部原因（例如磁盘损坏）造成配置文
件损坏或者丢失时，这个命令是很有用的。
sentinel monitor<master name><ip><port><quorum>：这个命令和配置文件中的含义是完全一样的，只不过是通过命令的形式
来完成Sentinel节点对主节点的监控。
例如命令sentinel-1节点重新监控mymaster-1节点：
127.0.0.1:26379> sentinel monitor mymaster-1 127.0.0.1 6379 2
sentinel is-master-down-by-addr：Sentinel节点之间用来交换对主节点是否下线的判断，根据参数的不
同，还可以作为Sentinel领导者选举的通信方式。

通过 sentinel get-master-addr-by-name <master name> 获得主节点的信息。通过主节点获得slave的信息(role或者info replication)

为了让应用端能得到故障转移后的结果信息，应该让应用端连接Sentinel而不是直接连接master/slave。

####Java操作Redis Sentinel

 Jedis jedis =new Jedis("127.0.0.1",26379);//其中一个哨兵
List<String> master=jedis.sentinelGetMasterAddrByName("mymaster");
if(master==null || master.size()<2){
return null;
}
for(String s:master){
System.out.println(s);
}
//输出:
//127.0.0.1
//6379

各哨兵每2秒向”sentinel:hello频道“发布消息,主节点订阅该消息得知哨兵情况。

可以通过订阅__sentinel__:hello来发现新节点。
对主节点执行monitor

上图是6379这个master的动作,下图是26379这个哨兵的所有端口。
master 每1秒向各节点发送ping 确定彼此存活。 向”sentinel:hello频道“发布消息， 让订阅该频道的哨兵、从节点得到彼此状态。