为什么代理架构常作为缓存实现方案

网友投稿 560 2023-04-23

为什么代理架构常作为缓存实现方案

为什么代理架构常作为缓存实现方案

一、Redis集群模式的故障发现

Redis集群模式故障发现过程有主观下线与客观下线。

主观下线简单来说就是我这个节点认为你故障了。

客观下线则是集群中大多数节点认为你故障了。

这些判定与状态的同步均通过Gossip协议PING/PONG来通信。

主观下线流程

@1 定时向集群中其他节点发送PING消息@2 超过时间(cluster-node-timeout)未收到接受节点PONG响应消息@3 认为该接受节点存在故障,标记为主观下线状态pfail

客观下线流程

@1 Gossip协议PING/PONG通信

携带集群1/10的其他节点状态

当然也包含主观下线节点的信息

@2 接受节点维护故障节点下线报告

只处理发送为主节点的请求,从节点不处理

不存在故障节点下线报告,新增下线报告

已存在故障节点下线报告,更新报告时间

@3 尝试故障节点的客观下线逻辑

每次收到其他节点的故障状态pfail时,均会尝试客观下线

监测故障下线报告是否过期,过期的报告将被删除

报告时间超过cluster-node-timeout*2未被更新将被移除

下线报告数量小于持有槽主节点的数量的二分之一,退出客观下线

下线报告数量大于持有槽主节点的数量的二分之一,标记客观下线

向集群广播一条fail消息(标记客观下线立即生效、故障从节点发起故障转移流程)

二、Redis集群模式的故障转移

Redis集群模式从节点的作用用于灾备,主节点故障时能够替换顶上去。

Redis的从节点当然也不例外。多个从节点谁去替换主节点?

选举逻辑以及选举失效是怎么样的?

故障转移流程

从节点中复制的偏移量越大,替换主节点的优先级越高。

从节点获得持有槽的主节点一半以上的选票,可替换为主节点。

从节点向集群广播PONG消息,通知该变更。

三、常见缓存代理架构方案简述

Redis的集群模式客户端直连集群,不需要额外的组件,运维难度较低。

由于集群中每个实例都需要保存路由信息,彼此不断传播通信更新,也造成通信成本进而影响集群规模。

Redis的集群模式也会造成客户端需要重定向,带来复杂性。

因此,缓存代理模式可以解决这种复杂性,当然组件也会增多。

客服端:兼容RESP协议的轻量级客户端。

集群代理:负责域客户端建立连接,以及转发请求到对应的槽位和实例节点。

元数据中心:主要负责存储槽位与实例对应路由信息以及健康检查心跳探测。

集群模式一:集群部署主从架构,需要元数中心负责心跳的健康监测,主从节点的HA,当主节点故障切换从节点接管。

集群模式二:集群部署Raft组,不需要额外的HA心跳监测,集群自闭环,三个节点一组成本较高。

模式一

模式二

兼容RESP协议的轻量级客户端与代理建立长链接。

发送读写请求到代理层,代理根据路由规则将key路由到对应集群的槽位。

管理平台可对元数据信息、槽位分配、代理以及集群部署运维等进行管理。

可视化白屏化对整个集群的监控、告警、大key等水位监控告警。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:用 Pandas 处理结构不佳的 Excel 文件
下一篇:Flowable 流程部署与删除
相关文章