Redis高可用方案的实现原理

Redis哨兵模式
哨兵也是一种特殊的redis，哨兵节点采用raft一致性算法，所以要求哨兵节点至少3个并且奇数。
1、每个哨兵每秒对各个Redis数据节点做心跳检测。
2、如果发现某个节点超时未响应，则对该节点进行主观下线。
如果主管下线的节点是master节点，还要咨询其他的哨兵节点，如果过半节点都认为该节点下线，则对该节点做客观下线。
3、同时这也是一个选主的过程，一般第一个发现主观下线的节点，会被选为leader哨兵节点。
4、由leader哨兵节点对redis数据节点进行故障转移。
1）leader哨兵节点对数据节点进行选主，首先要节点健康，优先选择高优先级的节点，然后选择复制偏移量最大的，然后看runid最小的。
2）将该节点设置为新的主节点。
3）将其他从节点的主节点的切换到新的主节点上。
4）如果老的主节点恢复了，将老的主节点也作为新的主节点的从节点。
5、客户端监听配置的变化。

附：3个定时监控任务
1、每10秒，每个哨兵节点向所有数据节点发送info命令，更新数据节点的拓扑信息，包括感知新增、下线节点，以及节点信息，哪个是主节点等。
2、每2秒，每个哨兵节点向__sentinel__:hello频道发送当前节点的信息和当前节点对主数据节点的判断，并且订阅该频道。目的：1）更新哨兵节点的拓扑信息，包括哨兵节点的增删。2）交换各个哨兵节点对主节点的判断。
3、每1秒，每个哨兵节点向所有数据节点和其他哨兵节点发送ping命令做心跳检测。

Redis集群模式
为了解决单点内存有限的问题，数据分区。
1、集群内，gossip协议，每秒给指定数目的节点发送ping消息，做数据同步。
2、发现某个节点超时未响应ping消息，进行主观下线。
3、当半数以上持有槽的主节点都标记该节点主观下线时，触发客观下线流程。
a）Q：为什么必须是主节点？
A：集群模式下，主节点才负责读写请求（从节点只是备份数据，不负责提供读写）和集群槽等关键信息的维护。
b）Q：为什么要求半数以上？
A：防止因为网络分区等原因造成集群分割。小集群因为无法完成从主观下线到客观下线这一关键过程，从而可以防止继续对外提供服务。
4、当确认为客观下线时，通知集群内的所有节点标记故障节点为客观下线状态并立刻生效。同时，通知故障节点的从节点触发故障转移流程。
5、如果故障节点是主节点，需要在它的从节点中选举一个新的主节点。
a）从节点的资格检查，必须与其他的主节点通信正常。
b）准备选举时间。
c）发起投票，从节点没有投票权，因为要大于等于3个节点才能凑够N/2+1个节点，导致从节点浪费资源。所以使用其他的主节点进行投票选举。
d）替换主节点。

哈希取余
实现简单，但是扩容缩容需要全部数据都要调整，适用于数据库场景。
一致性哈希算法
哈希环，增删分区时，只需要调整部分节点即可，适用于缓存场景。
缺点：
1、负载不均衡。
2、一个节点过载宕机，可能会导致雪崩。
哈希槽
哈希环上放置虚拟节点，key不直接映射真实节点，先映射到虚拟节点（哈希槽），然后再通过虚拟节点映射到真实节点。
这样就能很好的解决了一致性哈希带来的问题了。
Q：为什么要求一定是闭合的环？
A：如果最大值的节点挂掉，原本存储在他里面的key存哪里呢？
参考：https://www.jianshu.com/p/b208804dce9c
1