问题
- Redis 主哨兵模式是如何保证高可用的 主要依赖主哨兵的发现故障和故障转移
概述
本文假设读者对redis 的主从复制已经进行了了解 。 Redis 主哨兵集群为Redis 提供了高可用，即高可用是猪哨兵模式的主要目的，这是宏观上Sentinel功能的完整列表
- Monitoring ：监视实例的情况
- Notification : 通知
- Automatic failover : 当Master异常下线后，自动会通过选举
- Configuration provider : 提供配置信息。
注意事项
在配置哨兵模式下几件事需要注意 ：
- 至少保证3台实例
- 由于Redis使用异步复制，因此Sentinel + Redis分布式系统不能保证在故障期间保留已确认的写入。
- 开启 Sentinel后，客户端也需要支持 Sentinel 模式
工作流程
分布式服务器布局
主哨兵的可以是如下布局 
这是最简单的布局，Sentinel 依附在实例中，当实例 down 的话，那么 Sentinel 自然也会 down 掉，而图中的 quorum = 2 是什么意思呢，在后面章节再解释。二这种布局会出现分布式服务器“脑裂”问题，如下图
此时可以看到一台 replcation 成为了新的 master，而假如此刻客户端对 redis 进行写入那么数据将会丢失， redis.conf 中的两个参数可以设置
min-replicas-to-write 1 min-replicas-max-lag 10
使用以上配置，Redis实例在充当主实例时，如果无法写入至少1个副本，将停止接受写入。 由于复制是异步的，因此实际上无法写入意味着复制副本已断开连接，或者没有向我们发送异步确认超过指定的最大延迟秒数。
另外一种布局
或是
后面这两种的优势和缺点可见官网文档
流程
Sentinel 可以分为以下几个步骤
- 各个Sentinel认为 master 主观下线
- 多个 Sentinel 认为 master 客观下线
- 故障转移
检测主观下线状态
主观下线是什么意思呢？就是（站在Sentinel的角度）认为自己监听的 master 下线了，超过了某个心跳的时间没有回应。
检测客观下线状态
当Sentinel判定master 主观下线后，它就会去询问其他Sentinel是否他们也监控到master 下线了，当达到一定的数量，Sentinel 就会将服务器判定为客观下线，并对主服务器执行故障转移操作。而这个数量就是我们上面讲到的 quorum,上面的例子就是 ：当询问到有包括自己有两台 Sentinel 监控到master 下线了，那么就判定主服务器客观下线。
选举 Snentinel
为什么要选举 Snentinel 呢？现在主服务器下线了，那么需要选举一台 Sentinel 来进行协调工作，使得故障转移得以进行。那么如何选举呢？选举的方法和 Raft 的方式一样，本文不再重复，参阅参考资料 。
故障转移
故障转移共分为下面几步
- 选出新的主服务器
- 修改从服务器的复制目标
- 将旧的主服务器变为从服务器 第一步，选举新的主服务器的标准肯定是谁拥有最新的记录最有资格充当主服务器了（主从复制，复制一半主挂了），而第二步也很好理解，既然旧的主服务器已经挂了，新的被选出来，自然要修改从服务器的复制目标，最后旧的服务器变成从服务器。
底层实现
参阅以下链接
- https://www.cnblogs.com/renpingsheng/p/9803838.html 我们也可以从上面的工作原理猜测，Sentinel 不仅要有连接 master和 replication的通信通道，还要有连接其他的Sentinel的通信通道，以便监控判定主服务器客观下线和其他功能。
实践部分
使用docker 搭建主从集群
实践部分参照以下链接，在此表示感谢！
- https://www.cnblogs.com/bixiaoyu/p/10745874.html
我们将要搭建是这个布局的分布式 redis集群
先搭建docker ip相关。
docker network create --subnet=172.60.0.0/16 mynetwork
搭建之前我们需要redis.conf 和 sentinel.conf 文件，获取方法可以去下载redis的config文件夹下拿到。
master 主服务器
然后执行
docker run -d -p 6900:6900 -v /home/docker_software/redis/redis.conf:/usr/local/etc/redis/redis.conf -v /home/docker_software/redis/data:/data -v /home/docker_software/redis/sentinel_master.conf:/usr/local/etc/redis/sentinel.conf --name redis-ip-m --net=mynetwork --ip 172.60.0.2 docker.io/redis redis-server /usr/local/etc/redis/redis.conf --appendonly yes
-d: 后台运行-p: 端口映射-v: 挂载目录和文件，上面用于redis.conf 和 sentinel.conf 放进容器内，而/data 则是数据目录，因为 docker 停止后数据会丢失，所以/data 目录挂载在宿主机器中redis-server: 启动的服务/usr/local/etc/redis/redis.conf： 启动的配置（由于配置了挂载文件所以执行的挂载文件）-ip: 指定ip地址--appendonly yes: 运行参数，表明进行持久化
replication1 从服务器
修改redis.conf ,在最后一行加上
slaveof 172.60.0.2 6900 ##主从复制
执行
docker run -d -p 6901:6901 -v /home/docker_software/redis/redis1.conf:/usr/local/etc/redis/redis.conf -v /home/docker_software/redis/data1:/data -v /home/docker_software/redis/sentinel_r.conf:/usr/local/etc/redis/sentinel.conf --name redis-ip-r1 --net=mynetwork --ip 172.60.0.3 docker.io/redis redis-server /usr/local/etc/redis/redis.conf --appendonly yes
另外一台从服务器也是同样的步骤，搭建完后是这样的 ：
[root@localhost redis]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7bc085663022 docker.io/redis "docker-entrypoint..." 2 hours ago Up 2 hours 6379/tcp, 0.0.0.0:6902->6902/tcp redis-ip-r2 8eebf70c4a84 docker.io/redis "docker-entrypoint..." 2 hours ago Up 2 hours 6379/tcp, 0.0.0.0:6901->6901/tcp redis-ip-r1 28e0f66cbd40 docker.io/redis "docker-entrypoint..." 2 hours ago Up 2 hours 6379/tcp, 0.0.0.0:6900->6900/tcp redis-ip-m
共三台。
sentinel 监控
进入容器内，修改 sentinel.conf 文件，将
#sentinel myid b82a11362cfc53b1d8e552f04acada1d13946b11 注释掉 sentinel monitor mymaster 172.60.0.2 6900 2 logfile "/data/sentinel" #日志地址
注释掉因为其他两台从服务器的 sentinel.conf 也是指定这个id(搭建的时候复制了同一份 sentinel.conf)，其他配置看conf文件解释。
然后
/usr/local/bin/redis-sentinel /usr/local/etc/redis/sentinel.conf
其他两台服务器也是这样的步骤启动，然后到我们的日志地址看看日志输出
可以看到另外两台 sentinel也启动了。
故障转移测试
我们使用
docker stop 主服务器容器
把主服务器停了，看一下日志有什么变化。
我们可以看到成功地把从服务器变为了新的主服务器，并将旧的主服务器变为从服务器，实验成功！
参考资料
- https://redis.io/topics/cluster-tutorial/
- https://www.cnblogs.com/renpingsheng/category/1317158.html
- https://www.cnblogs.com/fan-gx/p/11463400.html
- https://www.cnblogs.com/bixiaoyu/p/10745874.html（主从搭建，推荐一看）