大厂Redis面试通关(2):主从延迟过高、repl-backlog爆满?这4道生产,让你彻底搞懂主从复制!
- 2026-10-21 06:20:28
面试官问：“Redis主从复制延迟过高怎么解决？”、“repl-backlog-size 设置多少合适？”
如果你只会背“全量同步+增量同步”，那面试官可能会觉得你没处理过真实的线上延迟告警。真正的运维，必须能把主从复制的底层机制和调优参数讲得明明白白。
这是【DevOps-运维小子】Redis面试通关合集的第2篇。
📊 【考点7：使用 Redis INFO 命令查看哪些关键指标？】
👉 基础回答：Server（版本）、Clients（连接数）、Memory（内存）、Persistence（RDB/AOF状态）、Stats（命中率）、Replication（主从信息）、CPU。
👉 生产级回答（加分项）：“我们重点监控几个核心指标：
mem_fragmentation_ratio（内存碎片率，>1.5需关注）。connected_clients（连接数，防止连接耗尽）。keyspace_hits / (keyspace_hits + keyspace_misses)（缓存命中率，低于90%需排查）。master_link_status（主从连接状态，必须为up）。”
🛠️ 【考点8：简述 Redis 主从复制工作原理？】
👉 生产级回答：“从节点发送 PSYNC 命令，主节点触发 bgsave 生成 RDB 快照，发送给从节点，期间写命令存入 repl-backlog（复制积压缓冲区）。从节点加载 RDB 后，主节点发送缓冲区指令。后续持续异步同步。⚠️ 这里有一个关键参数：repl-backlog-size 默认只有1MB。如果写入量极大，主从断开重连后，如果偏移量不在缓冲区内，会导致全量同步，数据量大会打满带宽。生产环境建议调整为 64MB 甚至更大。”
📈 【考点9：Redis 主从复制延迟过高怎么解决？】
👉 排查思路：
网络带宽是否打满（跨机房、跨地域）。
主节点写入量是否过大（大事务、大Key）。
从节点配置是否过低（CPU、内存）。
repl-backlog-size是否过小。
👉 生产级回答（加分项）：“如果从节点执行 slave-read-only yes 还发现数据不一致，可能是因为从节点刚从主节点全量同步完成，或者从节点处理慢。可通过 info replication 查看 master_link_status 和 master_last_io_seconds_ago。⚠️ 优化方案：拆分大Key、升级从节点硬件、调整复制缓冲区、使用集群分片分散写入压力。”
🏗️ 【考点10：Redis 高可用方案有哪些？】
👉 标准回答：主从复制、哨兵（Sentinel）、Redis Cluster 集群。
👉 生产级回答（加分项）：“小规模用哨兵，数据量超过单机内存用 Cluster。⚠️ Cluster 存在 MOVED 和 ASK 重定向，客户端必须支持 Cluster 协议。此外，Cluster 的 Gossip 协议通信会消耗一定带宽，节点数不宜过多（建议不超过1000个节点）。”
你们在生产环境里，主从延迟最高达到过多少秒？是怎么解决的？欢迎评论区聊聊。
上面展示的仅仅是核心考点。为了方便大家复习，我整理了《Redis生产级面试通关全集》PDF + 4个生产排查脚本（包含内存碎片告警、大Key安全扫描、慢查询分析）。
👉 关注公众号【DevOps-运维小子】，后台回复【Redis面试】，直接领走！
(预告：下一篇讲“高可用架构与故障排查”，哨兵模式怎么选主？脑裂怎么解决？Cluster不可用常见原因是什么？全是高薪运维的必考大招。)