Redis的哨兵模式帮助我们解决单个数据节点（主节点）故障的问题，保证服务的高可用。如果仅使用单个主节点存储数据，这不能满足大数据量的java训练的场景。因此，我们必须通过数据的分布式存储来解决这个问题。目前Redis采用的是虚拟槽分区的方案。本文只会讲解集群模式下的一些基本概念。虚拟插槽分区什么是虚拟插槽分区？即有0到16383个slot均匀分布到集群中的所有master节点。存储数据时，会根据指定的哈希函数计算key对应的slot位置，就可以知道key应该存放在集群中的哪个节点。。当Smartclient在任意一个master节点上查询指定的key，如果发现没有命中本机，就会告诉client重定向到指定的机器上去获取key。在极端情况下，每次需要两次请求才能获取密钥。因此，这个问题可以通过智能客户端来解决，实现从键到槽到节点的映射。在failover主从复制模式下，可以利用sentinel机制实现主从切换，保证高可用。那么Redis是如何保证集群模式下的高可用的呢？在解释之前，我们先看一下一般集群模式下的Redis部署结构：Redis在故障转移时会执行两个主要步骤1.故障发现2.故障恢复?故障发现集群中的任何一个节点都会通过ping/pong报文检测故障除自身以外的所有节点的存活状态，如果存活则更新对应节点的检测时间。后面会通过定时任务扫描，检测时间与当前时间的差值是否大于cluster-node-time，如果是，则将该节点标记为主观下线（该节点尚未下线）。下次它检测到存活时，它会携带它主观上认为离线的节点进行传播。每个节点都会维护一份集群内节点主观下线的报告。当发现某个节点的主观下线报告数量达到集群中节点数量的一半以上时，会触发客观下线（实际节点下线的上线操作），即通知集群中的存活节点节点已经下线的集群。?故障恢复从节点通过内部定时任务发现主节点客观下线后，会触发故障恢复流程，即必须选举一个从节点为主节点。首先，每个节点都会进行资格检查，检查自己与master节点的断开连接时间是否小于cluster-node-time*cluster-slave-validity-factor，否则不满足选举条件。满足选举条件后，根据自身复制偏移量的大小来决定准备选举的时间。偏移量越大，选举准备时间越早。当时间一到，Slave节点将发起一次选举，在集群中广播选举消息，收到该消息的Master节点将投票响应。当投票数达到集群一半以上时，该节点被选举成功，进行故障转移，实现主从切换。否则，投票失败，等待下一个节点（下一次）发起选举。
