- 为什么需要Redis Cluster? 解决了什么问题？有什么优势？
- 主要问题是缓存的数据量太大，还有并发量要求太大，普通模式下的Redis和主从模式下的redis无法横向扩展来缓解压力。
- 使用集群模式可以使缓存的数据库相对均匀的分布在这些Redis实例上，客户端的请求可以通过路由规则转发到目标master上。
- 优势就是横向扩展非常友好，只需要增加redis节点到集群中即可，可以动态扩容和缩容。
- 具备主从复制，故障转移（无需单独部署Sentinel）等功能。
-
Redis Cluster是如何分片的？如何确定给定key的应该分布到哪个哈希槽？
Redis Cluster采用的是哈希槽分区，每个键值对都属于一个一个hash slot。哈希槽一共有16384个，要计算给定的key应该分布到哪个哈希槽，需要对key计算CRC-16校验码，然后用这个校验码跟16384取模，得到的值就是key对应的哈希槽。
-
为什么Redis Cluster的哈希槽是16384个？
- 哈希槽太大会导致心跳包太大，消耗太多带宽。
- 哈希槽总数越少，对存储哈希槽信息的bitmap压缩效果越好。
- Redis Cluster主节点一般不会太大，16384足够。
- Redis Cluster支持重新分配哈希槽么？
支持，可以手动增加槽或者删除修改槽，例如：cluster addslots 1 2 3 4 5. 或者新加节点会自动重新分配。
- Redis Cluster扩容缩容期间可以提供服务吗？
缩容扩容本质就是重新分片，动态迁移哈希槽。 为了保证Redis Cluster在扩容和缩容期间依然能够对外正常提供服务，Redis Cluster 提供了重定向机制，两种不同的类型：
-
ASK重定向 -
MOVED重定向
从客户端的角度来看，ASK重定向如下：
- 客户端发送请求，如果请求的key还在对应的哈希槽，则响应。
- 如果当前key对应的哈希槽正在迁移新节点，返回-ASK重定向错误，告知客户端要将请求发送到哈希槽被迁移的目标节点。
- 客户端收到-ASK重定向错误，会将临时一次性的重定向，自动向新的目标节点发送一次ASKING命令，接收到ASKING命令的节点会强制执行一次请求，下次再来需要重新提前发送ASKING命令。
- 客户端发送真正的请求命令。
如果客户端请求的key对应的哈希槽已经迁移完成的话，就会返回-MOVED重定向错误，告知客户端当前哈希槽是由哪个节点负责，客户端向目标节点发送请求并更新缓存的哈希槽分配信息。
-
Redis Cluster中的节点是怎么进行通信的？
基于GOSSIP协议进行通信。每个redis节点都有一份集群信息。 Gossip消息分三类：
- MEET:在某个redis节点发送cluster meet ip port 可以向指定的redis发送一条meet信息（方言说的话就是参加你们的会议啦）, 就能加入该集群。
- PING、PONG：检查对方是否下线，疑似下线，已下线。
- FAIL：节点A发现节点B下线，并且下线报告中有效期内集群半数以上的节点将B都标为PFAIL，节点A就会向集群广播一条FAIL信息，通知其他节点这个B凉了。
