【Redis 系列】redis 学习十一，redis 的哨兵模式详解和实战

上一次我们说到的主从复制是这样搭建的

主机可以读，可以写

从机只能读，不能写

想一想，那么我们是不是也可以这样呢？

多个 redis-server 首尾相连

那么咱们部署的时候就是 6379 – 6380 – 6381

此时，若主机 6379 宕机掉，6380 会不会变成主机呢？

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=0,lag=1
master_failover_state:no-failover
master_replid:f1e3db9e5e438f5d98e4cad23f684b12d790ae56
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0

我们可以看到 6379 有一个从机，6380 自身也是作为从机（虽然 6380 是 6381 的主机）

此时将 6379 宕机掉，发现 6380 仍然是 slave

127.0.0.1:6379> shudown
not connected>

我们人为的将 reids 6380 的服务器修改为主机，看看 6379 redis-server 起来之后，是否可以把 master 抢回去

使用 slaveof no one 可以将自己设置成 master

启动 6379 redis-server

redis-server /usr/local/redis/redis-6.2.5/6379.conf

发现 6380 仍然是主机，6379 成为了光杆司令

实际项目中，我们肯定不会采取上面和上一次文章说到的部署方式，他们抵御风险的能力太低了

因为实际生产环境中，主机宕机了，若从机没有办法成为主机的话，岂不是在主机回复之前再也不能做写入操作了吗？这是很严重的问题

下面我们来详细看看 哨兵模式是如何解决上述问题的

哨兵模式

自动选举 master 的模式

介绍

主动切换 master 的方法是：

当主机服务器宕机后，以往的情况咱们需要手动把某一个从机服务器修改为主机服务器，需要人为处理，耗时耗力，且会造成一段时间内服务不可用的情况，这种做法是不可取的

所以有了哨兵模式，哨兵模式是 redis 2.8 版本开始真是提供的 sentinel 架构来解决上述的问题

哨兵模式，能够监控后台的主机服务器是否故障，若出现了故障，则会投票选举出一个从机服务器来做主机

哨兵模式是一种特殊的模式，Redis 提供了哨兵的命令

哨兵其实是一个独立的进程，作为进程，它会独立运行

其原理就是哨兵通过发送命令，等到 Redis 服务器响应，从而监控运行的多个 Redis 实例

实际演练