首先我们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不好在线扩容
-
实现哨兵集群模式比较复杂
哨兵模式就到这里了,如有错误内容,请各位大佬斧正!!!!!