Redis面试题 04

目录

1. Redis 常见性能问题和解决方案？

2. 说说为什么 Redis 过期了为什么内存没释放？

3. Redis 突然变慢，有哪些原因？

4. 为什么 Redis 集群的最大槽数是 16384 个？

💡 面试加分技巧：场景化串联

1. Redis 常见性能问题和解决方案？

核心回答逻辑：从“慢查询”、“大 Key”、“网络/架构”三个维度展开。

话术参考：
“Redis 的性能问题通常表现为响应变慢或吞吐量下降，我主要从以下三个维度排查和解决：

1. 慢查询（Slow Log）：

   • 现象：某些命令执行时间过长。
   • 原因：使用了高复杂度命令（如KEYS *,HGETALL大 Hash），或者 Value 过大。
   • 解决：开启slowlog监控，找出耗时命令并优化；避免在生产环境使用O(N)复杂度的命令；拆分大 Key。

2. 大 Key（BigKey）问题：

   • 现象：单个 Key 的 Value 过大（如 String > 10KB, Hash/List 元素 > 5000）。
   • 危害：读取时阻塞网络带宽，删除时阻塞主线程，主从同步延迟。
   • 解决：使用redis-cli --bigkeys或 RDB 分析工具定位。对大 Key 进行拆分（如大 Hash 拆分为多个小 Hash）；删除时使用UNLINK代替DEL进行异步非阻塞删除。

3. 架构与网络瓶颈：

   • 现象：单机 QPS 达到上限，或网络带宽打满。
   • 解决：
     • 读写分离：利用主从架构，将读请求分摊到从节点。
     • 集群化：使用 Redis Cluster 进行分片，水平扩展存储和计算能力。
     • 客户端优化：使用连接池，避免频繁建立连接；使用 Pipeline 批量操作减少 RTT（网络往返时间）。

4. 持久化影响：

   • 原因：RDBbgsave或 AOFrewrite时 fork 子进程可能引起短暂停顿，AOF 刷盘策略过于激进（everysec 或 always）。
   • 解决：在低峰期执行持久化操作；合理配置appendfsync（通常选 everysec）；确保服务器内存充足，避免 fork 失败。”

2. 说说为什么 Redis 过期了为什么内存没释放？

核心回答逻辑：解释“定期删除的局限性” + “内存淘汰策略未触发”。

话术参考：
“这是一个非常经典的误区。Redis 键过期了，内存不一定立即释放，主要原因有两点：

1. 过期删除策略的机制（惰性 + 定期）：

   • Redis 不会在键过期的瞬间立刻删除它。它采用惰性删除（访问时才删）和定期删除（每秒随机抽查一部分）。
   • 如果一个 Key 过期了，但既没有被访问，也没被定期删除策略抽中，它就会一直留在内存中，直到被访问或被下一次定期删除选中。

2. 内存淘汰策略（Eviction Policy）未触发：

   • 即使有过期键存在，只要 Redis 当前使用的内存总量未达到maxmemory上限，Redis 就不会主动去清理那些‘虽然过期但还没被删掉’的 Key，也不会触发内存淘汰机制。
   • 只有当内存满了，且配置了淘汰策略（如allkeys-lru），Redis 才会积极地去清理数据（包括已过期的和未过期的）。

总结：过期只是给 Key 打了个‘死亡标记’，真正的物理删除是滞后的。如果发现内存长期不释放，可以检查maxmemory配置是否合理，或者是否存在大量‘僵尸 Key’（已过期但未访问）。”

3. Redis 突然变慢，有哪些原因？

核心回答逻辑：按“紧急程度”和“常见度”排序，展示排查思路。

话术参考：
“如果线上 Redis 突然变慢，我会按照以下步骤快速排查：

1. 是否有 BigKey 操作：

   • 检查是否有读写超大 Key 的操作，导致网络阻塞或单命令执行时间过长。
   • 检查是否有DEL大 Key 操作阻塞了主线程（应改用UNLINK）。

2. 是否有高复杂度命令：

   • 查看慢查询日志（Slow Log），确认是否有KEYS *,FLUSHALL,HGETALL(大对象),SORT等命令在执行。

3. 持久化导致的阻塞：

   • 检查是否正在执行 RDBbgsave或 AOFrewrite。Fork 子进程时可能会造成毫秒级的停顿；如果磁盘 IO 压力大，AOF 刷盘也会变慢。

4. 内存淘汰（Eviction）开销：

   • 如果内存已满，Redis 需要频繁执行淘汰算法（如 LRU 链表维护），这会消耗大量 CPU，导致处理请求变慢。

5. 网络与带宽：

   • 检查服务器网卡流量是否打满（如发生了缓存雪崩，大量请求涌入）。
   • 检查是否有热 Key（Hot Key）问题，导致单个分片负载过高。

6. CPU 竞争：

   • 检查宿主机或其他容器是否占用了大量 CPU 资源，导致 Redis 线程调度不及时。

排查手段：优先使用SLOWLOG GET 10看慢命令，INFO stats看命中率/连接数，INFO memory看内存使用率。”

4. 为什么 Redis 集群的最大槽数是 16384 个？

核心回答逻辑：从“心跳包大小”和“工程权衡”角度解释。

话术参考：
“这个数字是 Redis 作者在设计 Cluster 协议时做出的工程权衡，主要基于以下考虑：

1. 心跳包的大小限制：

   • Redis 集群中，节点之间通过 Gossip 协议发送心跳包来同步元数据（包括槽的分布情况）。
   • 每个节点需要在心跳包中携带自己负责的槽位信息。如果槽位数量太多（比如 2^32 个），心跳包会变得非常大，占用过多网络带宽，影响集群通信效率。
   • 16384 个槽位可以用2KB左右的位图（Bitmap）来表示（16384 bits = 2048 bytes），这是一个在网络传输中非常小的开销。

2. 集群规模的实际需求：

   • Redis 官方建议集群节点数不超过 1000 个。
   • 16384 个槽位足以支撑上千个节点的平滑迁移和负载均衡。对于绝大多数业务场景，这个数量已经绰绰有余。
   • 如果槽位太少（如 100 个），在节点扩容/缩容时，数据迁移的粒度太粗，难以做到精细均衡。

总结：16384 是一个在网络带宽开销和数据迁移粒度之间取得的最佳平衡点。计算公式大致是2^14 = 16384，既保证了心跳包小巧，又满足了大规模集群的调度需求。”

💡 面试加分技巧：场景化串联

如果面试官问得比较散，你可以尝试串联起来回答，展示系统性思维。例如：

“关于 Redis 的性能和稳定性（Q1, Q3），我们最怕遇到大 Key和慢查询，这往往是导致 Redis突然变慢的元凶。
而关于内存管理（Q2），我们要理解 Redis 的过期删除机制是滞后的，不能指望过期就立马释放，需要配合合理的maxmemory策略。
最后，在设计集群架构时（Q4），Redis 选择了16384 个槽位，这是为了在保证数据均匀分布的同时，控制节点间心跳包的大小，体现了极致的工程权衡。”

这样回答会让面试官觉得你不仅背了知识点，而且真正理解了整个技术体系。