共计 1045 个字符，预计需要花费 3 分钟才能阅读完成。
Redis 的哨兵模式帮咱们解决单数据节点（主节点）产生故障时，来保障服务的高可用。如果仅仅靠单个主节点来存储数据，这齐全满足不了 java 培训大数据量场景。所以咱们必须通过分布式存储数据来解决这一问题，目前 Redis 采纳虚构槽分区的计划进行解决，本篇只会解说到集群模式中的一些基础性概念。
虚构槽分区
什么是虚构槽分区呢？就是有 0～16383 个槽平均调配给集群中的所有主节点，在数据存储时，会依据指定的哈希函数运算出 key 对应的槽地位，即可晓得该 key 应存入集群中的哪个节点。
Smart 客户端
在任何一台主节点查问指定的 key 时，发现没有命中本台机器会通知客户端重定向到指定的机器获取该 key。极其的状况下会导致每次要获取 key 时都要走两次申请能力获取到，因而通过 Smart 客户端可能解决这一问题, 它实现了从键到槽到节点的映射。
故障转移
主从复制的模式下能够应用哨兵机制来实现主从切换，进而保障高可用。那么集群模式下 Redis 又是如何保障高可用的呢？在解说之前咱们先来看看个别集群模式下的 Redis 部署构造:
Redis 在进行故障转移时会进行两大步骤 1. 故障发现 2. 故障复原
• 故障发现
集群中的任何一个节点都会通过 ping/pong 的音讯来检测除本身以外的所有节点存活状态，如果存活则会更新对应节点的检测时间。前面会通过定时工作扫描检测时间是否与以后工夫之差大于 cluster-node-time，如果是标记该节点为主观下线（节点并未进行下线操作）。下次再进行检测存活时会携带它认为主观下线的节点进行流传。每个节点本身都会保护一份集群内节点被主观下线的报告，当发现其中某个节点的主观下线报告数量达到集群内节点数量的一半以上，将会触发主观下线（实在进行节点下线操作），即告诉集群内存活节点，该节点已线下。
• 故障复原
从节点通过外部的定时工作发现主节点主观下线之后，会出触发故障复原流程，也就是必须选举出一个从节点作为主节点。首先每个节点都会进行资格查看，查看本身与主节点连贯断开的工夫是否小于 cluster-node-time*cluster-slave-validity-factor，如果不是则不合乎选举条件。合乎选举条件之后会依据本身复制偏移量的大小确定筹备选举的工夫，偏移量越大的筹备选举工夫越早。待工夫到时从节点会发动选举，在集群内进行播送选举音讯，收到音讯的主节点会进行响应投票，当票数达到集群数量一半以上则该节点被选举胜利，进行故障转移实现主从切换。否则投票失败，期待下个节点（下次）发动选举。
