redis之（十五）redis的集群中的哨兵角色

一：redis集群的哨兵的目的是什么？。

（1）监控主redis和从redis数据库是否正常运行

（2）主redis出现故障，自动将其中一台从redis升级为主redis。将原先的主redis转变成从redis

 

 

二：redis集群＋哨兵的的结构图

三单机模拟实现redis集群＋哨兵的分布式部署

(1)启动redis集群

(2)查看集群角色

(3)启动哨兵（在配置文件中写入:sentinel monitor mymaster 127.0.0.1 6379 1）

==>配置文件格式：sentinel momitor 数据库名字 主redis的ip地址  主redis端口号  执行故障恢复前

==>启动哨兵后，并杀死6379端口实例.会从6380.6381里选举一个实例，称为新的主redis

==>图片中＋try-failover表示哨兵开始进行故障恢复。-failover-end表示哨兵完成故障恢复，期间涉及的内容很复杂，包括领头哨兵的选举，备选从数据库的选择。

==>图片中＋switch-master表示主redis从6379端口迁移到6381.6379实例的信息并没有被哨兵清除

==>图片中-sdown表示6379重新启动，加入到集群中。

 

四：哨兵的原理

（1）哨兵的配置文件，要找出需要监控的主数据库。

  --->sentinel monitor master-name  ip  redis-port quorum

  --->master-name 主数据库的名字

  --->ip表示当前系统中主数据库的地址

  --->redis-port 表示当前系统中主数据库的端口号

  --->quorum表示故障恢复操作前至少需要几个哨兵节点同意。

 

（2）一个哨兵节点可以监控多个redis主从系统，只需要提供多个sentinel monitor配置即可。同时多个哨兵节点也可以同时监控一个redis主从系统。

 

（3）哨兵启动后，会与要监控的主数据库建立两条链接。这两个链接的建立方法与普通的redis客户端一样。其中一条链接用来订阅主数据库_sentinel_:hello频道以获取其他同样监控该数据库的哨兵节点信息。另外一条链接，需要定期向主数据库发送info等命令来获取主数据库的本身的信息。

  --->每10秒哨兵会向主数据库和从数据库发送info命令。

  --->每2秒哨兵会向主数据库和从数据库的_sentinel_:hello频道发送自己的信息。

  --->每1秒哨兵会向主数据库和从数据库和其他哨兵节点发送ping命令

 

（4）哨兵活动过程

  --->哨兵发送info命令，可以获得当前数据库的相关信息（包括运行id,复制信息，该数据库的从节点列表）。得到这些信息后，哨兵会和从redis节点建立同样两条链接。从反馈的信息中，更新，新加入的节点，以及获得数据库的角色变化信息。

  --->哨兵向主从数据库的_sentinel_:hello频道发送自己的信息来与同样监控该数据库的哨兵分享自己的信息。发送内容<哨兵地址><哨兵端口><哨兵运行id><哨兵配置版本><主数据库名字><主数据库的地址><主数据库的端口><主数据库的配置版本>。哨兵订阅到该信息，判断是否是新加入的哨兵，如果是，加入哨兵列表。并与其建立一条链接用来发送ping命令。同时判断信息中主数据库的配置版本，如果该版本比当前记录的主数据库的版本高，则会更新主数据库的数据。

  --->实现了自动发现从数据库和其他哨兵节点后，哨兵要做的就是定时监控这些数据库和节点有没有停止服务。这是通过每隔一定时间向这些节点发送ping命令实现的。

   配置参数：sentinel down-after-milliseconds 主数据库名  毫秒数。 

   毫秒数>1秒，则每隔1秒发送一次ping命令，小于1秒，则按配置的毫秒数的间隔发送ping命令。

 

（5）哨兵实现发现主redis宕机，在从redis集群中选举新redis主节点。

  ---> 当哨兵a发现主redis节点m由于ping不通，先认为其［主观下线］

  --->哨兵a会发送SENTINEL is-master-down-by-addr命令来询问其他哨兵节点（b,c,d...）了解他们是否也认为m下线。并将得到同样认为下线的结果进行累加，达到指定数量（quorum），则认为m为［客观下线］

  --->哨兵a就会向其他哨兵列表（b,c,d...）发送命令，要求选举自己为领头哨兵，如果其他哨兵没有同意过其他哨兵节点为领头哨兵，则同意a为领头哨兵，如果a发现有超过半数且超过quorum参数值的哨兵节点同意自己是领头哨兵，则a成功称为领头哨兵。

  --->当有多个哨兵节点同时参选领头哨兵，则会出现没有任何节点当选的可能，此时每个参选节点将等待一个随机时间重新发起参选请求，进行下一轮选举，知道选举成功。

  --->选出领头哨兵，则领头哨兵a将从停止服务的主redis数据库的从redis列表中挑选一个来充当新的主redis节点。

    1，所有在线的从数据库中，选择优先级最高的从数据库，优先级可以通过slave-priority选项配置。

    2，如果有多个最高优先级的从数据库，则复制的命令便宜量越大，即复制越完整，越优先。

    3，如果以上条件都一样，则选择运行id教小的从数据库。

  --->选举除从redis，则向其发送SLAVEOF NO ONE命令将其升格为主数据库，而后领头哨兵会向其他从数据库发送SLAVEOF命令，使其称为新主redis数据库的从数据库

  --->最后一步，更新内部记录，将已经停止服务的旧的数据库更新为新的主数据库的从数据库，使得当其恢复服务时候自动以从数据的身份继续服务。

 

 

五：哨兵的部署

(1)如果一个主从系统中配置的哨兵教少，则哨兵对整个系统的判断的可靠行就会越低。反之，越高。极端（一个哨兵，就是单点问题）

(2)相对稳妥的部署方案是是的哨兵的视角尽可能地与每个节点的视角一致。

  --->为每个节点（无论是主数据库还是从数据库）都部署一个哨兵。

  --->使每个哨兵与其对应的节点的网络环境相同或相近。