09｜Redis 集群

Redis面试题库 - 这篇文章属于一个选集。

§ 9: 本文

1. Redis 集群架构模式有哪几种？
#

分析

Redis 提供了三种集群模式：主从架构、哨兵集群、切片集群。

主从复制

主从复制是 Redis 高可用服务的最基础的保证，实现方案就是将从前的一台 Redis 服务器，同步数据到多台从 Redis 服务器上，即一主多从的模式，且主从服务器之间采用的是「读写分离」的方式。

主服务器可以进行读写操作，当发生写操作时自动将写操作同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令，然后执行这条命令。

也就是说，所有的数据修改只在主服务器上进行，然后将最新的数据同步给从服务器，这样就使得主从服务器的数据是一致的。

注意，主从服务器之间的命令复制是异步进行的。

具体来说，在主从服务器命令传播阶段，主服务器收到新的写命令后，会发送给从服务器。但是，主服务器并不会等到从服务器实际执行完命令后，再把结果返回给客户端，而是主服务器自己在本地执行完命令后，就会向客户端返回结果了。如果从服务器还没有执行主服务器同步过来的命令，主从服务器间的数据就不一致了。

所以，无法实现强一致性保证（主从数据时时刻刻保持一致），数据不一致是难以避免的。

哨兵集群

在使用 Redis 主从服务的时候，会有一个问题，就是当 Redis 的主从服务器出现故障宕机时，需要手动进行恢复。

为了解决这个问题，Redis 增加了哨兵模式（Redis Sentinel），因为哨兵模式做到了可以监控主从服务器，并且提供主从节点故障转移的功能。

切片集群

当 Redis 缓存数据量大到一台服务器无法缓存时，就需要使用 Redis 切片集群（Redis Cluster）方案，它将数据分布在不同的服务器上，以此来降低系统对单主节点的依赖，从而提高 Redis 服务的读写性能。

Redis Cluster 方案采用哈希槽（Hash Slot），来处理数据和节点之间的映射关系。在 Redis Cluster 方案中，一个切片集群共有 16384 个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中，具体执行过程分为两大步：

根据键值对的 key，按照 CRC16 算法计算一个 16 bit 的值；
再用 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽。

接下来的问题就是，这些哈希槽怎么被映射到具体的 Redis 节点上的呢？有两种方案：

平均分配：在使用 cluster create 命令创建 Redis 集群时，Redis 会自动把所有哈希槽平均分布到集群节点上。比如集群中有 9 个节点，则每个节点上槽的个数为 16384/9 个；
手动分配：可以使用 cluster meet 命令手动建立节点间的连接，组成集群，再使用 cluster addslots 命令，指定每个节点上的哈希槽个数。

为了方便你的理解，我通过一张图来解释数据、哈希槽，以及节点三者的映射分布关系。

上图中的切片集群一共有 2 个节点，假设有 4 个哈希槽（Slot 0~Slot 3）时，我们就可以通过命令手动分配哈希槽，比如节点 1 保存哈希槽 0 和 1，节点 2 保存哈希槽 2 和 3。

redis-cli -h 192.168.1.10 -p 6379 cluster addslots 0,1
redis-cli -h 192.168.1.11 -p 6379 cluster addslots 2,3

然后在集群运行的过程中，key1 和 key2 计算完 CRC16 值后，对哈希槽总个数 4 进行取模，再根据各自的模数结果，就可以被映射到哈希槽 1（对应节点 1）和哈希槽 2（对应节点 2）。

需要注意的是，在手动分配哈希槽时，需要把 16384 个槽都分配完，否则 Redis 集群无法正常工作。

回答

Redis 提供了三种集群模式：主从架构、哨兵集群、切片集群。

主从：选择一台作为主服务器，将数据同步多台从服务器上，构建一主多从的模式，主从之间读写分离。主服务器可读可写，发生写操作会同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令。主从服务器之间的命令复制是异步进行的，所以无法实现强一致性保证（主从数据时时刻刻保持一致）；
哨兵：当 Redis 的主从服务器出现故障宕机时，需要手动进行恢复，为了解决这个问题，Redis 增加了哨兵模式，哨兵监控主从服务器，并且提供主从节点故障转移的功能；
切片集群：当数据量大到一台服务器无法承载，需要使用 Redis 切片集群（Redis Cluster）方案，它将数据分布在不同的服务器上，以此来降低系统对单主节点的依赖，提高 Redis 服务的读写性能。

2. Redis 主从复制过程是怎样的？
#

分析

Redis 集群支持的主从复制，数据同步主要有两种方法：一种是全量同步，一种是增量同步。

1. 全量同步

刚开始搭建主从模式时，从机需要从主机上获取所有数据，这时就需要 Slave 将 Master 上所有的数据进行同步复制。复制的步骤为：

从服务器发送 SYNC 命令，链接主服务器；
主服务器收到 SYNC 命令后，进行存盘的操作，并继续收集后续的写命令，存储缓冲区；
存盘结束后，将对应的数据文件发送到 Slave 中，完成一次全量同步；
主服务数据发送完毕后，将进行增量的缓冲区数据同步；
Slave 加载数据文件和缓冲区数据，开始接受命令请求，提供操作。

2. 增量同步

从节点完成了全量同步后，就可以正式的开启增量备份。当 Master 节点有写操作时，都会自动同步到 Slave 节点上。Master 节点每执行一个命令，都会同步向 Slave 服务器发送相同的写命令，当从服务器接收到命令，会同步执行。

回答

当从节点初次连接到主节点，或者掉线重连后进度落后较多时会进行一次全量数据同步。此时，主节点会生成 RDB 快照并传输给从节点，在此期间，主节点接受到的增量命令将会先写入 replication_buffer 缓冲区，等到从节点加载完 RDB 快照的数据后，再将缓冲区的命令传输给从节点，以此完成初次同步。

当从节点掉线重连后，如果进度落后的不多，将会进行增量同步。主节点内部维护了一个环形的固定大小的 repl_backlog_buffer 缓冲区，它用于记录最近传播的命令。其中，主节点和从节点会分别在该缓冲区维护一个 offset，用于表示自己的写进度和读进度。当从节点掉线重连后，将会检查主节点和从节点 offset 之差是否小于缓冲区大小，如果确实小于，说明从节点同步进度落后不多，则主节点将该缓冲区中的两 offset 之间的增量命令发送给从节点，完成增量同步。

当主从节点完成初次同步后，将会建立长连接进行命令传播。简单的来说，就是每当主节点执行一条命令，它就会写入 replication_buffer 缓冲区，随后再将缓冲区的命令通过节点间的长连接发送给对应的从节点。

3. Redis 的主从复制模式有什么优缺点？
#

分析

对于讲 Redis 主从复制模式优缺点，需要讲出 Redis 主从复制优缺点是什么，和其他方案的对比。

一、优点：

读写分离：主节点处理写请求，从节点分担读请求，提升系统吞吐量（适合读多写少场景）；
数据冗余：从节点实时备份主节点数据，降低数据丢失风险；
高可用基础：主节点故障时，从节点可快速切换为主（需配合哨兵或手动操作）；
扩展性：通过增加从节点横向扩展读能力，成本较低。

二、缺点：

数据不一致：异步复制存在延迟，可能读到旧数据（金融等强一致场景需额外方案）；
写瓶颈：所有写操作集中在主节点，高并发写入时易成为性能瓶颈；
运维复杂度：故障转移需人工干预或依赖哨兵，大规模集群管理成本高；
资源开销：每个从节点需完整数据副本，内存/存储成本随节点数线性增长。

三、与其他方案对比：

vs 哨兵模式：哨兵提供自动故障转移，主从需手动或依赖哨兵实现高可用；
vs 集群模式：集群通过分片支持海量数据和高并发写，主从仅扩展读能力，写仍受限于主节点。

回答

Redis 主从复制通过数据冗余和读写分离提高了可用性和读性能，但存在数据一致性延迟、写操作无法扩展、故障转移复杂等缺点；相比哨兵模式缺乏自动故障转移能力，相比集群模式无法水平扩展写能力，适合读多写少且对一致性要求不高的场景。

4. 哨兵机制是什么？
#

分析

Redis 哨兵（Sentinel）机制是一种高可用解决方案，用于监控主从节点、自动检测故障并执行主节点切换（failover），确保 Redis 服务持续可用。

核心功能

监控：持续检查主节点和从节点是否正常运行；
自动故障转移（Failover）：主节点宕机时，哨兵会选举新主节点并让其他从节点复制它；
配置管理：客户端可通过哨兵获取最新的主节点地址，避免手动修改配置；
通知：可集成告警系统（如邮件、API）通知管理员故障情况。

对比主从复制

主从复制：仅数据备份，无自动故障恢复能力；
哨兵模式：在主从复制基础上，增加自动故障检测和主节点切换，提升高可用性。

适用于需要自动容灾但无需数据分片（写扩展）的场景。

说明为什么需要哨兵，哨兵起到什么样的作用即可。

回答

因为在主从架构中读写是分离的，如果主节点挂了，将没有主节点来响应客户端的写操作请求，也无法进行数据同步。

哨兵作用是实现主从节点故障转移。哨兵会监测主节点是否存活，如果发现主节点挂了，会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。

5. 哨兵机制的工作原理？
#

分析

讲明哨兵机制故障转移的原理即可，哨兵工作原理主要是以下步骤：

1. 判断节点是否存活

哨兵会周期性给所有主节点发送 PING 命令来判断其他节点是否正常运行。如果 PING 命令响应失败哨兵会将节点标记为主观下线，然后该哨兵会向其他节点发出投票命令，当票数达到设定的阈值之后这个主节点就被标记为客观下线。然后哨兵会从从节点中选择一个作为主节点。

2. 投票

哨兵集群中会选择一 leader 来负责主从切换，选举是一个投票过程：判断主节点为客观下线的是候选者，候选者向其他哨兵发送命令表示要成为 leader，其他哨兵会进行投票，每个哨兵只有一票，可以投给自己或投给别人，但是只有候选者才能把票投给自己。候选者之后拿到半数以上的赞成票并且票数大于设置的阈值，就会成为 leader。

3. 选出新主节点

把网络状态不好的从节点给排除：先把已经下线的从节点过滤掉，然后把以往网络连接状态不好的从节点排除掉。接下来要对所有从节点进行三轮考察：优先级、复制进度、ID 号。在进行每一轮考察的时候，哪个从节点优先胜出，就选择其作为新主节点：

第一轮考察：哨兵首先会根据从节点的优先级来进行排序，优先级的值越小排名越靠前；
第二轮考察：如果优先级相同，则查看复制的下标，哪个接收的复制数据多哪个就靠前；
第三轮考察：如果优先级和下标都相同，选择 ID 较小的那个。

4. 更换主节点

选出新主节点之后，哨兵 leader 让已下线主节点属下的所有从节点指向新主节点。

5. 通知客户的主节点已更换

客户端和哨兵建立连接后，客户端会订阅哨兵提供的频道。主从切换完成后，哨兵就会向 +switch-master 频道发布新主节点的 IP 地址和端口的消息，这个时候客户端就可以收到这条信息，然后用这里面的新主节点的 IP 地址和端口进行通信了。

6. 将旧主节点变为从节点

继续监视旧主节点，当旧主节点重新上线时，哨兵集群就会向它发送 SLAVEOF 命令，让它成为新主节点的从节点。

回答

哨兵机制通过周期性 PING 检测节点存活，若主节点主观下线则发起投票，达到阈值后标记为客观下线并选举哨兵 Leader；Leader 基于优先级、复制进度和 ID 从从节点中选出新主节点，切换从节点指向新主并通知客户端，旧主恢复后降级为从节点，实现自动故障转移和高可用。

6. Redis sentinel（哨兵）模式优缺点有哪些？
#

分析

对于讲 Redis sentinel（哨兵）模式优缺点，需要讲出 Redis sentinel（哨兵）优缺点是什么，为什么要这么设计（对比 redis 的其他两种高可用方案）。

回答

优点：

哨兵模式基于主从复制模式，所以主从复制模式有的优点，哨兵模式也有；
哨兵模式下，master 挂掉可以自动进行切换，系统可用性更高。

缺点：

Redis 的容量受限于单机配置；
以及主从切换过程可能会出现丢失数据的问题。

7. 说说 Redis 哈希槽的概念？
#

分析

对于讲 Redis 哈希槽概念，需要讲出 Redis 哈希槽是什么，哈希槽的工作原理，以及为什么要这么设计。

1. 核心概念

Redis 哈希槽（Hash Slot）是 Redis Cluster 实现数据分片的核心机制，本质上是将整个 Key 空间划分为 16384 个固定逻辑单元（槽）。

数据分片规则：每个 Key 通过 CRC16(key) % 16384 计算哈希槽编号，决定存储在哪个槽中；
槽分配：集群中的每个节点负责管理一部分哈希槽（例如 Node1 管理 0-5000 号槽，Node2 管理 5001-10000 号槽等）；
去中心化路由：客户端可直接计算 Key 对应的槽编号，无需依赖中心化的元数据服务。

2. 工作原理

客户端请求：客户端计算 key 的哈希槽，若连接节点不负责该槽，返回 MOVED 重定向响应，引导客户端访问正确节点；
节点间通信：节点通过 Gossip 协议交换槽分配信息，维护全局路由表；
槽迁移：管理员可手动将槽从一个节点迁移到另一个节点，迁移过程中新旧节点同时服务该槽的请求，确保平滑过渡。

3. 关键设计细节

为什么是 16384 个槽？
Redis 作者 Antirez 解释：
- 网络开销：节点间需同步槽分配信息，16384 个槽仅需 2KB 内存（每个槽用 2 字节表示），若使用 65536 槽则需 8KB，在心跳包中占比过大；
- 实际规模：16384 槽足够支持上千节点，远超实际需求；
- 对比一致性哈希优势：

维度	哈希槽	一致性哈希
数据迁移粒度	槽级别（细粒度）	节点级别（粗粒度）
扩容影响	仅迁移部分槽，影响可控	需重新分配大量数据
路由复杂度	客户端直接计算，无中心依赖	依赖外部服务或虚拟节点映射
管理灵活性	支持槽批量迁移、权重分配	依赖哈希环自然分布

回答

Redis 哈希槽是 Redis Cluster 数据分片的核心机制，整个集群有 16384 个固定槽位，每个键通过 CRC16 算法计算后取模 16384 分配到特定槽位。集群将槽位均匀分布在不同的节点，节点只负责自己持有的槽位数据。客户端访问时直接路由到目标节点，若请求的槽位不属于当前节点，则返回 MOVED 重定向响应。哈希槽支持动态迁移，可通过重新分配槽位实现集群扩容缩容，迁移过程中采用 ASK 临时重定向保证可用性。这种设计实现了数据均匀分布、高效路由和弹性扩展，相比一致性哈希减少数据迁移量，是 Redis Cluster 高可用和水平扩展的基础架构。

8. 哈希槽和 Redis 节点是如何对应的？
#

分析

在创建集群的时候，我们可以为 cluster 中每个节点，划分职责，也就是给他们分配负责的数据区间，这里 Redis 使用的是一个叫 Hash 槽的概念，即将数据分为了多个槽，每个节点负责一些槽。

redis-cli -p 7000 cluster addslots {0..5461}
redis-cli -p 7001 cluster addslots {5462..10922}
redis-cli -p 7002 cluster addslots {10923..16383}

如果想自动平均分配，也可以使用 CLUSTER REBALANCE 命令。

回答

主要有自动分配和手动分配两种方式。自动分配是集群创建或者节点添加减少时，Redis 自动将哈希槽平均分配到集群节点上；手动分配是使用命令指定每个节点上面的哈希槽数目，使用手动分配时要把 16384 个槽位给分完，否则集群不会正常工作。

9. 主从模式的同步过程？
#

分析

Redis 主从复制流程主要分为以下三个核心步骤：

1. 连接协商阶段

从服务器向主服务器发送 PSYNC 命令，携带主服务器的 runID 和复制偏移量（offset）参数；
主服务器响应从服务器，返回自身的 runID 和当前复制偏移量；
从服务器接收并持久化存储这两个关键参数，为后续数据同步建立基础。

2. 数据全量同步阶段

主服务器执行 BGSAVE 生成 RDB 快照文件；
从服务器接收 RDB 文件后，会先清空现有数据集，再加载 RDB 文件完成全量数据同步，为确保数据一致性，主服务器在此期间将新写入操作暂存至复制缓冲区（replication buffer）。

3. 增量同步阶段

主服务器将复制缓冲区中的写操作按顺序发送至从服务器；
从服务器依次执行接收到的写命令，完成最终数据同步；
至此，首次主从数据同步完整流程执行完毕，进入增量数据同步阶段，也就是 Redis 主节点利用缓冲区将写入操作持续同步给 Redis 从节点。

回答

主要分为建立连接协商、主从数据同步、发送新操作三个步骤，连接协商主要确定复制偏移量等关键数据，为同步建立基础；首次主从同步数据是通过 RDB 文件传递来同步，期间的命令是利用复制缓冲区同步，完成首次同步之后，后续写入操作持续同步给 Redis 从节点，保证增量数据也是同步的。

10. 从服务重新上线之后，主服务器如何知道要将哪些增量数据发送给从服务器？
#

分析

这里主要要点明如何决策是增量同步还是全量同步，这个决策取决于读的数据是不是在 repl_backlog_buffer 中。

什么是 repl_backlog_buffer？

repl_backlog_buffer 是一个环形缓冲区，用于主从服务器断连后，从中找到差异的数据；replication offset 标记缓冲区的同步进度。

回答

网络断开从服务器重新上线之后，会发送自己的复制偏移量到主服务器，主服务器根据偏移量之间的差距判断要执行的操作：如果从服务器要读的数据在 repl_backlog_buffer 中，则采用增量复制；如果不在，采用全量复制。

11. Redis 如何减少主从数据的不一致？
#

分析

Redis 从节点会向主节点同步数据，但是同步总有延迟，有延迟就有一段时间的不一致，回答要点是如何减少不一致时间，或者对外屏蔽不一致的从节点数据。

回答

为了优化 Redis 主从节点不一致的问题，可以采取以下措施：

同机房部署：将主从节点部署在同一机房，以降低网络延迟，减少数据同步的时间差；
外部监控程序：通过外部程序实时监控主从节点的复制进度。计算主从节点之间的复制进度差，如果复制进度差超过预设阈值，客户端将不再从该从节点读取数据，从而减少数据不一致对业务的影响，进度差阈值设置不宜太小，确保在主从同步延迟较高时，客户端仍能正常访问部分从节点。

12. 主从模式是同步复制还是异步复制？
#

分析

搞清楚同步复制和异步复制的区别，就不难判断，Redis 是异步复制。

同步复制（Synchronous Replication）

定义：主服务器在执行写操作时，必须等待所有从服务器成功写入数据并返回确认后，才向客户端返回成功响应；
特点：
- 强一致性：主从数据完全一致，确保数据的可靠性；
- 高延迟：由于需要等待从服务器的响应，写操作的延迟较高；
- 可靠性高：即使主服务器宕机，从服务器也能提供完整的数据；
- 性能开销大：网络延迟或从服务器性能不足会拖慢整体性能；
适用场景：
- 对数据一致性要求极高的场景，如金融交易、支付系统；
- 允许较高延迟但对数据可靠性要求严格的场景。

异步复制（Asynchronous Replication）

定义：主服务器执行写操作后，立即向客户端返回成功响应，而不等待从服务器的写入确认。数据复制在后台异步进行；
特点：
- 弱一致性：主从数据可能存在短暂的不一致（复制延迟）；
- 低延迟：主服务器无需等待从服务器，写操作响应速度快；
- 性能高：适合高并发、低延迟的场景；
- 可靠性较低：如果主服务器在数据复制完成前宕机，可能导致数据丢失；
适用场景：
- 对性能要求高、允许短暂数据不一致的场景，如社交网络、日志系统；
- 数据丢失风险可接受的场景。

回答

异步复制。因为主节点收到写命令之后，先写到内部的缓冲区，然后再异步发送给从节点。这样做的好处是对主流程影响小，不干扰 Redis 的高性能。

13. 如何保证 Redis 的高可用性？
#

分析

Redis 的高可用性指的是在节点故障时快速恢复服务，核心方案有三种（主从复制，集群模式），可根据业务规模选择。

回答

在面试中，可以按以下结构清晰回答：

1. 主从复制

Redis 支持主从复制机制，其中一个 Redis 实例（主节点）负责写操作，而其他实例（从节点）复制主节点的数据。如果主节点发生故障，结合哨兵，可以让从节点顶替成为主节点，提供读写功能，从而实现故障转移和高可用性。

2. 集群模式（大规模场景）

Redis Cluster 是一种分布式 Redis 解决方案，它可以将数据分片存储在多个节点上，并自动管理节点间的数据分布和故障转移。Redis Cluster 提供了高可用性和扩展性，允许在集群中添加或删除节点而不会影响整个系统的可用性。

3. 监控和告警

建立有效的监控和告警系统可以及时发现问题并采取行动。监控 Redis 的关键指标，如内存使用、连接数和响应时间，可以在问题发生时快速响应。

补充方案

持久化：开启 RDB 快照和 AOF 日志，宕机后可从磁盘恢复数据（不是高可用，是兜底）；
云服务：直接用阿里云、AWS 的托管 Redis 服务（多可用区部署）。

14. Redis cluster 注重 CAP 哪两者？为什么？
#

分析

Redis Cluster 作为分布式缓存系统，遵循 CAP 理论，但需要在三者中做出取舍。其核心设计目标是高性能、高可用性和水平扩展，因此在 AP（可用性+分区容错性）之间做了明确选择，牺牲了强一致性（C）。

具体来说，Redis Cluster 优先保证以下两者：

1. 分区容错性（P）

数据分片：数据被划分为 16384 个哈希槽，分布在多个节点上。即使发生网络分区（如部分节点失联），各分区仍能独立处理自己负责的槽位请求；
Gossip 协议：节点间通过 Gossip 协议自动发现和同步状态，确保网络分区后仍能维护集群元数据。

2. 可用性（A）

主从自动故障转移：主节点宕机时，从节点通过选举机制快速晋升为新主节点，客户端无感知；
异步复制：主节点写入成功后立即返回响应，数据异步复制到从节点，避免同步复制导致的延迟。

为什么牺牲一致性？

一致性（C）与可用性（A）的权衡：Redis Cluster 在默认情况下更倾向于可用性（A）。在数据复制过程中，Redis 采用了异步复制机制，这意味着主节点写入数据后，不会等待所有从节点确认就返回操作成功的结果。这样做提高了系统的响应速度和可用性，但在极端情况下（如主节点宕机且未完成数据同步）可能会导致数据丢失，即牺牲了强一致性（C）。

这种对一致性的权衡让 Redis Cluster 更符合 AP 系统的特点。

回答

Redis Cluster 在 CAP 中明确选择 AP（可用性+分区容错性），牺牲强一致性（C）。通过 16384 哈希槽分片和 Gossip 协议保障分区容错性（P），即使网络分区各节点仍能独立工作。采用主从自动故障转移和异步复制确保高可用性（A），写入快速响应但可能丢失未同步数据。这种设计优先保证高性能和扩展性，接受最终一致性，典型符合 AP 系统特征。

15. cluster 集群原理，客户端是怎样知道该访问哪个分片的
#

Redis Cluster 将数据按照键哈希分配到 16384 个哈希槽 slot 上，这个问题其实是问如何找到 Key 对应的哈希槽的。

回答

首先客户端会计算 key 所在的哈希槽是哪个（如果使用哈希 tag 的话，就只会对 {} 包裹的内容进行哈希）；
把请求发给一个 Redis 节点，节点会检查自己是否负责这个 slot；
若哈希槽不是由自身节点负责，就返回 MOVED 重定向；
若哈希槽确实由自身负责，且 key 在 slot 中，则返回该 key 对应结果；
若 Redis key 不存在此哈希槽中，检查该哈希槽是否正在迁出（MIGRATING）；
若 Redis key 正在迁出，返回 ASK 错误重定向客户端到迁移的目的服务器上；
若哈希槽未迁出，检查哈希槽是否导入中；
若哈希槽导入中且有 ASKING 标记，则直接操作，否则返回 MOVED 重定向；
大部分的客户端通常实现会缓存集群节点和槽的映射关系，并且在遇到 MOVED 错误的时候才进行缓存的更新。

16. 哨兵主节点是怎么选举出来的？如果主节点宕机了，客户端发来的请求怎么知道自己要请求的新的主节点是哪个端口？
#

分析

回答这个问题，需要清楚哨兵主观下线和客观下线判断的流程，以及哨兵向客户端广播新主节点信息的流程：

哨兵主节点的选举过程是：

主观下线判断：哨兵会每隔 1 秒给所有主从节点发送 PING 命令，当主从节点收到 PING 命令后，会发送一个响应命令给哨兵，以此判断它们是否在正常运行。如果主节点或者从节点没有在规定的时间内响应哨兵的 PING 命令（由 down-after-milliseconds 参数设定，单位是毫秒），哨兵就会将它们标记为「主观下线」；
客观下线判断：客观下线只适用于主节点。当一个哨兵判断主节点为「主观下线」后，就会向其他哨兵发起命令，其他哨兵收到这个命令后，会根据自身和主节点的网络状况，做出赞成投票或者拒绝投票的响应。当这个哨兵的赞同票数达到哨兵配置文件中的 quorum 配置项设定的值后，这时主节点就会被该哨兵标记为「客观下线」。例如，3 个哨兵，quorum 配置为 2，那么一个哨兵需要 2 张赞成票（包括自己的一张），就可以标记主节点为“客观下线”；
选举哨兵 leader：哪个哨兵节点判断主节点为「客观下线」，这个哨兵节点就是候选者。候选者会向其他哨兵发送命令，表明希望成为 Leader 来执行主从切换，并让所有其他哨兵对它进行投票。每个哨兵只有一次投票机会，可以投给自己或投给别人，但是只有候选者才能把票投给自己。在投票过程中，任何一个「候选者」，要满足两个条件：拿到半数以上的赞成票；拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。例如，3 个哨兵节点，quorum 设置为 2，想成为 Leader 的哨兵只要拿到 2 张赞成票，就可以选举成功。如果没有满足条件，就需要重新进行选举；
选择新主节点：选举出哨兵 leader 后，哨兵 leader 在已下线主节点属下的所有「从节点」中挑选新主节点。先过滤掉已经下线的从节点和以往网络连接状态不好的从节点（通过 down-after-milliseconds * 10 配置项判断，若在 down-after-milliseconds 毫秒内主从节点未联系上则认为断连，断连次数超过 10 次则网络状况不好）。然后对剩余从节点进行三轮考察： a. 第一轮考察：根据从节点的优先级排序，优先级由 slave-priority 配置项设置，优先级越小排名越靠前，优先级最高的从节点胜出； b. 第二轮考察：如果优先级相同，则查看复制下标，哪个从「主节点」接收的复制数据多（即 slave_repl_offset 最接近 master_repl_offset），哪个就靠前； c. 第三轮考察：如果优先级和复制下标都相同，就选择从节点 ID 较小的那个。

客户端获取新主节点端口的方式：

主要通过 Redis 的发布者/订阅者机制来实现。每个哨兵节点提供发布者/订阅者机制，客户端可以从哨兵订阅消息。主从切换完成后，哨兵就会向 +switch-master 频道发布新主节点的 IP 地址和端口的消息，客户端和哨兵建立连接后，会订阅哨兵提供的频道，此时客户端就可以收到这条信息，然后用这里面的新主节点的 IP 地址和端口进行通信。

回答

当 Redis 主节点挂了，哨兵（Sentinel）会从剩下的从节点里挑一个当新主节点。挑选规则主要是看谁的数据新、网络稳，然后几个哨兵投票决定。

客户端一开始是连哨兵问主节点在哪儿的，所以主节点换了之后，哨兵会告诉客户端新的主节点地址（比如新 IP 和端口 6379）。客户端收到后就会自动切过去，不用手动改配置。整个过程是自动的，业务基本无感。

17. Cluster 集群与主从相比有什么好处
#

分析

首先要了解什么是主从模式和 Cluster 集群，然后根据 Cluster 集群的优点和主从的缺点进行分析。

Redis Cluster 相比主从架构的核心优势体现在四方面：

数据分片
主从架构数据集中存储，存在单点瓶颈；Cluster 通过哈希槽（16384 slots）自动分片，数据均匀分布到多个节点，实现负载均衡，突破单机容量限制。
读写性能
主从架构写操作集中在主节点，读操作可能因同步延迟不一致；Cluster 所有节点均可读写，请求智能分配，避免单节点过载，提升高并发场景下的吞吐量。
高可用性
主从架构依赖哨兵或人工切换，故障恢复慢；Cluster 内置自动故障转移，节点故障时秒级迁移数据槽（slot），确保服务无中断。
弹性扩展
主从架构扩容需停机或复杂操作；Cluster 支持在线横向扩展，通过迁移数据槽平滑增删节点，适应业务动态增长。

总结：Redis Cluster 通过分布式架构天然解决主从的性能、可用性和扩展性瓶颈，更适合大规模高并发场景。

回答

Redis Cluster 相比主从模式的核心优势在于：

数据分片：通过 16384 个哈希槽自动分散数据，避免单机瓶颈；
读写性能：所有节点均可读写，智能分配请求提升并发能力；
高可用：内置自动故障转移，节点宕机时秒级切换；
弹性扩展：支持在线增删节点，通过槽迁移实现平滑扩容。

主从架构存在单点性能瓶颈、同步延迟、依赖哨兵切换和扩容复杂等问题，而 Cluster 的分布式设计天然解决了这些痛点，特别适合大规模高并发场景。

18. Cluster 的主节点是怎么选举出来的？
#

分析

Cluster 的主节点选举，其实就是问当主节点出问题，Cluster 是怎么进行故障转移的：

当一个从节点发现主节点宕机（处于 FAIL 状态），想要发起故障转移时，会先向集群里的其它节点发送数据包用于拉票，集群主节点收到这样的包后，如果在当前选举纪元中没有投过票，确认要对方投票的话，就会发送响应包。

从节点如果在一段时间内收到大部分主节点的投票，则表示选举成功，之后就可以升级为主节点，并接管老主节点所负责的槽位，并将这种变化广播给其它所有集群节点，让它们感知到这个变化，并修改自己过时的配置。

从节点升级成主节点，还需要：

遍历 16384 个槽，接管老主节点所负责的所有槽位；
更新集群状态（下线 -> 上线）；
向集群所有节点广播 PONG 包，将本节点上任以及接管槽位的信息通知给它们。

自此一个新的主节点就重新选举出来了。

回答

当 Redis Cluster 主节点宕机时，故障转移流程如下：从节点发现主节点 FAIL 后发起选举，向其他主节点拉票；获得多数主节点投票后即选举成功。新主节点会接管原主节点的所有负责的槽位，更新集群状态为上线，并向全网广播 PONG 消息通知变更。整个过程确保槽位分配一致，集群快速恢复可用。故障转移完全自动，无需人工干预，保证服务高可用。

19. cluster 为什么不用一致性哈希算法？
#

分析

首先需要了解什么是一致性哈希算法，然后分析下 cluster 的 hash 槽比起一致性哈希算法有什么优点即可。

回答

维护很简单（代码简单，原理简单，实现简单）；
减少 rehash 期间涉及的参与者数量；
Redis 客户端库例如 redis-py 这些，使用一致性哈希也会更复杂，因为我们希望客户端知道哪个 master 负责哪些 slots，以便客户端可以直接往 master 发送请求。

20. Redis Cluster 中如何保证一致性问题？
#

分析

其实就是问 gossip 协议原理。

回答

Redis Cluster 解决一致性问题，可以理解为每个人（Cluster 中的每一个节点）都会说流言蜚语，每个节点会向它知道的节点广播一些数据包，例如 PING 包，对方会回复 PONG 包，双方都会带上它知道的节点信息，就这样相互交换信息，最终整个集群会达到最终一致性。

21. Redis Cluster 扩缩容期间是否可以持续提供服务？底层机制是什么？
#

分析

Redis Cluster 扩容、缩容的本质其实是 slot 的迁移，分析下 slot 迁移的过程即可。

回答

可以提供服务。

Redis Cluster 扩容、缩容的本质其实是 slot 的迁移。在 slot 迁移过程，如果客户端给当前 Redis 节点发送请求，则有两种情况：

如果该 key 所对应的 slot 还在当前 Redis 节点，则直接处理，并返回处理结果；
如果该 key 所对应的 slot 还在迁移过程中，则该节点返回一个 ASK 重定向错误，告诉客户端该请求对应的 slot 正在进行迁移，请去目标节点发送请求吧。客户端接受 ASK 响应后，则先向目标节点发送一个 ASKING 指令，告诉目标节点，接下来的这条指令，你必须执行，然后紧接着发送原请求；
如果该 key 所对应的 slot 不在当前 Redis 节点，或者已经被迁移到其他目标节点了，则该节点返回一个 MOVED 重定向错误，客户端接受响应后，直接向目标节点发送指令即可，同时会更新客户端的 slot 缓存。

22. redis cluster 新增节点怎么扩容和迁移数据？
#

分析

需要回答新增节点如何正确的加入到集群，以及数据正确的迁移到新节点中：

当一个节点加入到 Redis Cluster 中时，会通过 Gossip 协议来传播集群状态信息，确保所有节点都知道新节点的存在。

对于每个需要迁移的哈希槽，Redis Cluster 会在源节点和目标节点之间进行以下操作：

目标节点向源节点发送 MIGRATE 命令，请求迁移指定哈希槽中的键值对；
源节点将指定的键值对逐个发送给目标节点；
目标节点接收到数据后，将其写入本地存储。

回答

新节点加入 Redis Cluster 时，首先通过 CLUSTER MEET 命令加入集群，Gossip 协议会同步集群状态。数据迁移通过以下步骤完成：

新节点被分配部分哈希槽；
源节点和目标节点建立迁移通道；
目标节点发送 MIGRATE 命令请求迁移指定槽位数据；
源节点逐个键值迁移，目标节点接收并存储；
迁移完成后更新集群配置，广播新槽位分配。

整个过程保证数据一致性，服务不中断，支持在线扩容。

Redis面试题库 - 这篇文章属于一个选集。

§ 9: 本文

1. Redis 集群架构模式有哪几种？#

2. Redis 主从复制过程是怎样的？#

3. Redis 的主从复制模式有什么优缺点？#

4. 哨兵机制是什么？#

5. 哨兵机制的工作原理？#

6. Redis sentinel（哨兵）模式优缺点有哪些？#

7. 说说 Redis 哈希槽的概念？#

8. 哈希槽和 Redis 节点是如何对应的？#

9. 主从模式的同步过程？#

10. 从服务重新上线之后，主服务器如何知道要将哪些增量数据发送给从服务器？#

11. Redis 如何减少主从数据的不一致？#

12. 主从模式是同步复制还是异步复制？#

13. 如何保证 Redis 的高可用性？#

14. Redis cluster 注重 CAP 哪两者？为什么？#

15. cluster 集群原理，客户端是怎样知道该访问哪个分片的#

16. 哨兵主节点是怎么选举出来的？如果主节点宕机了，客户端发来的请求怎么知道自己要请求的新的主节点是哪个端口？#

17. Cluster 集群与主从相比有什么好处#

18. Cluster 的主节点是怎么选举出来的？#

19. cluster 为什么不用一致性哈希算法？#

20. Redis Cluster 中如何保证一致性问题？#

21. Redis Cluster 扩缩容期间是否可以持续提供服务？底层机制是什么？#

22. redis cluster 新增节点怎么扩容和迁移数据？#