一、为什么需要哨兵在上一篇文章中我们搭建了Redis主从集群实现了读写分离提高了并发读写的能力。但主从架构存在一个致命问题当master节点宕机后整个集群将无法写入数据且需要人工介入才能恢复。Redis提供了哨兵机制来解决这个问题。哨兵的核心作用有三个监控持续检查master和slave是否按预期工作自动故障恢复master故障时。自动将一个slave提升为新的master通知作为Redis客户端的服务发现来源故障转移后将最新信息推送给客户端下面我们开始动手搭建二、集群机构规划我们在同一台虚拟机上开启3个Sentinel实例,组成sentinel集群用来监管之前搭建的Redis主从集群7001 master7002/7004 slave整体机构如下三个sentinel实例信息节点IPPORTs1192.168.8.10227001s2192.168.8.01227002s3192.168.8.10227003前置条件请确保Redis主从集群7001/7002/7003已经搭建并正常运行。如果还没有请参考前文《Redis主从集群搭建与数据同步原理详解》三、准备实例和配置3.1 创建目录要在同一台虚拟机开启3个实例必须准备三份不同的配置文件和目录配置文件所在目录也就是工作目录。# 进入/tmp目录cd/tmp# 创建目录mkdirs1 s2 s3创建完成后目录结构如下3.2 编写sentinel.conf在s1目录下创建一个sentinel.conf文件内容如下port27001sentinel announce-ip192.168.8.102 sentinel monitor mymaster192.168.8.10270012sentinel down-after-milliseconds mymaster5000sentinel failover-timeout mymaster60000dir/tmp/s1配置项解读port 27001当前sentinel实例的端口sentinel announce-ip 192.168.8.102声明当前sentinel的IP避免多网卡时通信混乱sentinel monitor mymaster 192.168.8.102 7001 2指定监控节点的主节点信息mymaster主节点名称可自定义任意写192.168.8.102 7001主节点的IP和端口2枚举master时的quprum值判断客观下线时所需的最少哨兵票数建议设置sentinel的一半以上sentinel down-after-milliseconds mymaster 5000主管下线判定时间5秒内无响应即认为主观下线sentinel failover-timeout mymaster 60000故障转移超时时间dir /tmp/s1工作目录3.3 拷贝并修改配置将 s1/sentinel.conf 拷贝到 s2、s3 两个目录# 方式一逐个拷贝cps1/sentinel.conf s2cps1/sentinel.conf s3# 方式二管道组合命令一键拷贝echos2 s3|xargs-t-n1cps1/sentinel.conf然后修改 s2、s3 两个文件夹内的配置文件将端口分别修改为 27002、27003工作目录同步修改sed-i-es/27001/27002/g-es/s1/s2/gs2/sentinel.confsed-i-es/27001/27003/g-es/s1/s3/gs3/sentinel.conf四、启动哨兵集群为了方便查看日志我们打开 3 个 ssh 窗口分别启动 3 个 sentinel 实例# 第1个redis-sentinel s1/sentinel.conf# 第2个redis-sentinel s2/sentinel.conf# 第3个redis-sentinel s3/sentinel.conf启动成功后可以看到类似如下的日志输出日志中可以看到 sentinel 已经成功连接到了 master 节点 7001并发现了它下面的两个 slave 节点。五、故障转移测试5.1 模拟master宕机我们尝试让 master 节点 7001 宕机redis-cli-p7001shutdown5.2 观看哨兵日志查看 sentinel 日志可以看到哨兵们开始协商判定 7001 主观下线 → 客观下线 → 选举 leader → 挑选新 master 的完整过程查看7003的日志查看7002的日志六、故障转移原理在测试过程中哨兵完成了以下关键步骤值得深入理解6.1 如何判断实例健康主观下线每个sentinel每秒向所有的实例发送ping命令若超过 down-after-milliseconds 未响应则标记为主观下线、客观下线若超过quorum数量的sentinel都认为该实例主观下线则标记为客观下线触发故障转移6.2 如何挑选新master哨兵按以下顺序筛选 slave 节点断开时长与 master 断开时间超过 down-after-milliseconds * 10 的 slave 被排除slave-priority值越小优先级越高0 表示永不参与选举offsetoffset 越大说明数据越新优先级越高运行 idid 越小优先级越高6.2 故障转移流程sentinel 给选中的 slave 发送 slaveof no one让它成为 mastersentinel 给其它 slave 发送 slaveof 新masterIP 新masterPort让它们成为新 master 的从节点将故障节点标记为 slave故障节点恢复后自动成为新 master 的 slave七、客户端如何感知变化搭建完哨兵集群后客户端不能直接连接master的IP否则故障转移后会连接失败。正确的做法是让客户端连接哨兵集群由哨兵返回当前master的地址。以spring boot为例在application.yml中配置哨兵信息即可spring:redis:sentinel:master:mymasternodes:-192.168.150.101:27001-192.168.150.101:27002-192.168.150.101:27003Spring 的 RedisTemplate 底层利用 Lettuce 实现了节点感知和自动切换客户端无需关心 master 的具体地址故障转移后会自动更新连接。 一、为什么需要哨兵在上一篇文章中我们搭建了Redis主从集群实现了读写分离提高了并发读写的能力。但主从架构存在一个致命问题当master节点宕机后整个集群将无法写入数据且需要人工介入才能恢复。Redis提供了哨兵机制来解决这个问题。哨兵的核心作用有三个监控持续检查master和slave是否按预期工作自动故障恢复master故障时。自动将一个slave提升为新的master通知作为Redis客户端的服务发现来源故障转移后将最新信息推送给客户端下面我们开始动手搭建二、集群机构规划我们在同一台虚拟机上开启3个Sentinel实例,组成sentinel集群用来监管之前搭建的Redis主从集群7001 master7002/7004 slave整体机构如下三个sentinel实例信息节点IPPORTs1192.168.8.10227001s2192.168.8.01227002s3192.168.8.10227003前置条件请确保Redis主从集群7001/7002/7003已经搭建并正常运行。如果还没有请参考前文《Redis主从集群搭建与数据同步原理详解》三、准备实例和配置3.1 创建目录要在同一台虚拟机开启3个实例必须准备三份不同的配置文件和目录配置文件所在目录也就是工作目录。# 进入/tmp目录cd/tmp# 创建目录mkdirs1 s2 s3创建完成后目录结构如下3.2 编写sentinel.conf在s1目录下创建一个sentinel.conf文件内容如下port27001sentinel announce-ip192.168.8.102 sentinel monitor mymaster192.168.8.10270012sentinel down-after-milliseconds mymaster5000sentinel failover-timeout mymaster60000dir/tmp/s1配置项解读port 27001当前sentinel实例的端口sentinel announce-ip 192.168.8.102声明当前sentinel的IP避免多网卡时通信混乱sentinel monitor mymaster 192.168.8.102 7001 2指定监控节点的主节点信息mymaster主节点名称可自定义任意写192.168.8.102 7001主节点的IP和端口2枚举master时的quprum值判断客观下线时所需的最少哨兵票数建议设置sentinel的一半以上sentinel down-after-milliseconds mymaster 5000主管下线判定时间5秒内无响应即认为主观下线sentinel failover-timeout mymaster 60000故障转移超时时间dir /tmp/s1工作目录3.3 拷贝并修改配置将 s1/sentinel.conf 拷贝到 s2、s3 两个目录# 方式一逐个拷贝cps1/sentinel.conf s2cps1/sentinel.conf s3# 方式二管道组合命令一键拷贝echos2 s3|xargs-t-n1cps1/sentinel.conf然后修改 s2、s3 两个文件夹内的配置文件将端口分别修改为 27002、27003工作目录同步修改sed-i-es/27001/27002/g-es/s1/s2/gs2/sentinel.confsed-i-es/27001/27003/g-es/s1/s3/gs3/sentinel.conf四、启动哨兵集群为了方便查看日志我们打开 3 个 ssh 窗口分别启动 3 个 sentinel 实例# 第1个redis-sentinel s1/sentinel.conf# 第2个redis-sentinel s2/sentinel.conf# 第3个redis-sentinel s3/sentinel.conf启动成功后可以看到类似如下的日志输出日志中可以看到 sentinel 已经成功连接到了 master 节点 7001并发现了它下面的两个 slave 节点。五、故障转移测试5.1 模拟master宕机我们尝试让 master 节点 7001 宕机redis-cli-p7001shutdown5.2 观看哨兵日志查看 sentinel 日志可以看到哨兵们开始协商判定 7001 主观下线 → 客观下线 → 选举 leader → 挑选新 master 的完整过程查看7003的日志查看7002的日志六、故障转移原理在测试过程中哨兵完成了以下关键步骤值得深入理解6.1 如何判断实例健康主观下线每个sentinel每秒向所有的实例发送ping命令若超过 down-after-milliseconds 未响应则标记为主观下线、客观下线若超过quorum数量的sentinel都认为该实例主观下线则标记为客观下线触发故障转移6.2 如何挑选新master哨兵按以下顺序筛选 slave 节点断开时长与 master 断开时间超过 down-after-milliseconds * 10 的 slave 被排除slave-priority值越小优先级越高0 表示永不参与选举offsetoffset 越大说明数据越新优先级越高运行 idid 越小优先级越高6.2 故障转移流程sentinel 给选中的 slave 发送 slaveof no one让它成为 mastersentinel 给其它 slave 发送 slaveof 新masterIP 新masterPort让它们成为新 master 的从节点将故障节点标记为 slave故障节点恢复后自动成为新 master 的 slave七、客户端如何感知变化搭建完哨兵集群后客户端不能直接连接master的IP否则故障转移后会连接失败。正确的做法是让客户端连接哨兵集群由哨兵返回当前master的地址。以spring boot为例在application.yml中配置哨兵信息即可spring:redis:sentinel:master:mymasternodes:-192.168.150.101:27001-192.168.150.101:27002-192.168.150.101:27003Spring 的 RedisTemplate 底层利用 Lettuce 实现了节点感知和自动切换客户端无需关心 master 的具体地址故障转移后会自动更新连接。