哨兵的作用和原理

slave 节点宕机恢复后可以找 master 节点同步数据，那 master 节点宕机怎么办？

Redis 提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下：

Redis 哨兵 - 图1

哨兵的作用

  • 监控：Sentinel 会不断检查 master 和 slave 是否按预期工作
  • 自动故障恢复：如果 master 故障，Sentinel 会将一个 slave 提升为 master。当故障实例恢复后也以新的 master 为主
  • 通知：Sentinel 充当 Redis 客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给 Redis 的客户端

服务状态监控

Sentinel 基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送 ping 命令：

  • 主观下线：如果某 Sentinel 节点发现某实例未在规定时间响应，则认为该实例主观下线。
  • 客观下线：若超过指定数量（quorum）的 Sentinel 都认为该实例主观下线，则该实例客观下线。quorum 值最好超过 Sentinel 实例数量的一半。

选举新的 master

一旦发现 master 故障，Sentinel 需要在 salve 中选择一个作为新的 master，选择依据是这样的：

  • 首先会判断 slave 节点与 master 节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该 slave 节点
  • 然后判断 slave 节点的 slave-priority 值，越小优先级越高，如果是 0 则永不参与选举
  • 如果 slave-priority 一样，则判断 slave 节点的 offset 值，越大说明数据越新，优先级越高
  • 最后是判断 slave 节点的运行 id 大小，越小优先级越高。

如何实现故障转移

当选中了其中一个 slave 为新的 master 后（例如 slave1），故障的转移的步骤如下：

  • Sentinel 给备选的 slave1 节点发送 slaveof no one 命令，让该节点成为 master
  • Sentinel 给所有其它 slave 发送 slaveof ip port 命令，让这些 slave 成为新 master 的从节点，开始从新的 master 上同步数据。
  • 最后，Sentinel 将故障节点标记为 slave，当故障节点恢复后会自动成为新的 master 的 slave 节点

哨兵的作用和原理小结

Sentinel 的三个作用是什么？

  • 监控
  • 故障转移
  • 通知

Sentinel 如何判断一个 redis 实例是否健康？

  • 每隔 1 秒发送一次 ping 命令，如果超过一定时间没有相向则认为是主观下线
  • 如果大多数 sentinel 都认为实例主观下线，则判定服务下线

故障转移步骤有哪些？

  • 首先选定一个 slave 作为新的 master，执行 slaveof no one
  • 然后让所有节点都执行 slaveof 新 master
  • 修改故障节点配置，添加 slaveof 新 master

搭建哨兵集群

三个 Sentinel 实例信息如下：

节点 IP PORT
s1 public-ip 27001
s2 public-ip 27002
s3 public-ip 27003

准备实例和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

我们创建三个文件夹，名字分别叫s1、s2、s3：

  1. # 进入/sentinel 目录
  2. cd /sentinel
  3. # 创建目录
  4. mkdir s1 s2 s3

然后我们在 s1 目录创建一个 sentinel.conf 文件，添加下面的内容：

  1. port 27001
  2. sentinel announce-ip 81.70.151.52
  3. sentinel monitor mymaster 81.70.151.52 7001 2
  4. sentinel down-after-milliseconds mymaster 5000
  5. sentinel failover-timeout mymaster 60000
  6. dir "/develop/redis/sentinel/s1"

解读：

  • port 27001：是当前 sentinel 实例的端口
  • sentinel monitor mymaster 81.70.151.52 7001 2：指定主节点信息
    • mymaster：主节点名称，自定义，任意写
    • public-ip 7001：主节点的 ip 和端口
    • 2：选举 master 时的 quorum 值

然后将 s1/sentinel.conf 文件拷贝到 s2、s3 两个目录中（在 /sentinel 目录执行下列命令）：

  1. # 方式一：逐个拷贝
  2. cp s1/sentinel.conf s2
  3. cp s1/sentinel.conf s3
  4. # 方式二：管道组合命令，一键拷贝
  5. echo s2 s3 | xargs -t -n 1 cp s1/sentinel.conf

修改 s2、s3 两个文件夹内的配置文件，将端口分别修改为 27002、27003：

  1. sed -i -e 's/27001/27002/g' -e 's/s1/s2/g' s2/sentinel.conf
  2. sed -i -e 's/27001/27003/g' -e 's/s1/s3/g' s3/sentinel.conf

启动

为了方便查看日志，我们打开 3 个 ssh 窗口，分别启动 3 个 redis 实例，启动命令：

  1. # 第1个
  2. redis-sentinel s1/sentinel.conf
  3. # 第2个
  4. redis-sentinel s2/sentinel.conf
  5. # 第3个
  6. redis-sentinel s3/sentinel.conf

Redis 哨兵 - 图2

Redis Template 的哨兵模式

在 Sentinel 集群监管下的 Redis 主从集群，其节点会因为自动故障转移而发生变化，Redis 的客户端必须感知这种变化，及时更新连接信息。Spring 的 Redis Template 底层利用 lettuce 实现了节点的感知和自动切换。

初始化工程：链接

首先，在 pom 文件中引入 redis 的 starter 依赖

  1. <dependency>
  2.     <groupId>org.springframework.boot</groupId>
  3.     <artifactId>spring-boot-starter-data-redis</artifactId>
  4. </dependency>

然后在配置文件 application.yml 中指定 sentinel 相关信息：

  1. spring:
  2.   redis:
  3.     sentinel:
  4.       master: mymaster # 指定master名称
  5.       nodes: # 指定redis-sentinel集群信息
  6.         - redis:27001
  7.         - redis:27002
  8.         - redis:27003

最后，配置主从读写分离

  1. @Bean 
  2. public LettuceClientConfigurationBuilderCustomizer configurationBuilderCustomizer(){
  3.     return configBuilder -> configBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
  4. }

这里的 ReadFrom 是配置 Redis 的读取策略，是一个枚举，包括下面选择：

  • MASTER：从主节点读取
  • MASTER_PREFERRED：优先从 master 节点读取，master 不可用才读取 replica
  • REPLICA：从 slave（replica）节点读取
  • REPLICA _PREFERRED：优先从 slave（replica）节点读取，所有的 slave 都不可用才读取 master