查看之前的博客可以点击顶部的【分类专栏】
本篇博客基于第1篇博客的环境基础上继续实验的：
/BiandanLoveyou/article/details/117793509
1、什么是哨兵机制？
Redis的哨兵 (sentinel) 系统用于管理多个 Redis 服务器，该系统执行以下三个任务：
1、监控(Monitoring)：哨兵(sentinel) 会不断地检查你的 Master 和 Slave 是否运作正常。
2、提醒(Notification)：当被监控的某个 Redis 出现问题时，哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
3、自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作，它会将失效 Master 的其中一个Slave升级为新的Master，并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的 Master时，集群也会向客户端返回新Master的地址，使得集群可以使用新的 Master 代替已失效 Master。
哨兵(sentinel) 是一个分布式系统，你可以在一个架构中运行一个或者多个哨兵(sentinel) 进程，这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息，并使用投票协议(agreement protocols)来决定是否执行自动故障迁移，以及选择哪个Slave作为新的Master。
每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave 定时发送消息，以确认对方是否【活】着，如果发现对方在指定时间(可配置)内未回应，则暂时认为对方已挂(所谓的【主观认为宕机】Subjective Down，简称sdown)。
若哨兵群【集群】中的多数sentinel，都报告某一 master 没响应，系统才认为该master【彻底死亡】(即：客观上的真正down机，Objective Down，简称odown)，通过一定的选举算法 vote，从剩下的 slave 节点中，选一台提升为 master，然后自动修改相关配置。
个人理解的哨兵模式
哨兵模式，相当于一个公园里的几个门卫（哨兵，sentinel）和公园里执勤的保安们（Redis 机器）。门卫负责在门口放哨的，他们本身并不参与到保安的工作（业务Redis），但是他们都属于公园里的成员（都是 Redis 实例）。门卫们通过无线对讲机与每个保安（业务Redis）保持联络，同时也与其他门卫之间保持联络，每隔一段时间互相发送当前的状况。如果某个门卫（哨兵）发现保安队长（master）在某一段时间内一直没回应，就主观的认为这个保安队长（master）宕机了 sdown。如果几个门卫都报告这个保安队长（master）宕机了，那就是客观上的宕机 odown，这时候门卫他们就会在剩余的保安（Slave Redis）里挑选一个来做新队长（switch master）。如果之前宕机的那个队长重新联络上了，那也只能做普通保安（Slave Redis），因为保安队长只有一个。
2、配置哨兵模式（单哨兵，自动切换主从）
注意，这里的配置基于第一篇博客的环境内容：/BiandanLoveyou/article/details/117793509
首先我们下载标准的哨兵模式配置文件。在目录下面下载【/usr/local/src/redis/conf】
wget http://download.redis.io/redis-stable/sentinel.conf
说明：哨兵其实也是一个单独的 Redis 实例，因此我们在之前配好3个 Redis 实例的基础上，再使用一个 Docker 启动哨兵的实例，直接带上sentinel.conf 配置文件开启哨兵模式就OK了。
我们先了解一下sentinel.conf 配置文件（默认，不用修改下面2点）
port 26379。哨兵配置文件默认端口号。daemonize no。让 redis 服务在后台运行(因为使用docker启动时使用了-d参数，所以需要设置为no, 非docker设置为yes)。
然后修改sentinel.conf 配置文件的关键信息，①②这2项信息必须要配置啊，否则无法自动切换主从的：
①修改sentinel.conf 配置文件绑定的 IP 为 0.0.0.0 ，默认什么 IP 都可以，测试方便啊。上线后记得绑定指定的 IP 地址。
②修改节点名称等信息，以及配置登录密码。我们这次选举1次，得1票就可以了。方便测试啊
# 配置 主节点,名称,IP,端口号,选举次数sentinel monitor mymaster 192.168.0.105 6379 1# 因为 Redis 服务器配置了密码连接，因此需要加上密码sentinel auth-pass mymaster 123456
③修改心跳检测 30毫秒，默认是 30 秒（太长了，测试阶段要等待太久，因此改30毫秒，相当于实时）。
sentinel down-after-milliseconds mymaster 30
OK，配置完毕，我们启动测试。
1、按照第一篇博客的内容先启动3个 Redis 实例，6379为主节点，6380、6381是从节点。
2、启动哨兵实例：（需要根据实际路径 sentinel.conf 进行挂载）
docker run -p 26379:26379 --name sentinel \-v /usr/local/src/redis/conf/sentinel.conf:/etc/redis/sentinel.conf \-d redis redis-sentinel /etc/redis/sentinel.conf \--requirepass "123456"
启动结果：如果启动不成功，考虑关闭防火墙。不懂防火墙命令？查看博客：/BiandanLoveyou/article/details/116399225
使用docker logs 容器ID查看哨兵实例的日志。
看到 6380 和 6381 两个实例已经作为 6379 的从节点了。
3、验证哨兵模式
我们停掉 6379 主节点的 Redis 实例模拟宕机情况。docker rm -f 容器ID
4、使用docker logs 容器ID查看哨兵实例的日志。
看到主节点已经自动切换成 6381 这个 Redis 实例了。
5、在 Redis-desktop 测试一下：这时候发现 6381 是主节点，可以读写了。
然后去 6380 读取
没毛病，老铁们！
6、然后我们重新启动以前的主节点 6379，会有什么效果？
这时候，看到 6379 变成 6381 的从节点了。6379 只能读，不能写了。
注意：要想 6379 重启后能加入到集群并且可以主从复制，还必须配置6379的redis.conf 的masterauth 密码。这在上一篇博客有说明。这个是访问主库的密码。比如我的主库密码是 123456。3个配置文件都需要修改，因为集群里是需要密码登录的，如果 6379 不加密码，能加入集群，但是无法做主从复制！！
masterauth 123456
就比如：6381 已经修改数据了
但是 6379 获取的还是旧数据，并且无法实现主从复制功能。
3、配置多哨兵模式
OK，在单哨兵的基础上，我们配置多哨兵。单哨兵是一台哨兵实例在工作，而多哨兵是多个 Redis 实例在工作，哨兵之间也相互通讯，确认各自的信息。
1：复制两份sentinel.conf 文件，分别命名：sentinel01.conf、sentinel02.conf
[root@localhost conf]# cp sentinel.conf sentinel01.conf [root@localhost conf]# cp sentinel.conf sentinel02.conf [root@localhost conf]# lsredis6380.conf redis6381.conf redis.conf sentinel01.conf sentinel02.conf sentinel.conf
2、修改sentinel01.conf 端口号为 26380、sentinel02.conf 端口号为 26381。
3、修改 3 个配置文件的选举票数：一般为哨兵总数÷2 再加1，也就是超过一半的哨兵数就OK了。
注意：配置主节点的 【主机IP和端口】要3个都统一，否则无法选举 master。
4、配置完之后，我们重新启动 3 个 Redis 实例和 3 个哨兵实例。（先把之前的 docker 实例全部删除。 docker rm -f xxx yyy zzz）
这里列出3个哨兵的启动命令：
端口号为26379 的：
docker run -p 26379:26379 --name sentinel \-v /usr/local/src/redis/conf/sentinel.conf:/etc/redis/sentinel.conf \-d redis redis-sentinel /etc/redis/sentinel.conf \--requirepass "123456"
端口号为 26380 的：
docker run -p 26380:26380 --name sentinel01 \-v /usr/local/src/redis/conf/sentinel01.conf:/etc/redis/sentinel.conf \-d redis redis-sentinel /etc/redis/sentinel.conf \--requirepass "123456"
端口号为 26381的：
docker run -p 26381:26381 --name sentinel02 \-v /usr/local/src/redis/conf/sentinel02.conf:/etc/redis/sentinel.conf \-d redis redis-sentinel /etc/redis/sentinel.conf \--requirepass "123456"
启动结果：
5、验证多哨兵模式
通过查看某一台哨兵的日志：docker logs 容器ID
可以看到现在的 master 是 6380：
6380 有读写的操作：
而 6379 和 6381 只能读：
现在模拟 6380 宕机的情况：docker rm -f 容器ID
通过某一台哨兵的日志可以查看变化情况：
这时候，6379 这台 Redis 变成 master 了。
OK，这就完成了 Redis 哨兵集群的搭建。一般来说，如果业务量很大，才考虑使用 Redis 集群，而且实际部署多个哨兵的时候，不能部署到同一台机器，避免机器遇到物理故障，几个哨兵都没法工作，应该分开机器部署。
