Docker搭建Redis哨兵模式集群
- 1、哨兵模式概述
- 2、Docker搭建哨兵模式集群
- 2.1 先按照如下链接中方法搭建一个一主二从的Redis集群，其中redis-master1是主服务器，redis-salve11和redis-salve22是从服务器。
- 2.2 在/root/redisconf/文件夹下新建sentinel1.conf配置文件
- 2.3 新建redis-sentinel1容器(第一个哨兵节点)
- 2.4 查看哨兵节点信息
- 2.5 新建redis-sentinel2容器(第二个哨兵节点)
- 3、哨兵节点的常用配置
- 3.1 指定判断下线时间的阈值
- 3.2 设置故障恢复的时效
- 4、哨兵模式下的故障自动恢复效果
- 4.1 停止主服务器(redis-master1)所在的容器
- 4.2 观察哨兵节点所监控的主从集群状态
- 4.3 观察redis-slave2所在的命令行窗口，运行`info replication`命令
- 5、通过日志观察故障恢复流程
- 6、故障节点恢复后的表现
1、哨兵模式概述
基于主从复制模式的集群在发生故障时可能会出现数据丢失等情况，因为当主服务器发生故障后，需要手动进行数据恢复动作，并要重新设置主从关系，比较麻烦。
可以在主从复制的基础上引入“哨兵(sentinel)”机制，一方面用哨兵远程监控主从服务器是否可用，另一方面当主服务器发生故障时通过哨兵机制可以实现“故障自动恢复”效果。
一般来说，哨兵机制会和主从复制模式整合使用，在基于哨兵的模式里会在一台或多台服务器上引入哨兵进程，这些节点也叫哨兵节点。
哨兵节点一般不存储数据，它的作用是监控主从模式里的主服务器节点。当哨兵节点监控的主服务器发生故障时，哨兵节点会主导“故障自动恢复”流程，具体来讲就是会在该主服务器下属的从服务器里选出一个新的主服务器，并完成响应的数据和配置更改等动作。
也就是说，如果采用这种模式，可以让故障自动修复，从而提升系统的可用性。在项目里，一般会配置多个主从模式集群，所以会引入多个哨兵节点。基于哨兵模式的集群效果如下图所示。
2、Docker搭建哨兵模式集群
2.1 先按照如下链接中方法搭建一个一主二从的Redis集群，其中redis-master1是主服务器，redis-salve11和redis-salve22是从服务器。
Docker搭建Redis主从复制集群javascript:void(0)
2.2 在/root/redisconf/文件夹下新建sentinel1.conf配置文件
文件内容如下：
port 16379 哨兵节点的工作端口为16379 sentinel monitor master 172.17.0.5 6382 2
指定监控对象，其中master是哨兵节点为监控服务器指定的名字，172.17.0.5和6382分别是redis-master1这台主服务器的IP地址和端口号，最后的2表示至少需要2台哨兵节点认可才能认定该主服务器失效。
2.3 新建redis-sentinel1容器(第一个哨兵节点)
这里通过-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文件，代码如下：
随后开启命令窗口，新建哨兵节点：
此时的所有容器
继续进入客户端查看哨兵节点信息
可以看到，该哨兵正在监控172.17.0.5:6382指向的主服务器，sentinels=2表示172.17.0.5:6382指向的主服务器正在被两台哨兵节点监控。
至此，哨兵集群搭建完成。
3、哨兵节点的常用配置
3.1 指定判断下线时间的阈值
其中，master表示该哨兵节点监控的服务器名，需要和sentinel monitor配置项里指定的服务器名保持一致，而60000表示时间，单位是毫秒。也就是说，如果在69秒里该哨兵节点没有收到master服务器的正确响应，就会认为该服务器已经下线失效。
3.2 设置故障恢复的时效
该时效参数的单位是毫秒，这里的含义是，在进行故障恢复时，如果在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服务器会自动以“从服务器”的身份接入
总结，哨兵节点不仅能自动恢复故障，而且当故障节点恢复后会自动把它重新加入到集群中，而无需人工干预。也就是说，与简单的“主从复制模式集群”相比，基于哨兵模式的集群能很好地提升系统地可靠性。
