Redis 集群高频面试题（真实面试版）

Redis集群高频面试题（真实面试版）一、基础认知类（初级必问）1、说一说RedisCluster集群的核心架构？默认节点配置是什么？RedisCluster是Redis官方无中心分布式集群方案，核心采用主从分片+哈希槽模式，实现数据分片存储和高可用。默认标准架构是3主3从，也是生产最常用的配置：3个主节点负责读写、分片存储数据，3个从节点分别对应主节点做数据备份，实现故障自动切换。集群所有节点互相通信，采用Gossip协议同步集群状态、节点信息，无需单独部署哨兵组件，自带高可用能力。2、RedisCluster哈希槽的作用是什么？为什么是16384个？哈希槽是RedisCluster数据分片的核心，集群把所有数据映射到0-16383共16384个哈希槽，每个主节点负责维护一部分固定槽位。写入数据时，通过CRC16(key)%16384计算key对应的槽位，从而定位到对应主节点，实现数据分散存储。设置16384个槽位主要是工程层面的折中选择：1、槽位太少，数据分片粒度粗，节点负载不均衡，扩容迁移数据量过大；2、槽位太多会增大集群元数据的存储和同步开销，占用节点内存、增加Gossip协议通信压力；3、16384刚好适配Redis的节点通信、数据迁移逻辑，是官方验证的最优值。3、Redis单机、主从、哨兵、集群的区别和适用场景？单机：单节点部署，无备份、无高可用，挂掉直接服务不可用。只适用于本地测试、临时小业务，生产完全不用。主从模式：一主多从，主写从读，数据同步备份，但无自动故障转移，主节点挂掉后业务中断。适用于简单读分流场景，对可用性要求不高的业务。哨兵模式：基于主从，新增哨兵节点监控主从状态，主节点故障可自动选主、切换，保证高可用。但不支持数据分片，所有数据存在一套主从中，容量和性能受单节点限制，适用于数据量不大、要求高可用的场景。Cluster集群：支持数据分片、读写分离、故障自动转移、横向扩容，解决了单机容量和性能瓶颈，是生产大数据量、高并发Redis业务的首选。二、核心原理类（中级高频）1、RedisCluster如何实现数据读写路由？什么是重定向？客户端连接集群任意节点发起读写请求，节点会先计算key对应的哈希槽：1、如果当前节点负责该槽位，直接处理请求并返回结果；2、如果不属于当前节点槽位，节点会返回MOVED重定向信息，告诉客户端目标节点地址和端口，客户端重新向正确节点发起请求。另外集群支持客户端缓存槽位映射表，客户端本地维护槽位与节点的对应关系，正常情况下无需重复重定向，大幅提升请求效率。只有集群节点变更、槽位迁移时，才会触发重定向更新本地缓存。2、RedisCluster数据同步机制是什么？主从同步流程？集群主从同步和单机主从逻辑一致，采用异步复制，主节点写入成功后立即返回客户端，后台异步同步数据到从节点，不影响主流程性能。完整同步流程：1、从节点首次上线，向主节点发送同步请求；2、主节点执行bgsave生成RDB快照，发送给从节点；3、主节点同步快照期间的增量命令，写入复制缓冲区；4、从节点加载RDB文件，再执行增量缓冲区命令，完成全量同步；5、后续持续执行增量异步复制，维持主从数据一致。缺点是异步复制存在短暂数据不一致，极端场景主节点故障切换会丢失少量数据。3、集群为什么不支持多key批量操作？比如mget、mset？RedisCluster的多个key大概率分布在不同哈希槽、不同主节点上，而批量操作需要保证原子性，跨节点无法实现原子执行，因此集群默认禁止跨槽位多key批量操作。唯一例外是哈希标签key，通过{}包裹key的有效部分，让多个key计算出同一个哈希槽，即可支持批量操作。比如{user:100}:name、{user:100}:age，会路由到同一个节点。4、RedisCluster集群的Gossip协议作用？集群所有节点通过Gossip协议两两通信，主要负责：1、同步集群节点状态：在线、下线、故障、角色变更；2、同步槽位分配信息，保证所有节点集群数据一致；3、故障节点探测、集群状态更新，为故障转移提供依据。Gossip采用随机点对点通信，不会所有节点同时广播消息，降低集群通信压力，保证集群稳定性。三、故障与高可用类（中高级核心）1、RedisCluster主节点故障，自动切换流程？1、集群其他节点通过心跳检测，发现主节点超时无响应，标记该节点为疑似故障；2、集群超过半数主节点确认该主节点故障，正式判定节点下线；3、故障主节点对应的从节点，发起选举投票；4、集群主节点投票选出新主节点，从节点升级为主节点，接管原有哈希槽位；5、原故障主节点重启后，自动降级为从节点，挂载到新主节点下，同步数据。2、集群最大容忍多少个节点故障？3主3从架构下最坏情况？RedisCluster基于半数机制判断故障，3主3从标准架构下：1、单个主节点、单个从节点故障，集群完全正常，不影响读写；2、如果某一组主从全部故障，该组对应的哈希槽全部失效，集群直接不可用；3、集群最多容忍半数以下主节点故障，3主节点最多挂1个主节点，挂2个主节点集群直接宕机。3、什么是集群脑裂？如何解决？脑裂是集群网络分区导致的异常问题：网络波动将集群分割为两个分区，少数节点分区独立选举出新主节点，出现同一套集群存在两个主节点的情况，新旧主节点同时接收写入，导致数据错乱、丢失。生产主流解决方案：1、配置cluster-min-replicas-to-write1，主节点至少有1个正常从节点才接收写入，避免孤立主节点写数据；2、调整集群超时参数，缩短故障判定时间，快速识别网络分区；3、通过监控告警，及时发现并修复网络分区问题。4、RedisCluster数据丢失的场景有哪些？1、主从异步复制：主节点写入成功，还未同步到从节点就宕机，切换后数据丢失；2、集群脑裂：分区期间少数主节点写入数据，网络恢复后被覆盖丢失；3、节点故障过快：主节点瞬间宕机，来不及触发同步和故障转移；4、手动迁移槽位、扩容缩容操作不当，导致数据遗漏。四、运维与扩容优化类（高级/运维面试）1、RedisCluster如何扩容？新增主从节点流程？集群支持在线扩容，无需停机，核心是新增节点、迁移槽位、均衡数据：1、启动新的空Redis节点，加入现有集群；2、手动分配哈希槽位，从原有主节点迁移部分槽位到新主节点；3、集群自动迁移对应槽位的key数据，迁移过程不影响业务读写；4、为新主节点挂载从节点，保证集群高可用架构完整；5、验证槽位分配、数据一致性，完成扩容。2、集群缩容怎么做？需要注意什么？缩容核心是先迁移槽位，再下线节点，禁止直接删除节点：1、将待下线主节点的所有哈希槽位，全部迁移到集群其他主节点；2、槽位和数据全部迁移完成后，确认节点无数据、无任务；3、执行节点下线命令，移除节点，关闭服务。注意事项：缩容必须保证集群槽位完整，不能出现槽位空缺；缩容过程避开业务高峰期，防止数据迁移影响性能。3、RedisCluster集群热点key问题怎么解决？热点key是大量请求集中访问某一个key，导致单节点压力过大，集群负载失衡。解决方案：1、拆分热点key：将大key、热点key拆分多个子key，分散到不同节点；2、本地缓存兜底：高频静态热点数据，客户端本地缓存，减少Redis请求；3、调整哈希标签：合理规划key分布，避免大量key扎堆同一槽位；4、临时扩容对应节点资源，针对性提升单节点性能；5、监控热点key，提前发现并优化业务逻辑。4、RedisCluster相比哨兵模式的优缺点？优点：1、支持数据分片，突破单节点内存、QPS瓶颈，可横向无限扩容；2、无中心节点，架构更健壮，不存在单点故障；3、自带高可用、故障转移能力，无需额外部署哨兵组件；4、数据分散存储，单节点故障影响范围小。缺点：1、不支持跨槽位多key原子操作，业务开发有一定限制；2、集群部署、运维复杂度高于哨兵模式；3、异步复制依然存在数据丢失风险，无法做到强一致性。五、实战场景面试题（手撕问答）1、线上Redis集群某主节点CPU飙升，排查思路？1、监控定位：查看是否是热点key、大key导致高频读写；2、命令排查：是否存在keys、hgetall等高危耗时命令；3、连接排查：是否存在大量无效连接、慢查询堆积；4、集群状态：查看槽位是否均衡、节点是否频繁数据迁移、同步；5、业务层面：是否有批量写入、批量删除逻辑，引发瞬时压力。2、Redis集群数据不一致、