redis3.0版本开始支持集群功能，当我第一次学习它的时候，感觉它是我看到的第一个智能系统，后来发现很多同学的吐槽，太费网络资源，节点多的时候收敛慢，内部状态不确定，有问题很难定位等等，只知道优酷土豆在用，不过很多公司还是merge了它的部分功能。本文也是学习的总结，很多内容都是在网上看到的。

1、client配置

对于集群来说，client需要知道要操作的key在哪个shard上，key与shard之前的映射通常认为是客户端的配置，而redis中的数据是保存在16384个solt中的，因而这个配置包括两层映射，key->slot的映射和slot->shard的映射。

key->slot的映射是通过固定的算法计算出来了，如：CRC16（key）&16383。

slot->shard的映射在集群扩缩容后会动态变化，所以映射也需要动态的获取，redis通过MOVED命令动态探测slot的位置，如果client发送的key不在shard的处理slot范围内，shard会返回给client一个MOVED命令，告诉client这个slot由哪个shard负责，client动态更新更新配置。

2、数据迁移

集群扩缩容时，都需要对数据进行迁移，redis集群的数据迁移是以slot为单位的，每次原子地迁移一个key，直到整个slot全部迁移完成。

1）redis-trib通知目标节点准备接收属于slot的key。

2）redis-trib通知源节点准备迁移slot到目标节点。

3）redis-trib向源节点查询n个key。

4）redis-trib通知源节点迁移刚才查询到的key。

5）迁移完成，redis-trib通知任意一个节点将slot指派给目标节点，这个信息会很快传播到整个集群。

slot迁移过程中，源节点会收到属于这个slot的命令，redis是通过ASK命令处理的。命令先发送到源节点，如果key在源节点中，则源节点处理这个命令，如果源节点中没有找到这个key，源节点会回复client一个ASK命令，告诉client去目标节点尝试一下。

3、故障处理

如果是主节点故障，则会影响缓存服务，通常的故障处理包括故障检测，选主，故障转移，考虑到副本集数量减少，一般还会补充副本数量，从节点一般不对外提供读写服务，只做备份，如果检测到从节点故障只需要补充副本集。

故障检测

1）集群中的每个节点都会定期向其它节点发送PING消息，如果规定时间没有收到对方响应的PONG消息，则标记对方疑似下线（PFAIL）。

2）集群中的节点还会定期交换节点的状态，如果收到其它节点疑似下线的消息，节点也会记录一个下线报告。

3）如果在一个master节点的记录中，超过半数的master节点将某个master节点报告为疑似下线，那么就将这个master节点状态置为已下线状态（FAIL），并且广播这条消息，所有收到这条消息的节点也会将故障节点标识为已下线。

redis的故障检测是由所有master节点投票产生的，故障结果以广播的形式通知所有节点。

选主

1）slave节点发现它的master节点故障了，则会广播一条升主请求消息，并将自己的配置纪元加一。

2）所有master节点都必须在一个配置纪元中投一次票，如果master节点在这个配置纪元中没有投票，则会投给这个slave一票。

3）如果在这个配置纪元中slave收到的票数超过master总数的一半，则这个slave节点就会成为新的master节点。

4）如果这个配置纪元没有投票成功，则会进行下一轮跳票。

5）如果多个slave节点同时投票，那么很可能出现大家都得不到多于半数的支持，为了降低这种情况，每个slave都会在收到它的master下线的通知后的随机时间发起投票请求。

故障转移

1）获得多数投票的slave节点执行slaveof no one命令，成为master节点。

2）新的master节点接管故障master节点的slot。

3）新的master节点广播一条消息，通知其它节点它成为master节点。

4）新的master节点开始处理相关slot的命令。