Redis哨兵模式！

Redis 的 主从复制 模式下，一旦 主节点 由于故障不能提供服务，需要手动将 从节点 晋升为 主节点。

同时还要通知 客户端 更新 主节点地址。

  • Redis 2.8以后提供了Redis Sentinel哨兵机制 来解决这个问题。

Redis Sentinel的主要功能

Sentinel是一个管理多个Redis实例的工具，它可以实现对Redis的 监控、通知、自动故障转移。

监控

  • Sentinel 会不断的检查 主服务器 和 从服务器 是否正常运行。

通知

  • 当被监控的某个 Redis 服务器出现问题，Sentinel 通过 API 脚本 向 管理员 或者其他的 应用程序 发送通知。

自动故障转移

  • 当 主节点 不能正常工作时，Sentinel 会开始一次 自动的 故障转移操作。
  • 它会将与 失效主节点 是 主从关系 的其中一个 从节点 升级为新的 主节点，并且将其他的 从节点 指向 新的主节点。

配置提供者

  • 在 Redis Sentinel 模式下，客户端应用 在初始化时连接的是 Sentinel 节点集合，从中获取 主节点 的信息。

主观下线和客观下线

默认情况下，每个 Sentinel 节点会以 每秒一次 的频率对 Redis 节点和 其它 的 Sentinel 节点发送 PING 命令，并通过节点的 回复 来判断节点是否在线。

主观下线

  • 适用于所有 主节点 和 从节点。
  • 如果在 down-after-milliseconds 毫秒内，Sentinel 没有收到 目标节点 的有效回复，则会判定 该节点 为 主观下线。

客观下线

  • 只适用于 主节点。
  • 如果 主节点 出现故障，Sentinel 节点会通过 sentinel is-master-down-by-addr 命令。
    • 向其它 Sentinel 节点询问对该节点的 状态判断。
  • 如果超过 <quorum> 个数的节点判定 主节点 不可达，则该 Sentinel 节点会判断 主节点 为 客观下线。

工作原理

每个 Sentinel 以 每秒钟 一次的频率，向它所知的 主服务器、从服务器 以及其他 Sentinel 实例 发送一个 PING 命令。

如果一个 实例距离 最后一次 有效回复 PING 命令的时间超过 down-after-milliseconds 所指定的值。

  • 这个实例会被 Sentinel 标记为 主观下线。

如果一个 主服务器 被标记为 主观下线，并且有 足够数量 的 Sentinel在指定的 时间范围 内同意这一判断。

  • 那么这个 主服务器 被标记为 客观下线。

Sentinel 和其他 Sentinel 协商 主节点 的状态，如果 主节点 处于 SDOWN 状态，则投票自动选出新的 主节点。

将剩余的 从节点 指向 新的主节点 进行 数据复制。

img

脑裂问题

在 Redis 哨兵模式或集群模式中，由于网络原因，导致主节点（Master）与哨兵（Sentinel）和从节点（Slave）的通讯中断。

此时哨兵就会误以为主节点已宕机，就会在从节点中选举出一个新的主节点，此时 Redis 的集群中就出现了两个主节点的问题。

脑裂问题影响:

Redis脑裂问题会导致数据丢失。

当旧的 Master 变为 Slave 之后，的执行流程如下：

  • Slave（旧 Master）会向 Master（新）申请全量数据。
  • Master 会通过 Bgsave 的方式生成当前 RDB 快照，并将 RDB 发送给 Slave。
  • Slave 拿到 RDB 之后，先进行 Flush 清空当前数据（此时第四步旧客户端给他的发送的数据就丢失了）。
  • 之后再加载 RDB 数据，初始化自己当前的数据。

在执行到第三步的时候，原客户端在旧 Master 写入的数据就丢失了。

解决脑裂问题:

Redis提供了以下两个配置，通过以下两个配置可以尽可能的避免数据丢失的问题：

  • min-slaves-to-write：
    • 与主节点通信的从节点数量必须大于等于该值主节点，否则主节点拒绝写入。
  • min-slaves-max-lag：
    • 主节点与从节点通信的 ACK 消息延迟必须小于该值，否则主节点拒绝写入。

这两个配置项必须同时满足，不然主节点拒绝写入。