redis 主挂掉了，怎么将请求转移到从上去，如果从是多个，从是怎么进行选举的呢？

那么就要看我们今天的主角了，redis哨兵，redis哨兵能够帮助我们自动的完成选主和故障转移操作，这次还是会多画图，来加深大家都这个过程的记忆和理解。

redis哨兵是一个运行的特殊的redis进程，他主要有三个使命：

哨兵主要是监听主库和从库是否存活，怎么进行监控？ 哨兵会定期的给从库发送PING命令，如果从库没有在设定的时间内回复哨兵，那么就会认为从库下线了。哨兵也会定期的给主库发送PING命令进行通信，如果主库也没有在设定的时间内回复哨兵，那么就会认为主库也“下线了”。【注意我这里只是为了说明下监控的方式，真正判断的主库下线不是这样的】。

看图说话：

可以看到图中redis-2 slave 是灰色，表示已经down掉了，此时并没有正常返回给哨兵响应，所以被标记为下线状态了。

这里为什么要单独来说下主库的监控呢？因为主库监控，不能说哨兵没有收到PING的响应，那么就认为主库就下线了，因为主库的选举是一个很复杂的过程，会有耗时和通信的开销，所以我们不能简单认为哨兵没有收到PING的响应，那么就直接判断主库下线了，然后就进行选举，如果是从库可以的，因为从库下线了，对于主从集群来说，影响不会很大。

在主库压力比较大，或者网络阻塞了，出现抖动了，这个是并没有在设定的时间内回复给哨兵响应，那么此时武断的认为主库"下线了"，此时就出现了误判，明明不需要进行选主，不需要进行通知，此时白白浪费的资源、同时带来了开销。

看图说话：

在网络畅通的情况下，哨兵发了一个PING给主库

此时网络阻塞，变成了红色，PONG，没有在设定的时间内返回

网络恢复顺畅，哨兵重试，在设定的时间内返回响应

通过上面三幅图，其实就可以看出，网络阻塞的情况下，会出现误判的情况。

那么reids是怎么判断主库下线的呢？其实redis采用哨兵集群的方式，让哨兵集群中的每个哨兵都和主库进行通信，如果多数都没有在设定的时间内响应给哨兵，因为多个哨兵都出现网络不稳定的情况概率就大大降低了，那么此时这个主库就认为是下线了。下面我们来细细的说下这个过程，同时引入哨兵集群也解决了哨兵单点的问题。

这个过程分为主观下线和客观下线。

主观下线：指的是一个哨兵在设定的时间内，没有收到