Redis -- 14 -- Redis哨兵模式搭建

相关文章：

• Redis – 01 – 什么是Redis

• Redis – 02 – Linux上源码包安装Redis

• Redis – 03 – 安装Redis可能出现的问题

• Redis – 04 – 配置Redis开机自启

• Redis – 05 – Redis常用数据类型

• Redis – 06 – Redis持久化方式之RDB

• Redis – 07 – Redis持久化方式之AOF

• Redis – 08 – Redis数据恢复

• Redis – 09 – Redis持久化方式之RDB-AOF混合模式

• Redis – 10 – IO多路复用模型

• Redis – 11 – 一致性哈希算法

• Redis – 12 – Redis集群搭建

• Redis – 13 – Redis主从同步搭建

• Redis – 14 – Redis哨兵模式搭建

---

官方文档：Redis Sentinel Documentation

---

之前我们通过不同的方式搭建了 Redis 集群，但是这样的 Redis 集群有个很大的弊端，就是不具备高可用性，因为一旦 Master 挂掉之后，整个 Redis 集群将不能对外提供写入操作，因此 Sentinel (Redis 哨兵) 应运而生

Redis Sentinel 是 Redis 官方提供的集群管理工具，其本身也是一个独立运行的 Redis 进程，它可以监控多个 Master-Slave 集群，当发现 Master 故障之后能进行自动的故障转移，主要有以下几个功能

• 监控 (Monitoring)

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

• 通知 (Notification)

  • 当被监控的某个 Redis 服务出现问题时，Sentinel 会通过 API 向管理员或其他应用程序发送故障通知

• 自动故障转移

  • 当一个 Master 不能正常工作时，Sentinel 会自动进行一次自动故障转移操作，它会将失效 Master 的其中一个 Slave 升级为新的 Master，并让失效 Master 的其他 Slave 去识别新的 Master 进行主从同步

  • 当客户端试图连接失效的 Master 时，集群会向客户端返回新的 Master 地址，使得集群可以使用新的 Master 代替失效的 Master

---

一、Redis 哨兵分布式性质

• Redis Sentinel 是一个分布式系统，我们可以在一个架构中运行多个 Sentinel 进程

• 这些 Sentinel 进程会使用流言协议 (gossip protocols) 来接收 Master 是否下线的信息，并使用投票协议 (agreement protocols) 来决定是否执行自动故障转移，以及选取哪一个 Slave 作为新的 Master

  • 流言协议 (gossip protocols)

    • 每个节点都随机地与对方通信，最终所有节点的状态达成一致

    • 种子节点定期随机地向其他节点发送节点列表以及需要传播的信息

    • 不保证消息一定会传播给所有节点，但是最终会趋于一致

---

二、Redis 哨兵工作流程

• 每个 Sentinel 以每秒一次的频率向它所知的 Master、Slave、Sentinel 发送 PING 命令

• 如果一个实例 (instance) 在指定时间内 (down-after-milliseconds)，没有返回 PING 命令的回复，那么该实例会被 Sentinel 标记为主观下线

  • 一个有效的回复可以是：+PONG、-LOADING、-MASTERDOWN

• 如果一个 Master 被标记为主观下线，那么正在监视这个 Master 的所有 Sentinel 会确认该 Master 是否确实进入了主观下线状态，当有足够数量 (quorum) 的 Sentinel 在指定时间内都同意这一判断，那么该 Master 会被标记为客观下线

  • 主观下线

    • 主观下线 (Subjectively Down，简称 SDOWN)，指的是单个 Sentinel 对服务器做出的下线判断

  • 客观下线

    • 客观下线 (Objectively Down，简称 ODOWN)，指的是多个 Sentinel 对同一台服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令相互交流之后，做出服务器下线的判断

    • 客观下线条件仅适用于 Master，对于任何其他类型的 Redis 实例 (Slave、Sentinel)，Sentinel 在将它们判断为下线前不需要进行协商，Slave、Sentinel 永远不会达到客观下线的条件

    • 当服务器处于客观下线状态，且获得大多数 (majority) Sentinel 的支持，才能发起一次自动故障转移

  • quorum 和 majority 的区别

    • quorum：确认服务器 ODOWN 的最少 Sentinel 数量

    • marjority：授权进行主从切换的最少 Sentinel 数量

    • 举例说明 (假设有 5 个 Sentinel，那么 marjority 则为 3)

      • 1、quorum < marjority，设置 quorum 为 2，如果有 2 (quorum) 个 Sentinel 认为某台服务器 ODOWN，则这 2 (quorum) 个 Sentinel 会选举出一个 Sentinel 来做故障转移，但这个 Sentinel 还需要得到 3 (marjority) 个 Sentinel 的授权，才能真正进行故障转移

      • 2、quorum >= marjority，设置 quorum 为 4，如果有 4 (quorum) 个 Sentinel 认为某台服务器 ODOWN，则这 4 (quorum) 个 Sentinel 会选举出一个 Sentinel 来做故障转移，此外由于 4 (quorum) >= 3 (marjority)，所以必须要 4 (quorum) 个 Sentinel 都同意授权，才能真正进行故障转移

• 当没有足够数量 (quorum) 的 Sentinel 同意 Master 下线，Master 的客观下线状态就会被移除，当 Master 重新向 Sentinel 的 PING 命令返回有效回复时，Master 的主观下线状态就会被移除

---

三、Redis 哨兵选举策略

• 如果一个 Master 被 Sentinel 标记为 ODOWN，且 majority 个 Sentinel 都同意授权，那么会有一个 Master 被选举出来，此时需要考虑以下信息

  • 跟 Master 断开连接的时长

  • Slave 的优先级

  • 复制偏移量

  • 运行 ID

• 如果一个 Slave 跟 Master 断开连接的时长已经超过了