锐客网

  1. 首页 > it技术 > >

java开发技术之Redis入门篇集群模式的分析

Redis的哨兵模式帮我们解决单数据节点（主节点）发生故障时，来保证服务的高可用。如果仅仅靠单个主节点来存储数据，这完全满足不了java培训大数据量场景。所以我们必须通过分布式存储数据来解决这一问题，目前Redis采用虚拟槽分区的方案进行解决，本篇只会讲解到集群模式中的一些基础性概念。
虚拟槽分区
什么是虚拟槽分区呢？就是有0～16383个槽均匀分配给集群中的所有主节点，在数据存储时，会根据指定的哈希函数运算出key对应的槽位置，即可知道该key应存入集群中的哪个节点。
Smart客户端
在任何一台主节点查询指定的key时，发现没有命中本台机器会告诉客户端重定向到指定的机器获取该key。极端的情况下会导致每次要获取key时都要走两次请求才能获取到，因此通过Smart客户端能够解决这一问题,它实现了从键到槽到节点的映射。
故障转移
主从复制的模式下可以使用哨兵机制来实现主从切换，进而保证高可用。那么集群模式下Redis又是如何保证高可用的呢？在讲解之前我们先来看看一般集群模式下的Redis部署结构:
java开发技术之Redis入门篇集群模式的分析
文章图片

Redis在进行故障转移时会进行两大步骤 1. 故障发现 2. 故障恢复
? 故障发现
集群中的任何一个节点都会通过ping/pong的消息来检测除自身以外的所有节点存活状态，如果存活则会更新对应节点的检测时间。后面会通过定时任务扫描检测时间是否与当前时间之差大于cluster-node-time，如果是标记该节点为主观下线（节点并未进行下线操作）。下次再进行检测存活时会携带它认为主观下线的节点进行传播。每个节点自身都会维护一份集群内节点被主观下线的报告，当发现其中某个节点的主观下线报告数量达到集群内节点数量的一半以上，将会触发客观下线（真实进行节点下线操作），即通知集群内存活节点，该节点已线下。
? 故障恢复
【java开发技术之Redis入门篇集群模式的分析】从节点通过内部的定时任务发现主节点客观下线之后，会出触发故障恢复流程，也就是必须选举出一个从节点作为主节点。首先每个节点都会进行资格检查，检查自身与主节点连接断开的时间是否小于cluster-node-time*cluster-slave-validity-factor，如果不是则不符合选举条件。符合选举条件之后会根据自身复制偏移量的大小确定准备选举的时间，偏移量越大的准备选举时间越早。待时间到时从节点会发起选举，在集群内进行广播选举消息，收到消息的主节点会进行响应投票，当票数达到集群数量一半以上则该节点被选举成功，进行故障转移实现主从切换。否则投票失败，等待下个节点（下次）发起选举。

    推荐阅读


    上一篇：sonar搭建

    下一篇：基于Renode调试OneOS-Lite物联网操作系统