docker部署redis集群_Docker部署Redis集群----第八节（docker-redis哨兵集群原理篇）-CSDN博客

上个篇章，我们搭建了docker的哨兵集群的代码实现和部分功能节点的创建以及五条必须掌握的配置命令，本节篇章主要来讲哨兵集群Sentinel的原理。

1、哨兵Sentinel的原理：

通过上个篇章的梳理讲解哨兵Sentinel的处理机制，我们不难发现主要是分为三个步骤：

检测问题：主要是三个定时任务，这三个内部的执行任务可以保证Master主节点出现问题后马上让Sentinel节点知道。

首先了解下内部Sentinel节点会执行以下三个定时任务：

1、每10秒每个哨兵Sentinel对Master和Slave执行一次Info Replication：

Redis Sentinel 可以对Redis节点做失败判断和故障转移，在Redis内部有三个定时任务作为基础，来Info
Replication 发现从节点Slave来确认主从关系

2、每2秒每个哨兵Sentinel通过Master节点的channel交换信息（pub/sub）

这个定时任务如同发布订阅，哨兵Sentinel节点会对主从关系进行判断，通过_sentinel_:hello频道进行交互
。了解主从关系可以帮助更好地实现自动化操作Redis.然后Sentinel会告知系统信息给其他哨兵Sentinel节点
，就像握手，协议达成一致，并且哨兵Sentinel之间能相互感应。

3、每1秒每个哨兵Sentinel对其他Sentinel和Redis执行ping

失败判定的依据，对每个节点和其他Sentinel进行心跳检测。

发现问题：主要是了解主管上线和客观下线，当有一台哨兵节点Sentinel发现问题时，它就会主观上对它进行下线，当有多个哨兵Sentinel都发现有问题出现时就会让它客观下线。

这里我们先回顾下上节课所见的必须掌握的五个配置的其中两个：
sentinel monitor redis-master IP POST NUM 
sentinel down-after-millseconds redis-master ms
哨兵Sentinel会ping每个节点，如果超过 ms 毫秒，依然没有应答回复的话，做下线的判定
主观下线：
每个哨兵Sentinel节点对Redis节点失败的主观记录，这其中只是因为，该节点在 ms 毫秒内没有接收到Redis
的回复就会发起主观下线【主观下线的依据是苛刻的，也就说证据不足不能单纯的认为某一台哨兵Sentinel没有
收到回复就判断Redis故障】
客观下线：
当有 NUM 个哨兵Sentinel节点都在 ms 毫秒内没有收到Redis的回复就会判定Redis已故障，并开始执行后面
的步骤发起故障转移。

解决问题：主要是领导者选举，如何在哨兵Sentinel内部多台节点做领导者选举，选出一个领导者，并实现故障转移。

1、每个主观下线的哨兵Sentinel节点，会向其他的Sentinel节点发起命令，要求将自己设置为领导者。
2、收到命令的Sentinel节点，如果“没有同意通过”其他节点发送命令，那么就会同意请求，反之拒绝
3、如果主观下线的哨兵Sentinel节点发现了自己的投票数超过半数同时也超过了sentinel monitor 
redis-master IP POST NUM 中的 NUM 数就会成为领导者
4、开始进行故障转移

讲到这里我们应该都已明白Sentinel的领导者的选举过程，那如何从从节点Slave选举为主节点的呢？

Redis的内部其实就是就有一个优先级的配置的，在配置文件中 slave-priority，这个参数是 Salve 节点的优先级配置。如果存在则返回，如果不存在则继续。当上面这个优先级不满足的时候，Redis 还会选择复制偏移量最大的 Slave节点，如果存在则返回，如果不存在则继续。之所以选择偏移量最大，这是因为偏移量越小，和 Master 的数据越不接近，现在 Master挂掉了，说明这个偏移量小的机器数据也可能存在问题，这就是为什么要选偏移量最大的 Slave 的原因。如果发现偏移量都一样，这个时候 Redis 会默认选择 runid 最小的节点。

2、生成环境中的部署技巧：

Sentinel 节点不应该部署在一台物理“机器”上。

这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流行的容器，它们虽然有不同的 IP 地址，但实际上它们都是同一台物理机，同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现 Sentinel 节点集合真正的高可用，请勿将 Sentinel 节点部署在同一台物理机器上。

部署至少三个且奇数个的 Sentinel 节点。

3个以上是通过增加 Sentinel 节点的个数提高对于故障判定的准确性，因为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基础上节省一个节点。

3、哨兵节点详解：

进入哨兵节点客户端后执行SENTINEL masters命令“显示被监控的所有master以及它们的状态.”
127.0.0.1:26379> SENTINEL masters
1)  1) "name"        
    2) "mymaster"       //被监控主节点的名称
    3) "ip"
    4) "172.60.0.4"     //被监控主节点的ip
    5) "port"
    6) "6379"           //被监控主节点的端口号
    7) "runid"
    8) "8aaecf3f6a197932b28ed89d2d3936636814c5fe"  //被监控主节点的runid[运行]
    9) "flags"
   10) "master"
   11) "link-pending-commands"
   12) "0"
   13) "link-refcount"
   14) "1"
   15) "last-ping-sent"
   16) "0"
   17) "last-ok-ping-reply"
   18) "1017"
   19) "last-ping-reply"
   20) "1017"
   21) "down-after-milliseconds"
   22) "30000"              //监控主节点不可达超时时间
   23) "info-refresh"
   24) "2704"
   25) "role-reported"
   26) "master"
   27) "role-reported-time"
   28) "386306494"
   29) "config-epoch"    //epochs的配置
   30) "1"
   31) "num-slaves"
   32) "2"                //发现从节点个数
   33) "num-other-sentinels"        //发现其他哨兵节点个数
   34) "2"
   35) "quorum"  
   36) "2"       //需要同意主节点不可用的Sentinels的数量
   37) "failover-timeout"         
   38) "180000"    //延迟时间
   39) "parallel-syncs"  //复制转移数量
   40) "1"
执行SENTINEL slaves mymaster查看从节点的信息：【你会看到有两个从节点的信息】
127.0.0.1:26379> SENTINEL slaves mymaster
1)  1) "name"
    2) "172.60.0.3:6379"
    3) "ip"
    4) "172.60.0.3"
    5) "port"
    6) "6379"
    7) "runid"
    8) "e8510d9e9811dec10af1d88153db129284d2e264"
    9) "flags"
   10) "slave"
   11) "link-pending-commands"
   12) "0"
   13) "link-refcount"
   14) "1"
   15) "last-ping-sent"
   16) "0"
   17) "last-ok-ping-reply"
   18) "981"
   19) "last-ping-reply"
   20) "981"
   21) "down-after-milliseconds"
   22) "30000"
   23) "info-refresh"
   24) "8170"
   25) "role-reported"
   26) "slave"
   27) "role-reported-time"
   28) "388149449"
   29) "master-link-down-time"
   30) "0"
   31) "master-link-status"
   32) "ok"
   33) "master-host"
   34) "172.60.0.4"
   35) "master-port"
   36) "6379"
   37) "slave-priority"
   38) "100"
   39) "slave-repl-offset"
   40) "76787185"
2)  1) "name"
    2) "172.60.0.2:6379"
    3) "ip"
    4) "172.60.0.2"
    5) "port"
    6) "6379"
    7) "runid"
    8) "948b5d23e83648c586a5d3056c0b850a9c517887"
    9) "flags"
   10) "slave"
   11) "link-pending-commands"
   12) "0"
   13) "link-refcount"
   14) "1"
   15) "last-ping-sent"
   16) "0"
   17) "last-ok-ping-reply"
   18) "981"
   19) "last-ping-reply"
   20) "981"
   21) "down-after-milliseconds"
   22) "30000"
   23) "info-refresh"
   24) "8170"
   25) "role-reported"
   26) "slave"
   27) "role-reported-time"
   28) "387258992"
   29) "master-link-down-time"
   30) "0"
   31) "master-link-status"
   32) "ok"
   33) "master-host"
   34) "172.60.0.4"
   35) "master-port"
   36) "6379"
   37) "slave-priority"
   38) "100"
   39) "slave-repl-offset"
   40) "76787185"
执行SENTINEL get-master-addr-by-name mymaster 查看主节点的信息和端口号
127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster
1) "172.60.0.4"
2) "6379"
执行SENTINEL failover mymaster 强制切换主节点不需要得到其他Sentinel
127.0.0.1:26379> SENTINEL failover mymaster
OK
当我们再次执行查询主节点信息时就会发现主节点已经切换了如下图：

后面还有几个命令这里就不在一一实现了，有兴趣的话自己修改配置文件执行命令运行看看结果。到这里我们的哨兵集群的搭建和原理也就都讲完了。普通的主从复制和哨兵集群我们讲到这，下一篇章我们开始讲项目实践案例一共是两个案例1：用php实现轮询分流 2：高并发抢单。

今天的篇章就到这里，觉得还不错的话，请关注我的专栏和我的主页，谢谢。