【Redis】哨兵

哨兵巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，从而继续提供服务，俗称无人值守运维。

---

一、哨兵作用

• 主从监控，监控主从redis库运行是否正常。
• 消息通知，哨兵可以将故障转移的结果发送道客户端。
• 故障转移，如果master异常，则进行 主从切换，将其中的一个salve作为新master
• 配置中心，客户端通过链接哨兵来获得当前redis服务的主节点。

---

二、Redis哨兵架构

设置一个包含三台哨兵的集群和一个包含一主二从的集群

• 3个哨兵：自动监控和维护集群，不存放数据
• 1主2从：用于数据读取和存放

先配置一主二从集群
再配置三台哨兵的集群，并进行实验

---

三、哨兵运行流程和选举原理

3.1、哨兵运行流程

• SDown主观下线
    SDown是单个sentinel自己主观上检测到的关于master的状态，从sentinel角度来看，如果发送了PING心跳后，在sentinel down-after-milliseconds给定的毫秒数内没有收到合法的回复，就达到了SDOWN的条件。

• ODown客观下线
    ODown需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机了。因为有些时候某个sentinel节点因为自身问题无法连接master，master本身没有问题，这就需要多个sentinel一致认为该master有问题，才能进行下一步操作，保证了公平性和高可用。

• 3.3、选举领导者哨兵
    当主节点被判断为客观下线后，各个哨兵节点会先选举出一个领导者哨兵节点，并由这领导者节点进行故障迁移。选举领导者哨兵的方式是Raft算法。

• 3.4 领导者哨兵推动故障切换流程并选出新master
    选出新master的规则为，在剩余slave节点健康的前提下，

  • 比较slave优先级（replica-priority），高的成为master，一样的话下一步
  • 比较复制偏移量（replication offset），大的成为master，一样的话下一步
  • 比较run ID，最小的成为新master

    之后领导者哨兵使用slave of no one将选出的slave节点提升为master，领导者哨兵向其他slave发送命令，使剩余slave成为新的master节点的slave。
    当老master重新上线后，领导者哨兵会让原来的master降级为slave并恢复正常工作。

3.2、领导者哨兵的选举原理–Raft算法

  Raft算法的本质是先到先得，在一轮选举当中，哨兵A向哨兵B发送成为领导者的申请，如果B没有同意过其他哨兵，则同意A成为领导者。

---

四、哨兵使用建议

• 哨兵节点应该为多个，且本身应该集群来保证高可用。
• 哨兵节点的数量应该是奇数。
• 各个哨兵节点的配置应该一致，比如内存大小等
• 如果哨兵节点部署在Docker里面，要注意端口的正确映射
• 哨兵集群+主从复制，并不能保证数据的零丢失，这是由于在master宕机后，哨兵选举新的master需要时间，在这段时间内无法向redis内写入数据，从而导致数据丢失。

---