Hollis的个人博客
Hollis的个人博客

Redis - 哨兵模式

Hollis Hollis 收录于 Redis 和 Redis
  约 3600 字 预计阅读 8 分钟  - 次阅读   - 条评论  

哨兵模式

介绍

Redis 哨兵模式是一种用于提高 Redis 高可用性的解决方案。在传统的 Redis 架构中，如果主节点（master）发生故障，整个系统可能会出现不可用状态。哨兵模式通过监控 Redis 实例的运行状态，并在主节点失效时自动执行故障转移，使系统能够在主节点故障时继续正常工作。

下面是 Redis 哨兵模式的详细介绍：

  1. 监控： Redis 哨兵进程（Sentinel）运行在独立的服务器上，通过周期性地检查 Redis 实例的健康状态来监控它们。哨兵可以监控多个 Redis 实例，以确保系统的高可用性。

  2. 故障检测： 当哨兵检测到主节点（master）不可用时，它会将其标记为故障。这可能是由于网络问题、进程崩溃或硬件故障等原因导致的。

  3. 故障转移： 一旦主节点被标记为故障，哨兵会选择一个从节点（slave）提升为新的主节点。它会发送命令给其他哨兵进程，协调进行故障转移操作。然后，哨兵会更新所有客户端的配置，使它们连接到新的主节点。

  4. 选举： 如果哨兵集合中的多个哨兵同时检测到主节点失效，它们将进行选举以确定负责执行故障转移的哨兵。这确保了系统的高可用性，即使部分哨兵集合也能继续工作。

  5. 配置管理： 哨兵还负责管理 Redis 实例的配置信息。它们会监视配置变化，并确保所有节点都使用相同的配置信息，以保持系统的一致性。

  6. 自动恢复： 一旦主节点恢复正常，哨兵会自动将其重新添加到 Redis 实例的集群中，并重新启用主从复制。这确保了系统在主节点故障后能够迅速恢复。

总的来说，Redis 哨兵模式通过监控、故障检测、故障转移、选举、配置管理和自动恢复等功能，提供了一种简单而强大的方法来实现 Redis 实例的高可用性。它可以确保即使在主节点故障时，系统仍然能够继续提供服务，从而降低了系统出现不可用的风险。

配置哨兵

在 Redis 哨兵模式中，sentinel.conf 是哨兵配置文件，其中的 sentinel monitor 命令用于配置哨兵监视的 Redis 主节点。下面是该命令的详细介绍：

1

SENTINEL MONITOR <master-name> <ip> <port> <quorum>

  • <master-name>：指定要监视的 Redis 主节点的名称。这个名称在整个哨兵集群中必须是唯一的，并且在配置其他哨兵、执行故障转移等操作时会使用到。

  • <ip>：指定要监视的 Redis 主节点的 IP 地址。

  • <port>：指定要监视的 Redis 主节点的端口号。

  • <quorum>：指定用于进行故障检测和故障转移的投票数。在哨兵集合中，必须有超过 quorum 个哨兵认为主节点不可用时，才会执行故障转移。这有助于避免误报和错误的故障转移。

    quorum 表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数。

例如，如果要监视一个名为 mymaster 的 Redis 主节点，其 IP 地址为 127.0.0.1，端口号为 6379，并且设置 quorum 为 2，则可以执行以下命令：

1

SENTINEL MONITOR mymaster 127.0.0.1 6379 2

这将配置哨兵以监视名为 mymaster 的 Redis 主节点，并设置 quorum 为 2，这意味着至少需要有两个哨兵认为主节点不可用时才会执行故障转移。

其他参数配置

  • bind：服务监听地址，用于客户端连接，默认本机地址

  • daemonize：是否以后台 daemon 方式运行

  • protected-model：安全保护模式

  • port：端口

  • logfile：日志文件路径

  • pidfile：pid 文件路径

  • dir：工作目录

    -sentinel auth-pass <master-name> <password>：master 设置了密码，连接 master 服务的密码

    • 其他
      sentinel down-after-milliseconds <master-name> <milliseconds> 指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
      sentinel parallel-syncs <master-name> <nums> 表示允许并行同步的 slave 个数，当 Master 挂了后，哨兵会选出新的 Master，此时，剩余的 slave 会向新的 master 发起同步数据
      sentinel failover-timeout <master-name> <milliseconds> 故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
      sentinel notification-script <master-name> <script-path> 配置当某一事件发生时所需要执行的脚本
      sentinel client-reconfig-script <master-name> <script-path> 客户端重新配置主节点参数脚本

启动哨兵

Redis Sentinel 可以以两种方式启动：

  1. redis-sentinel： 使用命令行方式启动 Redis Sentinel 时，需要在命令行中指定哨兵的相关参数，如监听地址、端口号、日志文件路径等。以下是一个示例命令：

    1

    redis-sentinel /path/to/sentinel.conf

    其中，/path/to/sentinel.conf 是哨兵配置文件的路径。

  2. redis-server 命令并附加 --sentinel 参数

    1

    redis-server /path/to/sentinel.conf --sentinel

客观/主观下线

在 Redis 中，有两种类型的节点下线：客观下线（objective down）和主观下线（subjective down）。它们用于哨兵模式中的故障检测和故障转移。

  1. 客观下线（Objective Down）： 客观下线是指一个节点被多个独立的监控节点（哨兵）检测到不可用，从而被标记为不可用。这种下线是基于多个独立的检测结果，因此更可信。在哨兵模式中，客观下线通常由多个哨兵共同判断主节点不可用时触发。

  2. 主观下线（Subjective Down）： 主观下线是指一个节点被单个监控节点（哨兵）检测到不可用，但尚未得到其他节点的确认。这种下线是基于单个检测结果，因此相对不太可信。在哨兵模式中，当单个哨兵检测到主节点不可用时，会将其标记为主观下线，但只有当多个哨兵都检测到主节点不可用时，才会触发客观下线。

这两种下线的区别在于触发它们的条件和检测的可信度。客观下线需要多个哨兵共同确认，因此更可靠，而主观下线只需要单个哨兵检测到，相对来说不太可靠。在哨兵模式中，客观下线通常会触发故障转移操作，而主观下线则可能只是一个预警信号，需要进一步确认。

注意事项

  1. 主机也需要配置 masterauth

    由于主机后续可能会变成从机，所以需要使用 masterauth 设置访问新主机的密码，不然后续可能报错：master_link_status:down。

    主机和从机的密码最好设置相同密码，因为存在主从的切换。

  2. 之前 down 机的主机器重启回来，它会变成从机，之前的从机变成主机，它们的配置文件都会自动重写。

    两个配置文件的变化：

    老 master 的 redis.conf 文件

    旧master配置文件重写

    新 master 的 redis.conf 文件

    slave升master配置文件重写

  3. Master-Slave 切换后，master_redis.conf、slave_redis.conf 和 sentinel.conf 的内容都会发生改变，sentinel.conf 的监控目标会随之调换。

  4. 一般会设置多个哨兵（奇数个），生产都是不同机房不同服务器，很少出现多个哨兵全挂掉的情况。

  5. 可以同时监控多个 master，一行一个。

哨兵运行流程和选举原理

当一个主从配置中 master 失效后，sentinel 可以选举出一个新的 master 用于自动接替原 master 的工作，主从配置中的其他 redis 服务器自动指向新的 master 同步数据，一般建议 sentinel 采取奇数台，防止某一台 sentinel 无法连接到 master 导致误切换

运行流程，故障切换

  • 三个哨兵监控一主二从，正常运行中

    哨兵架构

  • SDown 主观下线 (Subjectively Down)

    1. SDOWN（主观不可用）是单个 sentinel 自己主观上检测到的关于 master 的状态，从 sentinel 的角度来看，如果发送了 PING 心跳后，在一定时间内没有收到合法的回复，就达到了 SDOWN 的条件。

    2. sentinel 配置文件中的 down-after-milliseconds 设置了判断主观下线的时间长度

    3. 说明

      主观下线说明

  • ODown 客观下线 (Objectively Down)

    1. ODOWN 需要一定数量的 sentinel，多个哨兵达成一致意见，才能认为一个 master 客观上已经宕机

    2. 说明

      ODown客观下线说明

    quorum 这个参数是进行客观下线的一个依据，法定人数 / 法定票数。

    意思是至少有 quorum 个 sentinel 认为这个 master 有故障才会对这个 master 进行下线以及故障转移。因为有的时候，某个 sentinel 节点可能因为自身网络原因导致无法连接 master，而此时 master 并没有出现故障，所以这就需要多个 sentinel 都一致认为该 master 有问题，才可以进行下一步操作，这就保证了公平性和高可用。

  • 选举出领导者哨兵 (哨兵中选出兵王)

    主哨兵解释

    1. 当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个 领导者哨兵节点（兵王） 并由该领导者也即被选举出的兵王进行 failover（故障转移）。

      哨兵日志文件解读分析

      哨兵兵王选举

    2. 哨兵领导者，兵王如何选出来的？-> Raft 算法

      Raft算法

      监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是 Raft 算法；Raft 算法的基本思路是先到先得：即在一轮选举中，哨兵 A 向 B 发送成为领导者的申请、如果 B 没有同意过其他哨兵，则会同意 A 成为领导者。

  • 由兵王开始推动故障切换流程并选出新的 master

    1. 新主登基

      -某个 Slave 被选中成为新 Master

      • 选出新 master 的规则，剩余 Slave 节点健康前提下，会按下图规则进行选举

        新master选举

        1. redis.conf 文件中，优先级 slave-priority 或者 replica-priority 最高的从节点 （数字越小优先级越高）

        从节点升级为主节点默认优先级

        1. 复制偏移位置 offset 最大的从节点 (也就是在 master 还没有宕机时，复制到数据比其他 Slave 要多)
        2. 最小 Run ID 的从节点，字典顺序，ASCII 码。

    2. 群臣俯首

      一朝天子一朝臣，换个码头重新拜

      • 执行 slaveof no one 命令让选出来的从节点成为新的主节点，并通过 slaveof 命令让其他节点成为其从节点
      • sentinel leader 会对选举出的新 master 执行 slaveof on one 操作，将其提升为 master 节点
      • sentinel leader 向其他 slave 发送命令，让剩余的 slave 成为新的 master 节点的 slave

    3. 旧主拜服

      老 master 回来也认怂，会被降级为 slave

      • 老 master 重新上线后，会将它设置为新选出的 master 的从节点
      • sentinel leader 会让原来的 master 降级为 slave 并恢复正常工作

    4. 小总结

      上述的 failover 操作均由 sentinel 自己独自完成，完全不需要人工干预

      选举新master总结

哨兵使用建议

  1. 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
  2. 哨兵节点的数量应该是奇数
  3. 各个哨兵节点的配置应一致
  4. 如果哨兵节点部署在 Docker 等容器里面，尤其要注意端口的正确映射
  5. 哨兵集群 + 主从复制，并不能保证数据零丢失，所以需要使用集群。
收录于 合集・Redis 13
更新于 2025-04-08 
CC BY-NC-SA 4.0
Redis
返回 | 主页
0%