面试，关于redis cluster的那些事

前言

最近面试，redis cluster 只要简历中有写，那基本都被问。有一些问的比较常规（八股文），而有一些面试官还是问得比较偏（为什么说偏呢？因为我只会搬砖）

常规问题

• 为什么要用redis cluster，而不是主从或者哨兵呢？

变相问你redis cluster有哪些优点，解决了哪些主从或者哨兵解决不了的问题，针对这个问题吧，我认为这样：

1）数据分片，能充分利用机器内存；

2）高性能以及支持在线扩容，无代理，异步复制，可扩容至1000个节点；

3）高可用，大多数master节点可用或者挂有至少一个从节点的master节点不可用的场景下，集群状态依然可用的；

4）从节点作为备份以及故障转移，如果master节点不可用，其下的从节点通过发起选举成为master节点，其实这就是高可用的体现。

官方这么说的：

image.png

• 那使用redis cluster 会存在一些什么问题？

我认为任何一门技术，都不存在绝对的利，根据场景以及业务去权衡，合适的就是好的

1）由于数据分片，一些热点key可能会造成数据访问倾斜问题。这个可通过给key加前后缀解决

2）redis cluster的副本数据是通过异步复制（默认），并非强一致性，故障转移期间有可能会丢失小部分客户端的写操作。虽然redis cluster也支持同步复制，但最终也都有可能丢失数据，且性能会下降（别忘了，我们是拿redis来提高性能的）

官方这么说的：

image.png

多说一句，其实你可关联想想mysql主从复制（异步、半同步、同步）、kafka ACK策略、rocketmq刷盘以及主从复制等等

• 如何知道一个key存在哪个实例上呢？

考察的分片原理，HASH_SLOT = CRC16(key) mod 16384。每个redis实例都维护着槽位与对应服务实例的映射关系，只要算出槽位，就能很快定位到对应的redis服务实例。

• redis cluster 在线扩容期间，如果客户端继续访问，会发生哪些问题？

1）如果槽位数据已迁移完成，旧节点会返回一个MOVDE重定向，客户端会再次发送指令给到新节点，这个可认为是永久性的（槽位与服务实例映射发生更新）。

2）如果部分数据还未迁移，对与旧节点存在的KEY会正常处理，否则，返回ASK重定向到其他节点。临时性，即下一次客户端还可继续访问该旧节点（槽位与服务实例映射未更新）。

官方这么说：

image.png

其他问题

• redis cluster 集群中一个master节点挂掉之后，选举流程是怎么样？

redis cluster采用类似Raft算法中的一个术语，就是currentEpoch，主要用于给事件增加版本。通常选举流程如下：

1）master节点被标识为fail状态；

2）slave节点将currentEpoch +1，并请求master节点进行投票。这个投票是由slave节点向集群中的每个master节点发送FAILOVER_AUTH_REQUEST包请求，然后等待master节点的响应，最大等待时间为NODE_TIMEOUT的两倍；

3）master节点响应FAILOVER_AUTH_ACK回复，即表示投票给该slave节点。NODE_TIMEOUT*2的是时间内，一个master节点不能再投给同一master节点下的其他slave节点，避免多个slave节点同时发起且同时选中；

4）slave节点丢弃所有小于请求投票时currentEpoch的AUTH_ACK回复，确保统计的是当前的选票；

5）一旦slave节点收到大多数master的ack响应，它将赢得选举，如果在NODE_TIMEOUT*2内没有达到大多数选票，则中止选举，并且在NODE_TIMEOUT*4时间后再次发起选举；

6）赢得选举的slave节点向集群其他节点发送ping和pong包以告知自己是master了

官方这么说：

image.png

• 这时，接着问，一个master节点挂了之后，其下的所有slave节点马上发起选举请求？

如果没了解过，我相信大部份都回答，yes。其实，这里有个副本等级和延迟公式

DELAY = 500 milliseconds + random delay between 0 and 500 milliseconds +
REPLICA_RANK * 1000 milliseconds.

主要目的是：

1）确保fail状态在集群中传播开，否则在主节点还不知道fail状态时，slave可能试图发起选举投票而被拒绝；

2）确保从master节点复制数据量最多的slave节点优先发起投票请求（合情合理），副本等级越小意味着复制数量越多，redis cluster后台维护着副本等级。

官方这么说：

image.png

• 如果集群中有3主3从，其中一个主节点挂掉了，集群还能正常服务？

这个需要自己去搭建个环境试下，一般有以下场景：

1）只要一个master节点下挂有至少一个从节点，无论master还是从节点其中一台挂了，都没影响，集群状态是ok（除非master和其下的从节点都挂掉）；

2）如果master节点下面，没有从节点，其挂掉后集群进入fail；

3）如果集群超过半数以上master挂掉（注意下，指slave赢得选举前，其他master也挂掉），无论是否有slave，集群进入fail状态

测试1：一个从节点挂掉，集群可用

image.png

测试2: 一个主节点挂掉，集群可用

image.png

停掉6383，选举后：

image.png

测试3：主从节点都挂掉，集群不可用

image.png

测试4：过半master节点挂后（注意下，指发生故障的master节点下的slave赢得选举前，其他master也挂掉），集群不可用

image.png

官方这么说：

image.png

• redis cluster 集群中，如果使用LUA脚本操作多个key，如何确保都落在一个服务实例上？

刚开始我也很懵，key不是通过CRC16哈希算法取模才知道落在哪个服务实例吗？（想到其他地方去了）

其实，redis cluster 有个散列标记特性，即使用花括号{}。也就是只取花括号之内的进行计算，只要花括号中的内容一样，最终计算结果一致的

官方这么说：

image.png

最后

以上就是最近遇到的一些问题，回来翻阅了下资料，记录了相关问题及自己的理解。其实redis cluster 还有很多高级的用法，如集群进入fail状态，依旧可通过配置来提供可用性（仅可读），有兴趣的可去看下官方介绍。最后，由于本人能力有限，如有不对的地方，请各位大佬修正哈