引言
本文主要走查了Redis的集群模式的故障发现、故障转移流程。
由于Redis集群模式中存在过高的通信成本。
集群代理模式也常常作为自建缓存集群的方案。
第三部分对常见的缓存代理架构做了简述,文章主要内容有:
一、Redis集群模式的故障发现
二、Redis集群模式的故障转移
三、常见缓存代理架构方案简述
一、Redis集群模式的故障发现
Redis集群模式故障发现过程有主观下线与客观下线。
主观下线简单来说就是我这个节点认为你故障了。
客观下线则是集群中大多数节点认为你故障了。
这些判定与状态的同步均通过Gossip协议PING/PONG来通信。
主观下线流程
客观下线流程
二、Redis集群模式的故障转移
Redis集群模式从节点的作用用于灾备,主节点故障时能够替换顶上去。
Redis的从节点当然也不例外。
故障转移流程
从节点中复制的偏移量越大,替换主节点的优先级越高。
从节点获得持有槽的主节点一半以上的选票,可替换为主节点。
从节点向集群广播PONG消息,通知该变更。
三、常见缓存代理架构方案简述
Redis的集群模式客户端直连集群,不需要额外的组件,运维难度较低。
由于集群中每个实例都需要保存路由信息,彼此不断传播通信更新,也造成通信成本进而影响集群规模。
Redis的集群模式也会造成客户端需要重定向,带来复杂性。
因此,缓存代理模式可以解决这种复杂性,当然组件也会增多。
客服端:兼容RESP协议的轻量级客户端。
集群代理:负责域客户端建立连接,以及转发请求到对应的槽位和实例节点。
元数据中心:主要负责存储槽位与实例对应路由信息以及健康检查心跳探测。
集群模式一:集群部署主从架构,需要元数中心负责心跳的健康监测,主从节点的HA,当主节点故障切换从节点接管。
集群模式二:集群部署Raft组,不需要额外的HA心跳监测,集群自闭环,三个节点一组成本较高。
模式一
模式二
兼容RESP协议的轻量级客户端与代理建立长链接。
发送读写请求到代理层,代理根据路由规则将key路由到对应集群的槽位。
管理平台可对元数据信息、槽位分配、代理以及集群部署运维等进行管理。
可视化白屏化对整个集群的监控、告警、大key等水位监控告警。