1、Redis集群模式故障发现Redis集群模式故障发现过程有主观下线和客观下线。主观下线简单来说就是我的节点认为你有问题。客观地下线意味着集群中的大多数节点认为你宕机了。这些判断和状态的同步通过Gossip协议PING/PONG进行通信。主观下线过程@1定时向集群内其他节点发送PING报文@2如果超时（cluster-node-timeout）没有收到接收节点的PONG响应报文@3认为接收节点出现故障，标记为主观下线状态pfail客观下线过程@1Gossip协议PING/PONG通信承载集群其他节点1/10的状态，当然也包括主观下线节点信息@2接受节点维护故障节点下线report只处理发送给master节点的请求，from节点不处理不存在的故障节点的下线报告，并添加已存在的故障节点下线报告的下线报告，并更新上报时间@3尝试的故障节点的客观下线逻辑每次收到其他节点的故障状态pfail，都会尝试客观下线，监测故障下线报告是否过期，过期的报告将被删除。报告时间超过cluster-node-timeout*2且未更新，将被移除。下线报告数量小于持有slotsmaster节点数量1/10的2倍，退出objective下线报告数量大于持有slotsmaster节点数量的一半，标记objectiveoffline并广播fail消息给集群（markingobjectiveoffline立即生效，失效的slave节点发起failoverProcess）2.Redis集群模式的故障切换Redis集群模式的slave节点用于容灾，当master节点失效时可以替换。Redis从节点当然也不例外。谁会用多个从节点代替主节点？什么是选举逻辑和选举失效？故障转移过程从节点复制的偏移量越大，替换主节点的优先级越高。从节点获得持有槽位的主节点的半数以上选票，可以取代主节点。从节点向集群广播PONG消息以通知更改。3、常见缓存代理架构方案简述Redis的集群模式客户端直接接入集群，不需要额外的组件，运维难度相对较低。由于集群中的每个实例都需要保存路由信息，通信更新不断地相互传播，这也会造成通信成本，影响集群规模。Redis的集群模式也导致客户端需要重定向，带来了复杂性。所以缓存代理模式可以解决这个复杂度，当然组件也会增加。客户端：兼容RESP协议的轻量级客户端。Clusterproxy：负责为域客户端建立连接，并将请求转发到对应的槽位和实例节点。MetadataCenter：主要负责存储slot和instance对应的路由信息??，以及健康检查心跳检测。集群模式一：集群部署主从架构，需要元数据中心负责心跳的健康监控，主从节点的HA，当主节点出现故障时，从节点接管.集群方式二：Raft组部署在集群中，不需要额外的HA心跳监控，集群自封闭，三个节点为一组成本比较高。方式一方式二兼容RESP协议的轻量级客户端与代理建立长链接。向代理层发送读写请求，代理层根据路由规则将key路由到对应集群的slot。管理平台可以管理元数据信息、槽分配、代理、集群部署和维护。可视化白屏监控、告警、水位监控告警等全集群大键。
