2.3 新建redis-sentinel1容器(第一个哨兵节点)

docker run -itd --privileged=true --name redis-sentinel1 -v /root/redisconf/:/usr/local/etc/redis -p 16379:16379 redis:latest redis-sentinel /usr/local/etc/redis/sentinel1.conf

  这里通过-v挂在了/root/redisconfig/目录，同时使用-p指定了Docker容器16379端口映射宿主机16369端口。这里用redis-sentinel命令启动了哨兵节点，启动时加载了sentinel1.conf文件。

2.4 查看哨兵节点信息

  通过dodkcer exec -it redis-sentinel1 /bin/bash命令进入Docker容器里的命令行，然后用redis-cli -h 127.0.0.1 -p 16379命令进入Redis客户端，在Redis客户端里，用info sentinel命令查看哨兵节点的信息，具体如下：

  从最后一行可以看到，该哨兵节点监控的主服务器状态(status)是ok,slaves数量为2，即该主服务器有两个从服务器，这和之前的配置情况是一致的。

2.5 新建redis-sentinel2容器(第二个哨兵节点)

在/root/redisconf/目录下创建sentinel2.conf文件，代码如下：

port 16380
sentinel monitor master 172.17.0.5 6382 2
dir “/”
logfile "sentinel2.log"

随后开启命令窗口，新建哨兵节点：

 docker run -itd --privileged=true --name redis-sentinel2 -v /root/redisconf/:/usr/local/etc/redis -p 16380:16380 redis:latest redis-sentinel /usr/local/etc/redis/sentinel2.conf

此时的所有容器

继续进入客户端查看哨兵节点信息

  可以看到，该哨兵正在监控172.17.0.5:6382指向的主服务器，sentinels=2表示172.17.0.5:6382指向的主服务器正在被两台哨兵节点监控。
  至此，哨兵集群搭建完成。

3、哨兵节点的常用配置

3.1 指定判断下线时间的阈值

sentinel down-after-millseconds master 60000

  其中，master表示该哨兵节点监控的服务器名，需要和sentinel monitor配置项里指定的服务器名保持一致，而60000表示时间，单位是毫秒。也就是说，如果在69秒里该哨兵节点没有收到master服务器的正确响应，就会认为该服务器已经下线失效。

3.2 设置故障恢复的时效

sentinel failover-timeout master 180000

  该时效参数的单位是毫秒，这里的含义是，在进行故障恢复时，如果在180秒里还没有完成主从服务器的切换动作，就会认为本次恢复动作失败。

4、哨兵模式下的故障自动恢复效果

  通过上文的配置，能实现哨兵节点监控主从复制模式里主服务器的效果。这里将演示主服务器失效后故障子u东恢复效果。

4.1 停止主服务器(redis-master1)所在的容器

  到redis-master1这个Docker容器下，执行docker stop redis-master1命令来停止主服务器所在的容器，以此来模拟主服务器失效的效果。

4.2 观察哨兵节点所监控的主从集群状态

  到redis-sentinel1这个哨兵节点所在的命令行窗口，通过info sentinel命令观察该哨兵节点所监控的主从集群状态。

  从输出结果可以看到，在该哨兵节点所在的集群里，主服务器已从172.17.0.5：6382换成172.17.0.7:6384。也就是说，真个主从复制集群并没有因为主服务器的失效而终止工作，这里哨兵节点把从服务器“提升”为主服务器，从而让该主从复制集群恢复了工作。
  到redis-sentinel2这个哨兵节点所在的命令行窗口，通过info sentinel命令观察该哨兵节点所监控的主从集群状态，也能看到类似的结果。

4.3 观察redis-slave2所在的命令行窗口，运行info replication命令

  从输出看出role的值已经变为了master,也就是从“从服务器”升级成“主服务器”。
  再去redis-slave1所在的命令窗口运行info replication命令，就能看到如下的部分结果，从箭头所指可看出该Redis服务器在redis-master1失效后确实已经从属于172.17.0.7:6384所指向的服务器。

通过本步骤的输出结果，能进一步确认“故障自动恢复”动作已经成功完成。

5、通过日志观察故障恢复流程

  由于在启动redis-sentinel1和redis-sentinel2节点时制定了日志的路径和位置，这里可以在对应的Docker容器里通过日志观察具体的故障恢复流程。
  先到redis-sentinel1所在的容器里用cat /sentinel1.log命令观察该哨兵节点在故障恢复时的动作，就能看到如下内容

  日志中的sdown的含义是“主管下线”，与之对应的是表示客观下线的odown。当本哨兵节点发现所监控的master服务器下线后，会先将它标记为“主管下线”，当多个哨兵节点(根据设置，这里需要2个)都判断服务器下线后，如日志中第1处圈起来那块，随后把该服务器标记为客观下线。
  当检测到客观下线后，会启动故障恢复(failover)流程,通过后面的日志，能看出故障恢复的各个步骤，这些细节可以不用关心。完成故障恢复后，会切换主服务器，切换完成后，会加载从服务器。至此，完成了故障自动恢复的流程。当前主从模式集群效果如下图。

  然后到redis-salve2所在的容器，执行cat /sentinel2.log命令查看该哨兵节点的日志，其中和故障恢复相关的内容如下所示。

  由于只能由一个哨兵节点完成故障自动恢复的动作，因此如果有多个哨兵节点同时监控到主服务器失效，那么最终只能有一个哨兵节点通过竞争得到故障恢复的权力。
  从上文的日志中可以看到，由于故障恢复的权利已经被redis-sentinel1节点竞争得到，所以当redis-sentinel2节点发现主服务器失效后，只能停留在主管下线(sdown)阶段，而无法进行故障恢复动作。只有当redis-sentinel1节点完成故障恢复动作后，redis-sentienl2节点才能输出后续的日志，感知到重构后的主从复制模式集群，并继续监控该集群里的节点。

6、故障节点恢复后的表现

  从上文日志可以看到，此时虽然redis-master1服务器依然处于失效状态，但是在新的主从复制集群里依然会把该服务器当成“从服务器”。再到redis-master1所在的命令行窗口用docker start redis-master1命令启动容器，以此来模拟该服务器排除故障后的效果。
运行完命令后，再到redis-salve22所在的命令行窗口里运行info replication命令，就能看到如下的输出，可以看到故障恢复后的redis-master1服务器会自动以“从服务器”的身份接入

  总结，哨兵节点不仅能自动恢复故障，而且当故障节点恢复后会自动把它重新加入到集群中，而无需人工干预。也就是说，与简单的“主从复制模式集群”相比，基于哨兵模式的集群能很好地提升系统地可靠性。