Redis哨兵模式(Sentinel)以及场景实践

Redis哨兵模式(Sentinel)以及场景实践

根据我们上篇中所用到的模型是一个Master两个Salve节点，那么当Master宕机时，两个从节点是无法进行写操作的，那势必会影响我们程序的正常使用，有没有什么办法可以在Master宕机时能有一个Salve节点变成Master继续提供写操作呢？答案是肯定的，我们的哨兵就是为解决这个问题而生的！

什么是哨兵模式？

在Redis2.8版本以前，当Master节点出现宕机情况时，我们是手动配置从Salve节点变为Master节点（或者恢复Master节点的服务）来继续工作的，但是这种操作不仅仅费时费力，还有可能在恢复期间影响写的操作，造成数据的丢失。所以Redis在2.8版本推出了哨兵模式来进行自动的分配Master节点。

见上图，哨兵以独立的进程实时监督Master节点和Salve节点，当Master节点出现意外情况不能正常运行时，哨兵就会选举一个Salve节点来当Master节点，以保证程序的正常的读写操作。
其实啊哨兵只负责干两件事：

• 监控所有Redis节点，看其是否正常运行（向所有节点发送命令，根据redis的返回状态判断其是否正常运行）
• 当检测到Master节点宕机时，会推举一个Salve节点当Master节点，然后通过发布订阅的模式来通知其他节点修改他们的配置文件，告诉他们我现在是皇帝，你们都是我的子民都得听我的。

我们虽然使用了哨兵模式，但是当这个哨兵也突然死掉了怎么办？那我们就多派几个哨兵进行监督嘛。这些哨兵不仅可以监控各个节点还可以互相监督。这就是多哨兵模式。

场景：比如Master节点突然崩溃了，我们的哨兵1检测到了，但是它并不会立即开始推举其他Salve节点，而是等待其他哨兵也检测到了Master节点确实崩溃了之后，哨兵们才会进行投票，票数多的那个salve节点将接替Master。切换成功之后，通过发布订阅模式，让各个哨兵把自己监控的Master切换成当前Master。

Redis怎么实现主从复制为这里就不再赘述，不了解的请移驾 Redis主从复制的配置并进行场景测试。

单哨兵配置：

1、在redis目录中新建一个文件sentinel.conf，里面内容如下

#sentinel monitor 随便起名 Master主机IP Master端口  1代表Master宕机时哨兵进行投票选举
sentinel monitor redis6379 127.0.0.1 6379 1 

2、启动刚刚配置的哨兵

redis-sentinel sentinel.conf   #启动哨兵

哨兵启动成功后我们可以在控制台看到Master节点和Salve节点的一些信息。

场景测试：

当Master突然宕机，是否会有Salve节点被推举为Master
在Master宕机之前我们先写一条数据

#6379为Master节点
127.0.0.1:6379> set name Silence-wen
OK
127.0.0.1:6379> get name
"Silence-wen"
127.0.0.1:6379> 

#6380Salve节点
127.0.0.1:6380> get name
"Silence-wen"
127.0.0.1:6380> 

#6381Salve节点
127.0.0.1:6381> get name
"Silence-wen"
127.0.0.1:6381> 

shutdown掉Master进程之前Master节点的从属信息：

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=16717,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=16717,lag=0
master_replid:600a20a2c7420d206c084442548b39ebed39f4de
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:16717
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:16717
127.0.0.1:6379> 

shutdown掉Master进程之前6380Salve节点的从属信息：

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:16773
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:600a20a2c7420d206c084442548b39ebed39f4de
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:16773
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:16773
127.0.0.1:6380> 

shutdown掉Master进程之前6381Salve节点的从属信息：

127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:16815
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:600a20a2c7420d206c084442548b39ebed39f4de
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:16815
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:16815
127.0.0.1:6381> 

shutdown掉Master进程：

[root@Silence bin]# ps -ef|grep redis
root      6280  6261  0 16:33 pts/0    00:00:00 redis-cli
root      6343     1  0 16:41 ?        00:00:19 redis-server 127.0.0.1:6381
root      6351  6323  0 16:41 pts/3    00:00:00 redis-cli -p 6381
root      6422     1  0 17:05 ?        00:00:17 redis-server 127.0.0.1:6380
root      6427  6283  0 17:06 pts/1    00:00:00 redis-cli -p 6380
root      6469  6208  0 17:53 pts/2    00:00:14 redis-server 127.0.0.1:6379
root      6649  6382  0 20:22 pts/4    00:00:00 grep --color=auto redis
[root@Silence bin]# kill 6469
[root@Silence bin]# ps -ef|grep redis
root      6280  6261  0 16:33 pts/0    00:00:00 redis-cli
root      6343     1  0 16:41 ?        00:00:19 redis-server 127.0.0.1:6381
root      6351  6323  0 16:41 pts/3    00:00:00 redis-cli -p 6381
root      6422     1  0 17:05 ?        00:00:17 redis-server 127.0.0.1:6380
root      6427  6283  0 17:06 pts/1    00:00:00 redis-cli -p 6380
root      6651  6382  0 20:23 pts/4    00:00:00 grep --color=auto redis
[root@Silence bin]# 

Master节点进程已shutdown，下面我们看看是否跟我们之前所说的那样，哨兵会选举一个Salve作为新Master节点。

等待几秒钟我们shutdown掉Master节点之后看下哨兵进程打印出来的信息：

6698:X 13 Aug 2020 20:33:13.148 # +sdown master redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:13.148 # +odown master redis6379 127.0.0.1 6379 #quorum 1/1
6698:X 13 Aug 2020 20:33:13.148 # +new-epoch 1
6698:X 13 Aug 2020 20:33:13.148 # +try-failover master redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:13.151 # +vote-for-leader 50b2a5b7aa9a471788c1df7a09775533f5392f14 1
6698:X 13 Aug 2020 20:33:13.151 # +elected-leader master redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:13.151 # +failover-state-select-slave master redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:13.218 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:13.218 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:13.295 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:14.257 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:14.257 # +failover-state-reconf-slaves master redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:14.338 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:15.330 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:15.330 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:15.381 # +failover-end master redis6379 127.0.0.1 6379
6698:X 13 Aug 2020 20:33:15.381 # +switch-master redis6379 127.0.0.1 6379 127.0.0.1 6381
6698:X 13 Aug 2020 20:33:15.381 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ redis6379 127.0.0.1 6381
6698:X 13 Aug 2020 20:33:15.381 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ redis6379 127.0.0.1 6381
6698:X 13 Aug 2020 20:33:45.425 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ redis6379 127.0.0.1 6381

从输出信息中我们可以看到，Master节点shutdown之后，哨兵会：

1、try-failover master redis6379（进行故障转移）
2、vote-for-leader （选举领袖）
3、elected-leader master redis6379 （选举一个领袖）
4、failover-state-select-slave master （故障转移状态从从节点中选举）
5、selected-slave slave （选择从节点）
6、failover-state-send-slaveof-noone（故障转移发送指令slaveof no one）
7、failover-state-wait-promotion （故障转移状态等待晋升）
8、promoted-slave （提拔从节点）
9、failover-state-reconf-slaves （故障转移状态重新配置从节点）
10、slave-reconf-sent （从节点重新配置发送）
11、slave-reconf-done（从节点重新配置完成）
12、failover-end（故障转移完成）
13、switch-master redis6379 127.0.0.1 6379 127.0.0.1 6381 （选举6381代替6379作为Master）
14、slave slave 127.0.0.1:6380 127.0.0.1 6380 @ redis6379 127.0.0.1 6381 （6380为6381的Salve）
15、slave slave 127.0.0.1:6379 127.0.0.1 6379 @ redis6379 127.0.0.1 6381（6379降为6381的Salve）

从哨兵打印出来的信息我们可以看出6379Master节点shutdown之后，哨兵进行了一系列操作后，将6381选举为了Master，同时又将6379和6380发配给了6381，成为了6381的奴隶。

是否真的像哨兵打印出的日志一样6381变成了Master呢？我们不妨来看一下。

查看两个Salve节点的从属信息：

127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=83338,lag=1
master_replid:d20833d54acc941615c6c0b4a989e6f8f4d1de42
master_replid2:47c74f39e93685c12f13ddc96bca80b76f1ecce1
master_repl_offset:83338
second_repl_offset:18322
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:83338
127.0.0.1:6381> 

6380的从属信息：

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:90594
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:d20833d54acc941615c6c0b4a989e6f8f4d1de42
master_replid2:47c74f39e93685c12f13ddc96bca80b76f1ecce1
master_repl_offset:90594
second_repl_offset:18322
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:90594
127.0.0.1:6380> 

果然6381变成了Master节点，但是它好像只有一个6380的从节点，6379怎么没显示呢？
我们这时候启动6379，看看6379的从属关系是什么样的？

127.0.0.1:6379> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:97041
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:d20833d54acc941615c6c0b4a989e6f8f4d1de42
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:97041
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:95665
repl_backlog_histlen:1377
127.0.0.1:6379> 

果然，6379变成6381的从节点了，7379启动之后在6381的从属关系中将会显示出来。

127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=101561,lag=0
slave1:ip=127.0.0.1,port=6379,state=online,offset=101561,lag=0
master_replid:d20833d54acc941615c6c0b4a989e6f8f4d1de42
master_replid2:47c74f39e93685c12f13ddc96bca80b76f1ecce1
master_repl_offset:101561
second_repl_offset:18322
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:101561
127.0.0.1:6381> 

由以上操作可以看出，哨兵帮我们实现了在Master宕机时自动实现故障转移的操作，从而减少了系统故障的时间。

但是当我们在实际项目当中可不仅仅这样配置就行的。在实际工作当中需要配置多个哨兵，而且还要配置发现故障时发送邮件给相关人员等等一些配置。