No.173 为什么代理架构常作为缓存实现方案
引言
本文主要走查了Redis的集群模式的故障发现、故障转移流程。
由于Redis集群模式中存在过高的通信成本。
集群代理模式也常常作为自建缓存集群的方案。
第三部分对常见的缓存代理架构做了简述，文章主要内容有：
一、Redis集群模式的故障发现
二、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的集群模式客户端直连集群，不需要额外的组件，运维难度较低。
由于集群中每个实例都需要保存路由信息，彼此不断传播通信更新，也造成通信成本进而影响集群规模。
Redis的集群模式也会造成客户端需要重定向，带来复杂性。
因此，缓存代理模式可以解决这种复杂性，当然组件也会增多。
模式一
模式二
兼容RESP协议的轻量级客户端与代理建立长链接。
微信扫码关注该文公众号作者
戳这里提交新闻线索和高质量文章给我们。
来源: qq
点击查看作者最近其他文章