Redis 集群帮我们解决了failover的问题，以及sharding的问题。简单来讲，redis集群通过复制，以及选主策略来解决failover的问题；redis通过重新分片的机制来解决数据sharding的问题。现在对于这两个问题，我们深入剖析一下。
sharding 问题
当我们在redis集群中新增加一台机器，并且将相关的槽分配给新增的机器。那么需要解决两个问题第一问题，客户端如何感知新增的节点；第二个问题，在进行数据迁移的时候，客户端找不到相应的数据如何处理。
Redis集群，在进行数据迁移的过程需要记录迁移每一个key的情况，在客户端获取相应的key对应的值的时候，客户端根据之前的服务节点，进行hash算法，定位相应的服务节点，但是这个节点的上的访数据已进行进行了迁移至新的服务 节点，此时redis集群并不是简单的报找不到错误，或者返回null，而是返回一种特殊类型的错误，在jedis中定义为JedisMovedDataException.在这个异常中客户端能够获取到该key已经moved到哪个节点。
客户端需要处理这个错误，处理步骤：
第一步刷新整个客户端与redis集群所建立连接的缓存，而重新连接，这样客户端，就能够将新增加进行redis集群节点找到。即解决了，上面的第一个问题。
在第一步的基础之上，redis客户端，只需要一步重试，就可以找到相应的节点的，并查询相应的数据值 了，即解决了数据迁移的时候数 据找不到的问题，解决了上面提到的第二个问题。
通过这种机制，redis集群，在进行重新分片的时候，是不需要考虑数据的分片时长。Redis集群帮我们搞定了数据自动分片问题。
failover问题
简单讲，redis集群依然采用主从复制的机制来保证集群的高可用。对于集群中的主从，只有主节点是提供对外服务，而从节点，是不对外进行服务的。当主节点宕机之后从节点通过选主机制提升为主节点然后对外提供服务。在这里有几个细节问题。现描述如下：
在redis集群中每一个节点都 会定期发送ping到集群中的其他节点，以获取对方节点状态。当对方节点，无法在规定的时间点内返回pong，此节点就将对方节点的状态标记为疑似下线。
当有第一个超半数主节点，判定该节点为疑似下线，则将此节点村记为下线，并广播出去。
从节点收到广播消息，得到它的主节点已下线，得发出选主请求。通过基于raft的算法选出一个主，提升为主节点，并接管之前宕机节点的所有槽处理。而在此之前，客户端如果请求相应的宕机节点，会一直报连接异常。在jedis中体现为JedisConnectionException。并且一直重试，当重试的次数达到一定数量时，得新刷新客户与redis集群所建立的长连接缓存。如果此时从机选主完成，并且提升为主机，则通过重试就可以获相应的连接，并调用成功。这样redis集群就解决failover问题。
1.Redis设计与实现 黄健宏