首先我们Redis哨兵模式需要搭建Redis集群，集群搭建Blog请看：Redis的集群搭建&主从复制_Xxxyfeng的博客-CSDN博客
当我们在没有配置Replication的时候，主机突然断电或者宕机了，那么就会出现另外几台从机会没有主机，那么此时客户
端就只能读取数据，不能写数据，为了解决这个问题，那么就出现了哨兵模式
以前我们在主机宕机的时候，都是需要程序员人为的更换主机
例如，我这里直接shutdown掉主机
# 6379端口号的服务端被关闭
127.0.0.1:6379> SHUTDOWN
not connected> exit再来观看从机的info信息
此时我们从机只能读不能写的，那么如何手动处理这种情况呢？
那么我们只需要把其中一台从机改变为主机即可！
127.0.0.1:6380> SLAVEOF no one
OK
127.0.0.1:6380> info replication
# Replication
role:master # 角色已经变成主机
connected_slaves:0 # 连接的从机为0，此时我们需要把其它的从机改变为此端口号的从机即可！
master_failover_state:no-failover
master_replid:de8443bb2cc7008aae2e53cee60226d235b3ec95
master_replid2:68f6f02a7ea151e5b1be7f9da046ab708b4eeb7b
master_repl_offset:98
second_repl_offset:99
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:98# 重新认主人
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380
OK
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380 # 主机端口号成功改为6380端口号的主机
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_repl_offset:98
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:de8443bb2cc7008aae2e53cee60226d235b3ec95
master_replid2:68f6f02a7ea151e5b1be7f9da046ab708b4eeb7b
master_repl_offset:98
second_repl_offset:99
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:15
repl_backlog_histlen:84这就是以前主机宕机的时候，手动修改主机的方法，这只是在两台机子的情况下，当我们开的从机很多，那么可想而知这
个工作量将会非常的大。
那么哨兵模式就是自动选取主机的工作，哨兵就是起到的一个监视的作用，当我们的主机断开连接的时候，哨兵模式首先
推断断该端口下的服务端是否已经断开连接了，它会发送一系列的连接命令来询问该服务端，当到达一定的时间后，哨兵
就会内部推选一个从机来当主机！
配置哨兵模式
我们需要一个配置文件来监控我们的主机端口号，在myconfig（自己创建的）目录下创建一个sentinel.conf
注意：文件名必须为sentinel.conf，不能出错，不然这配置文件不起作用
sentinel.conf就一行代码
# 代表监控127.0.0.1 下的6379端口号的服务端 后面的这个数字1，代表当主机挂了，salve投票让哪个从机成为主机，票数最多的从机就会成为主机！
sentinel monitor myredis 127.0.0.1 6379 1 ok，写完这个配置文件后，我们就可以启动哨兵模式去测试了
redis-sentinel mconfig/sentinel.conf # 启动命令启动后的界面
现在我们尝试让主机宕机，既使用shutdown命令
127.0.0.1:6379> SHUTDOWN
not connected> exit?关闭后，哨兵并不会立马投票选出主机，而是会持续给断开连接的主机发送消息，当到达一定时间后主机没有回应，那么才会进行投票选举！
?此时重新查看6380端口号的replication信息
127.0.0.1:6380> info replication
# Replication
role:master # 已经变成了主机
connected_slaves:1 # 连接的从机有一个
slave0:ip=127.0.0.1,port=6381,state=online,offset=22890,lag=1 # 连接的从机的具体信息
master_failover_state:no-failover
master_replid:2a76c850cd2f46e07a7d383afabed5a031404e86
master_replid2:3bee3e118c9b332e3a49958596cc03a1214c5106
master_repl_offset:22904
second_repl_offset:15190
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:22904从这里也可以看出，6380已经成为了新的主机，那么6381的从机其主机也改变为了6380端口号的服务端！说明哨兵模式
起作用了！那么当我们6379端重新连接，它会重新变为它们两个的主机吗？
?
可以从图中看到，重新连接不会成为主机，而是成为当前主机的从机！这就是哨兵模式的规则
哨兵模式的优缺点
优点：
-
哨兵集群，基于主从复制模式，那么主从赋值的优点都有
-
主从可以切换，故障可以转移，系统的可用性就越好
-
哨兵模式就是主从复制的升级，手动到自动，更加健壮！
缺点：
-
Redis不好在线扩容
-
实现哨兵集群模式比较复杂
哨兵模式就到这里了，如有错误内容，请各位大佬斧正！！！！！