redis RedissonShutdownException分析 redis all sentinels down

基础的准备工作：

解压3份Redis，为区分，文件夹命名改为端口号，具体可以参考上一篇博客

哨兵Sentinel

    Redis Sentinel 是一个分布式系统， 一个架构中可以运行多个 Sentinel 进程，一个 Sentinel 可以与其他多个 Sentinel 进行连接， 各个 Sentinel 之间可以互相检查对方的可用性，并进行信息交换。
    每个哨兵（sentinel）会向其它哨兵（sentinel）、master、slave 定时发送消息，以确认对方是否“活”着。如果发现对方在指定时间（可配置）内未回应，则暂时认为对方已挂（即所谓的“主观认为宕机”或“主观下线”：Subjective Down，简称 sdown）
    若“哨兵群”中的多数 sentinel 都报告某一 master 没响应，系统才认为 该master “彻底死亡”（即客观上的真正宕机或“客观下线”：Objective Down，简称 odown），通过一定的 vote 算法，从剩下的 slave 节点中，选一台提升为 master，然后自动修改相关配置

配置哨兵

因为windows系统下解压的Redis的zip文件夹中是不存在sentinel.cof文件的，那么我们需要手动来新建该文件

sentinel.conf的文件内容解读：（复制请复制下面的内容）

# ------------------------------------------------------------------------------------ #
# 这个是Redis-6379的配置内容，其它两个Redis-6380、Redis-6381同理新增然后改一下端口即可 #
# ------------------------------------------------------------------------------------ #
 
# 当前Sentinel服务运行的端口
# 在默认情况下，Sentinel 使用 TCP 端口 26379（普通 Redis 服务器使用的是 6379 ）
port 26379
 
# 哨兵监听的主节点mymaster；最后面的数字 3 表示最低通过票数；# 默认值 2
# 如果投票通过，则哨兵群体认为该主节点客观下线（odowm）
sentinel monitor mymaster 127.0.0.1 6379 3
 
# 哨兵认定当前主节点mymaster失效的判别间隔时间
# 如果在设置的时间内（毫秒），当前主节点没有响应或者响应错误代码，则当前哨兵认为该主节点主主观下线（sdown）
# 3s内mymaster无响应，则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
 
# 执行故障转移时，最多有1个从节点同时对新的主节点进行同步
# 当新的master上位时，允许从节点同时对新主节点进行同步的从节点个数；默认是1，建议保持默认值
# 在故障转移期间，将会终止客户端的请求
# 如果此值较大，则意味着"集群"终止客户端请求的时间总和比较大
# 反之此值较小，则意味着"集群"在故障转移期间，多个从节点仍可以提供服务给客户端
sentinel parallel-syncs mymaster 1
 
# 故障转移超时时间。
# 当故障转移开始后，但是在此时间内仍然没有触发任何故障转移操作，则当前哨兵会认为此次故障转移失败
sentinel failover-timeout mymaster 10000

sentinel.conf

port 26379
sentinel monitor mymaster 127.0.0.1 6379 3
sentinel down-after-milliseconds mymaster 3000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 10000

其他两个子节点6380和6381也要配置一下该文件，只需要修改port端口即可。

启动脚本编写

一个一个点击启动太麻烦了，制作简易启动脚本：

redis-6379-master-server.bat

@echo off
SET DIR=%~dp0\Redis_6379\
START %DIR%redis-server.exe %DIR%redis.windows.conf

redis-6379-sentinel.bat

@echo off
SET DIR=%~dp0\Redis_6379\
START %DIR%redis-server.exe %DIR%sentinel.conf --sentinel

redis-6379-mater-client.bat

@echo off
START %~dp0\Redis_6379\redis-cli.exe -p 6379

复制脚本，修改文件路径以及端口

 

启动Redis服务

依次执行 redis-6379-master-server.bat、redis-6380-slave-server.bat、redis-6381-slave-server.bat

redis启动成功后，启动哨兵，依次执行 redis-6379-sentinel.bat、redis-6380-sentinel.bat、redis-6381-sentinel.bat

启动redis的客户端

此时，测试下是否满足高可用：

模拟redis6379主服务宕掉，在6379的客户端上关闭主服务：

shutdown

观察哨兵26380

再次重启6379，执行redis-6379-master-server.bat，再次启动 6379 服务器，发现 6379 成为 6380 的从服务器，当重启之前的故障master 时，它连向了新master，而且 原master 成了 新master 的一个从节点。

如果关掉其中一个从节点，主节点增加键值，从节点宕机重启恢复后，还是会以从节点身份连master，不会影响master。而且，从节点 能照常读取到 master 在其宕机期间新增的键值。