redis的分布式集群（哨兵模式）

哨兵模式

什么是哨兵

顾名思义，哨兵的作用就是监控Redis系统的运行状况，它的功能包括两个

\1. 监控master和slave是否正常运行
\2. master出现故障时自动将slave数据库升级为master
哨兵是一个独立的进程，使用哨兵后的架构图

 为了解决master选举的问题，又引出了一个单点问题，也就是哨兵的可用性如何解决，在一个主从的redis系统中

可以使用多个哨兵进行监控任务，以保证系统的足够稳定，此时哨兵不仅会监控master和slave，同时还会互相监控，这种方式称为哨兵集群；

解决的问题

1.哨兵集群需要解决故障发现

2.master决策的协商机制问题

sentinel之间的相互感知
sentinel节点之间会因为共同监视同一个master从而产生了关联，一个新加入的sentinel节点需要和其他监视相同
master节点的sentinel相互感知，首先

1.需要相互感知的sentinel节点，都向他们共同监控的master节点订阅channel:sentinel:hello

2.新加入的sentinel节点向这个channel发布一条消息，包含自己本身的信息，这样订阅了这个channel的sentinel
就可以发现这个新的sentinel

3.新加入得sentinel和其他sentinel节点建立长连接

 master的故障发现

sentinel节点会定期向master节点发送心跳包来判断存活状态，一旦master节点没有正确响应，sentinel会把master设置为“主观不可用状态”，然后它会把“主观不可用”发送给其他所有的sentinel节点去确认，当确认的sentinel节点数大于>quorum时，则会认为master是“客观不可用”，接着就开始进入选举新的master流程；但是这里又会遇到一个问题，就是sentinel中，本身是一个集群，如果多个节点同时发现master节点达到客观不可用状态，那谁来决策选择哪个节点作为maste呢？这个时候就需要从sentinel集群中选择一个leader来做决策。而这里用到了一致性算法Raft算法、它和Paxos算法类似，都是分布式一致性算法。但是它比Paxos算法要更容易理解；Raft和Paxos算法一样，也是基于投票算法，只要保证过半数节点通过提议即可;

配置实现

通过在这个配置的基础上增加哨兵机制。在其中任意一台服务器上创建一个sentinel.conf文件，文件内容
sentinel monitor name ip port quorum
其中name表示要监控的master的名字，这个名字是自己定义。 ip和port表示master的ip和端口号。 最后一个1表示最低
通过票数，也就是说至少需要几个哨兵节点统一才可以。

port 6040
sentinel monitor my1master 192.168.11.131 6379 1
sentinel down-after-milliseconds my1master 5000 --表示如果5s内my1master没响应，就认为SDOWN
sentinel failover-timeout my1master 15000 --表示如果15秒后,my1sater仍没活过来，则启动failover，从剩下的
slave中选一个升级为master

 

两种方式启动哨兵
redis-sentinel sentinel.conf
redis-server /path/to/sentinel.conf --sentinel

哨兵监控一个系统时，只需要配置监控master即可，哨兵会自动发现所有slave；
这时候，我们把master关闭，等待指定时间后（默认是30秒），会自动进行切换，会输出如下消息
img
+sdown表示哨兵leader认为master已经停止服务了，+odown表示哨兵客观认为master停止服务了。接着哨兵开始进行故障恢复，挑选一个slave升级为master
+try-failover表示哨兵开始进行故障恢复
+failover-end 表示哨兵完成故障恢复
+slave表示列出新的master和slave服务器，我们仍然可以看到已经停掉的master，哨兵并没有清楚已停止的服务
的实例，这是因为已经停止的服务器有可能会在某个时间进行恢复，恢复以后会以slave角色加入到整个集群中