Redis哨兵《Redis开发与运维读书笔记》

主从复制的问题：

1）主节点故障需要手动干预将从节点提升为主节点，同时需要修改应用方的主节点地址
2）主节点写能力收单节点限制
3）主节点储存能力收单节点限制

Redis Sentinel的高可用

Redis在2.8版本之后提供，每个Sentinel会对数据节点和其他Sentinel节点进行监控。

Sentinel主要功能

• 监控
• 通知
• 主节点故障转移
• 配置提供者

实现原理

三个定时任务

• 每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。从而保证Sentinel节点中保存有最新的数据节点的拓扑结构。

• 每隔2秒，每个Sentinel节点会向Redis数据节点的 sentinel:hello频道发送该Sentinel节点对主节点的判断以及该Sentinel节点的信息。同时每个Sentinel节点也订阅这个频道来了解其他Sentinel节点已经他们对主节点的判断。

• 每隔1秒，每隔Sentinel节点会向主节点、从节点、其他Sentinel节点发送一条ping命令做一次心跳检查，来判断这些节点是否可达。
  1）主观下线：如果某些节点超时未回复则该Sentinel节点已下线
  2）客观下线：如果主观下线的是主节点，则该Sentinel节点会向其他Sentinel节点发送命令询问它们对主节点的判断，如果超过个Sentinel节点认为主节点下线了，这个判断就是客观下线。

从节点、Sentinel节点节点客观下线后，没有后续故障转移操作。

故障转移

Redis会用 Raft算法 实现Sentinel节点主节点的选举。

Sentinel的主节点负责故障转移，首先在从节点中获取 优先级高 的从节点，如果优先级都一样或者都没有设置，则找到 复制偏移量最大 的从节点，如果复制偏移量都一样则找 runid最小 的节点。

客户端逻辑

Redis Sentinel客户端只有在初始化和切换主节点时需要和Sentinel节点集合进行交互来回去主节点信息，因此设计客户端时需要将Sentinel节点集合考虑成配置（相关节点信息和变化）发现服务。
主要流程：
1）客户端遍历Sentinel节点获取Redis主节点信息
2）保持和Sentinel节点联系，用户获取主节点的变化信息。

高可用读写分离

维护从节点的资源池，同时监听从节点的状态变化消息，及时添加新的从节点和删除不可用的从节点，从而达到高可用从节点读。

总结

在复制的基础上，哨兵实现了自动化的故障发现、故障自动转移、配置中心、客户端通知。

缺陷：写操作无法负载均衡；存储能力受到单机的限制。

关键点：
1）尽量将Redis哨兵部署在不同的物理机上
2）哨兵节点个数应大于等3个且最好为奇数。因为哨兵的选举是基于Raft算法的。
3）哨兵节点和其他Redis节点无差别，但是哨兵节点不存储数据，并且可以执行一些命令
4）客户端初始化时连接的是Sentinel节点集合，但是Sentinel节点只是配置中心不做代理。
5）Sentinel节点通过三个定时任务实现对主节点、从节点、其他Sentinel节点的监控。
6）Sentinel对节点做判断时分为主观下线和客观下线
7）Redis Sentinel实现读写分离高可用可以依赖Sentinel节点的消息通知，获取Redis数据节点的状态变化