Redis系列(十):Redis面试系列问题(集群篇)

mhr18 2024-11-18 14:30 23 浏览 0 评论

引言

Redis作为一个基于BDS许可的开源的内存数据结构存储，用于数据库，缓存和消息代理；并且已经越来越在构建高性能、可扩展、高可用的Web应用中发挥着举足轻重的作用。

Redis已然成为当今互联网技术架构中应用的最广泛的中间件之一，它也是作为中高级后端工程技术面试中必备的技术栈成员。我们不仅仅要对Redis的基本使用进行掌握，更要深层次地理解Redis内部实现的细节原理。

熟练掌握Redis，在面试心仪的公司打分中起着重要的作用。本文我们一起来盘点回顾Redis的面试经典问题。篇幅比较长，让我们共同成长进步???！

Redis面试集群篇

1. 谈一下你对主从同步的理解？

主从复制：将一台Redis服务器的数据，复制到其他Redis服务器上，前者称为主节点Master，后者称为从节点Slaver；并且数据的复制是单向的，只能从主节点到从节点。Redis主从复制支持主从同步和从从同步，后者是Redis后续版本新增的功能，以减少主节点的同步压力。

主从复制的作用：

① 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式；

② 负载均衡：写Redis数据时链接主节点，读Redis数据时链接从节点，分担服务器负载。尤其是在写少读多的场景下，通过多个从节点分担读负载，可以提高Redis服务器的并发量；

③ 故障恢复：当主节点出现问题，可以由从节点提供服务；

④ 高可用性：主从复制还是哨兵和集群能够实施的基础，因此说主从复制是 Redis 高可用的基础。

Redis主从复制原理：

上图可以简化为三个阶段：准备阶段 -- 数据同步阶段 -- 命令传播阶段。每个阶段具体进行的操作，参见往期文章《Redis系列（五）：主从复制》！

2. 哨兵模式了解吗？简单谈一谈？

上图展示了一个典型的哨兵模式架构图，由两部分组成：哨兵节点 & 数据节点。

哨兵节点：哨兵系统由一个或者多个哨兵节点组成，哨兵节点是特殊的Redis节点，不存储数据；
数据节点：存储数据的节点，主节点和从节点都是数据节点；

在Redis主从复制的基础上，哨兵实现了自动化的故障恢复功能，官方对于哨兵功能的描述：

监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常；
自动故障转移（Automatic Failover）：当主节点不能正常工作时，哨兵会开始自动故障转移工作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点；
配置提供者（Configuration Provider）：客户端在初始化时，通过连接哨兵来获取当前Redis服务的主节点地址；
通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

上述功能中：监控和自动故障转移使得哨兵可以及时发现主节点故障并完成转移；配置和通知则需要与客户端进行交互。

3. 哨兵模式中，主节点出现故障，新的主节点是怎样被选择出来的呢？

故障转移操作的第一步要做的就是在已经下线的主服务器下的所有从服务器中，挑选出一个状态良好、数据完整的从服务器，然后向这个从服务器发送slaveof no one命令，将这个从服务器转换为主服务器。但是这个从服务器是怎么样被挑选出来的呢？

简单说一下Sentinel哨兵选择新主服务器的规则：

在失效主服务器下的从服务器中，那些被标记为主观下线、已断线、最后一次回复PING命令的时间大于5秒钟的从服务器都会被淘汰；
在失效主服务器下的从服务器中，那些和失效主服务器连接断开时长超过down-after指定时长10倍的从服务器都会被淘汰；
在经历了以上两轮淘汰之后剩余的从服务器中，选出复制偏移量（replication offset）最大的那个从服务器作为新的主服务器；如果复制偏移量不够，或者从服务器的复制偏移量相同，那么带有最小运行ID的那个从服务器成为新的主服务器。

4. Redis集群使用过吗，原理了解吗？

集群，即Redis Cluster，是Redis3.0开始引入的分布式存储方案。集群是由多个节点（Node）组成，Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点；只有主节点负责读写请求和集群信息的维护，从节点只进行主节点数据和状态信息的复制。

Redis集群的原理：

Redis集群中内置了16384个哈希槽。当客户端连接到Redis集群之后，会同时得到一份关于这个集群的配置信息，当客户端具体对某一个key值进行操作时，会计算出它的一个Hash值，然后把结果对16384求余数，这样每个key都会对应一个编号在0~16383之间的哈希槽，Redis会根据节点数量大致均等的将哈希槽映射到不同的节点。

Redis集群详细原理和使用场景内容参见往期文章：《Redis系列（六）：Reids集群模式》！

5. Redis集群中数据是如何分区的呢？

数据分区有顺序分区、哈希分区等，其中哈希分区由于其天然的随机性，使用比较广泛。集群的分区方案便是哈希分区的一种。我们知道衡量数据分区方法好坏的标准最主要的是：① 数据分布是否均匀；② 增减节点对数据分布的影响。

（1）方案一：哈希值 % 节点数

最容易想到的方案：哈希取余分区，计算key的hash值，然后对节点数量进行取余运算，从而决定数据映射到那个节点上。弊端：当新增或者删减节点时，节点数量发生变化，系统中所有的数据都需要重新计算映射关系，引发大规模的数据迁移。

（2）方案二：一致哈希算法分区

一致性哈希算法将整个哈希值空间组织成一个虚拟的圆环，范围是[0 - 2^32-1]，对于每一个数据，根据key计算hash值，确定数据在环上的位置，然后从此位置沿顺时针，找到第一台Redis服务器就是其映射到的服务器。与哈希取余分区相比，一致性哈希分区将增减节点的影响限制在相邻的节点。

弊端：当节点数量较少时，增加或删减节点，对单个节点的影响可能很大，造成数据的严重不平衡。

（3）方案三：带有虚拟节点的一致性哈希分区

该方案是在一致性哈希分区基础上，引入虚拟节点的概念。Redis集群使用的便是这个方案，其中虚拟节点称为槽（slot）。槽是介于数据和实际节点之间的虚拟概念，每个实际节点包含一定数量的槽，每个槽包含哈希值在一定范围内的数据。数据的映射关系由数据hash到实际节点变成了数据hash到槽再到实际节点。

在使用了槽的一致性哈希分区中，槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点之间的关系，增加和删减节点对系统的影响很小。在Redis集群，槽的数量是16384个。

6. Redis集群数据是如何存储的有了解吗？

节点需要专门的数据结构来存储集群的状态。这里所谓的状态：是一个比较大的概念，包括：集群是否处于上线状态、集群中有哪些节点、节点是否可达、节点的主从状态、槽分布等等。

节点为了存储集群状态提供了专门的数据结构，最关键的是 clusterNode 和 clusterState 结构：前者记录了一个节点的状态，后者记录了集群作为一个整体的状态。

clusterNode结构保存了一个节点的当前状态，包括创建时间、节点id、ip和端口号等。每个节点都会用一个clusterNode结构记录自己的状态，并为集群内所有其他节点都创建一个clusterNode结构来记录节点状态。

typedef struct clusterNode {
    // 节点创建时间 
    mstime_t ctime; 
    // 节点id 
    char name[REDIS_CLUSTER_NAMELEN];
    // 节点的ip和端口号 
    char ip[REDIS_IP_STR_LEN]; 
    int port; 
    // 节点标识：整型，每个bit都代表了不同状态，如节点的主从状态、是否在线、是否在握手等 
    int flags; 
    // 配置纪元：故障转移时起作用，类似于哨兵的配置纪元 
    uint64_t configEpoch; 
    /*
     * 槽在该节点中的分布：占用16384/8个字节，16384个比特；
     * 每个比特对应一个槽：比特值为1，则该比特对应的槽在节点中；
     * 比特值为0，则该比特对应的槽不在节点中
     */
    unsigned char slots[16384/8]; 
    //节点中槽的数量 
    int numslots;
    …
}clusterNode;

clusterState结构保存了在当前节点视角下，集群所处的状态。主要字段包括：

typedef struct clusterState { 
    // 自身节点 
    clusterNode *myself; 
    // 配置纪元 
    uint64_t currentEpoch; 
    // 集群状态：在线还是下线 
    int state; 
    // 集群中至少包含一个槽的节点数量 
    int size; 
    //哈希表，节点名称 -> clusterNode节点指针 
    dict *nodes; 
    //槽分布信息：数组的每个元素都是一个指向clusterNode结构的指针；如果槽还没有分配给任何节点，则为NULL 
    clusterNode *slots[16384]; 
  … } clusterState;