Sentinel（哨岗、哨兵）是Redis的高可用性（high availability）解决方案：由一个或多个Sentinel实例（instance）组成的Sentinel系统（system）可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

Redis Sentinel 是官方推荐的高可用性解决方案。它不会因为节点宕机而导致服务不可用，同时，它可以作为监控管理工具，可以提供节点监控、通知、自动故障恢复和客户端配置发现服务等，即使出现了故障，也能很快知道，并进行修复。

开始搭建：

本次部署是单机伪集群，想要部署真正的集群，需要将秒个主件拆分到各个机器上去部署，只修改ip地址.

docker-compose的安装:

下载：

curl -L https://github.com/docker/compose/releases/download/1.24.1/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose 

添加权限：

chmod +x /usr/local/bin/docker-compose

查看版本：

docker-compose --version

一：创建一个文件夹，用于适用docker-compose.yml文件

cd  /home/Software/Docker      #进入目录

mkdir redis , mkdir sentinel #创建docker文件夹并在其下创建redis和sentinel文件夹

二：进入redis文件夹，并创建如下docker-compose.yml文件

cd redis
touch docker-compose.yml
docker-compose.yml

三：编辑docker-compose.yml文件，并将如下内容复制进去，保存并退出

version: '3.4'
services:
  master:
    image: redis
    container_name: redis-master
    restart: always
    ports:
      - 6379:6379
    command: redis-server --port 6379
    #network_mode: "host"

  slave1:
    image: redis
    container_name: redis-slave-1
    restart: always
    ports:
      - 6380:6380
    command: redis-server --slaveof 192.168.8.150 6379 --port 6380
    #network_mode: "host"

  slave2:
    image: redis
    container_name: redis-slave-2
    restart: always
    ports:
      - 6381:6381
    command: redis-server --slaveof 192.168.8.150 6379 --port 6381
    #network_mode: "host"

四：进入刚刚创建的sentinel目录

cd ../sentinel

五：创建docker-compose.yml文件，并将如下内容复制进去，保存并退出

version: '3.4'
services:
  sentinel1:
    image: redis
    container_name: redis-sentinel-1
    ports:
      - 26379:26379
    command: redis-sentinel /home/Software/Docker/sentinel/sentinel.conf
    restart: always
    #network_mode: "host"
    volumes:
      - ./sentinel1.conf:/home/Software/Docker/sentinel/sentinel.conf

  sentinel2:
    image: redis
    container_name: redis-sentinel-2
    ports:
      - 26380:26379
    command: redis-sentinel /home/Software/Docker/sentinel/sentinel.conf
    restart: always
    #network_mode: "host"
    volumes:
      - ./sentinel2.conf:/home/Software/Docker/sentinel/sentinel.conf

  sentinel3:
    image: redis
    container_name: redis-sentinel-3
    ports:
      - 26381:26379
    command: redis-sentinel /home/Software/Docker/sentinel/sentinel.conf
    restart: always
    #network_mode: "host"
    volumes:
      - ./sentinel3.conf:/home/Software/Docker/sentinel/sentinel.conf

六：创建哨兵文件，并将如下内容复制进去，保存并退出

touch  sentinel.conf 

vi sentinel.conf

Redis哨兵配置主要关注三个地方：

port 26379
dir /tmp
# 自定义集群名，其中 127.0.0.1 为 redis-master 的 ip，6379 为 redis-master 的端口，2 为最小投票数（因为有 3 台 Sentinel 所以可以设置成 2）
sentinel monitor mymaster 192.168.8.150 6379 2
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
sentinel down-after-milliseconds mymaster 30000
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面： 
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。  
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes

注意：

     ① 第三行中 mymaster 是可以自定义集群的名字，如果使用其他语言连接集群，需要写上该名字。

     ② 192.168.8.150是我虚拟机的ip，请换成自己的ip，不要127.0.0.1 否则会链接到你的应用程序去，写IP就可以。

     ③  那个2呢，是因为我有3台哨兵，2个投票超过50%了，所以设置2即可，如果是更多，设置超过50%概率就好，自己喜欢。

七：将刚刚创建的sentinel.conf在创建3份，一模一样就可以了

cp sentinel.conf sentinel1.conf
cp sentinel.conf sentinel2.conf
cp sentinel.conf sentinel3.conf

八：启动集群，先启动master-slave redis服务，再启动sentinel哨兵。

cd  /home/Software/Docker/redis

docker-compose up -d     # 启动容器， -d 表示后台启动

cd  /home/Software/Docker/sentinel
docker-compose up -d                 #-d表示后台运行，就是守护态运行

STATUS状态是Up表示成功启动哨兵容器

使用客户端连接一下：

观察sentinel的日志

执行docker logs redis-sentinel-1 查看启动情况:



可以看到三个sentinel节点都监视了master (6379)节点，这个时候我们可以把maste(6379)节点停下来试一下:

docker stop redis-master

再次查询docker logs redis-sentinel-1 ，docker logs redis-sentinel-2，docker logs redis-sentinel-3：

可以看到日志输出，有两个sentinel节点认为master节点主观下线之后，有一个节点认为master节点客观下线:

sdown和odown两种失败状态:
sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机
odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机
sdown达成的条件很简单，如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机
sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机

主观下线：所谓主观下线，就是单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。

 

sentinel会以每秒一次的频率向所有与其建立了命令连接的实例（master，从服务，其他sentinel）发ping命令，通过判断ping回复是有效回复，还是无效回复来判断实例时候在线（对该sentinel来说是“主观在线”）。

 

sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，如果实例在down-after-milliseconds毫秒内，返回的都是无效回复，那么sentinel回认为该实例已（主观）下线，修改其flags状态为SRI_S_DOWN。如果多个sentinel监视一个服务，有可能存在多个sentinel的down-after-milliseconds配置不同，这个在实际生产中要注意。

客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，如果其他的哨兵也认为主节点主观线下了，则当认为主观下线的票数超过了quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线

然后开始开始投票选举领头sentinel:

如果一个master被认为odown了，而且majority哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave来

configuration epoch:

哨兵会对一套redis master+slave进行监控，有相应的监控的配置
执行切换的那个哨兵，会从要切换到的新master（salve->master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的
如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号

configuraiton传播:


　　哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，就是通过之前说的pub/sub消息机制

故障转移步骤：

1.多个sentinel发现并确认master有问题。
2.选举出一个sentinel作为领导。
3.选出一个slave作为master
4.通知其余slave成为新的master的slave
5.通知客户端主从变化
6.等待老的master复活成为新master的slave

4.Sentinel的工作原理总结
1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令。

2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。

3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。

5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 。

6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 。

7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。

若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。