redis-sentinel哨兵 完整攻略

1.简介

凌晨2点，你睡得正香，老板就突然打电话过来说，redis服务器炸了，网站瘫痪了！你不得不起床打开电脑开始苦逼的解决问题：重新配置redis，把项目的redis的地址切换到从节点的redis，然后重新打包项目，部署等一系列困扰你睡美梦的操作。然而，如果你配置redis哨兵，这一切将不会发生，你还可以继续睡你的美梦。

1.1sentinel 架构

三个哨兵充当对redis实例的实时监控，如果主节点挂掉，哨兵察觉到后立即在两个从节点中选举新的master，当挂掉的主节点恢复正常后，充当新master的从节点。

2.主从配置

你需要有三个redis实例，一个主节点和两个从节点
关于主从同步的配置可以看我的这篇博客
注意：我的redis是5版本的
redis主从复制

3.sentinel配置

在每一份redis实例上创建一份配置文件，在单机环境中，确保端口唯一即可（其他的配置不需要动）

#启动端口
port 26379
#监控主节点redis 服务名 ip和端口 当两个哨兵觉得主节点不可用时主节点下线
sentinel monitor mymaster 主节点redis的ip 端口 2
#5秒内主节点没有响应认定为挂掉了
sentinel down-after-milliseconds mymaster 5000
#选举另一个master超时时间
sentinel failover-timeout mymaster 60000
#选举中 最多有一个从节点同步主节点
sentinel parallel-syncs mymaster 1

ok，现在我们的整个环境搭建，三个redis实例和三个sentinel实例，我是在单机的centos环境下测试，在这里请各位读者十分的注意自己的ip和端口避免弄错！ 我这里使用的外网的ip，你可以用内网本地ip即可。

实例	ip:port
redis1	192.168.72.134:6379
redis2	192.168.72.134:6380
redis3	192.168.72.134:6381
sentinel1	192.168.72.134:26379
sentinel2	192.168.72.134:26380
sentinel3	192.168.72.134:26381

我们打开主节点redis实例客户端 查看具体信息

[root@localhost redis-5.0.3]# redis
127.0.0.1:6379> info replication
# Replication
#角色是master 其他从节点为salve
role:master
connected_slaves:2
#可以看到下面两个从节点实例 如果你的没有 请务必检查自己的操作步骤
slave0:ip=192.168.72.134,port=6381,state=online,offset=28,lag=1
slave1:ip=192.168.72.134,port=6380,state=online,offset=28,lag=1
master_replid:7387ff36c2ebcf7d1440e07c5cc006c96ae414c3
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:42

我们启动三个哨兵实例，如下图

启动任一sentinel客户端，查看其信息

[root@localhost redis-5.0.3]# redis-cli -p 26379
127.0.0.1:26379> sentinel master mymaster
 1) "name"
 2) "mymaster"
 3) "ip"
 4) "192.168.72.134"
 5) "port"
 6) "6379"
 7) "runid"
 8) "f51aee2ec220f0f662c248542bf9d03c86cc3834"
 9) "flags"
10) "master"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "514"
19) "last-ping-reply"
20) "514"
21) "down-after-milliseconds"
22) "5000"
23) "info-refresh"
24) "1239"
25) "role-reported"
26) "master"
27) "role-reported-time"
28) "121624"
29) "config-epoch"
30) "4"
31) "num-slaves"
32) "2"
33) "num-other-sentinels"
34) "2"
35) "quorum"
36) "2"
37) "failover-timeout"
38) "180000"
39) "parallel-syncs"
40) "1"

可以看到num-slaves和num-other-sentinels都是2，前者是从节点数量，后者是关联的哨兵数量，如果你的参数异常，请检查你的操作步骤。

3.测试

查看当前的master
显然是我们前面哨兵配置中监听的主节点

127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster
1) "192.168.72.134"
2) "6379"

宕机测试：
现在我们关闭redis 6379实例30秒

redis-cli -p 6379 DEBUG sleep 30

再查看主节点时发现已经切换6380端口的redis实例

127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster
1) "192.168.72.134"
2) "6380"

6379实例恢复时，我们可以看到它变成了从节点

127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.72.134
master_port:6380
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:415421
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:c6eba63129405a3f0fe2786b974fa2048179bafd
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:415421
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:393523
repl_backlog_histlen:21899

4.总结

本次教程就到此结束，请读者严格按照每一步操作来，避免踩坑。
当你再打开redis的配置文件查看最底部时，你会发现其中的主从配置ip和端口已经被sentinel动态的修改，每一次的宕机，sentinel都会对配置文件进行动态的修改。
如果此篇文章对你有用，不妨点个赞吧！一起加油