Redis 性能陷阱全拆解：90% 的团队错在让 Master 干了不该干的活这篇文章用“火锅店后厨模型”生动类比 Re

“Redis 的大多数性能问题，本质都是：把不该 Master 干的活，全塞给了 Master。”

这篇文章用“火锅店后厨模型”生动类比 Redis 主从架构中的职责错配问题。下面我为你系统梳理其六大核心问题与解决方案，并补充关键工程建议：

错误做法：在 Master 上开启 save 或 appendonly yes
后果：
- RDB：fork() 复制页表，大数据量下阻塞主线程（Copy-on-Write 虽优化但仍耗资源）
- AOF：持续写磁盘 + fsync 消耗 I/O 和 CPU
✅ 正确做法：
- Master 只处理读写请求
- 由 Slave 节点承担持久化任务（开启 AOF + appendfsync everysec）

📌 面试金句： “持久化与高并发服务解耦，是保障 Redis 稳定性的第一原则。”

配置建议：

# 在 Slave 节点配置
appendonly yes
appendfsync everysec   # 平衡性能与数据安全
no-appendfsync-on-rewrite no

误区：“加 Slave 能分担读压力” → 实则加重 Master 负担！
Master 额外开销：
- 为每个 Slave 维护独立的复制缓冲区（client output buffer）
- 发送 RDB 快照或增量命令
- 处理 ACK 和心跳
✅ 正确做法：
- 先监控 replication backlog、CPU、网络带宽
- 在业务低峰期扩容
- 使用 Proxy 层（如 Codis、Twemproxy）管理读写分离

风险：
- BGREWRITEAOF 会 fork() 子进程重写 AOF
- 主进程仍需记录增量写入到 AOF 重写缓冲区
- 内存压力 + CPU 负载飙升 → 请求延迟突增
✅ 解决方案：
- 不在 Master 执行，改在 Slave 上重写后替换
- 或安排在凌晨等低峰时段自动触发

错误结构（星型） ：
```
Master
 ├── Slave1
 ├── Slave2
 └── Slave3
```
- Master 压力大（N 倍复制流量）
- 故障切换复杂
推荐结构（链式） ：
```
Master → Slave1 → Slave2 → Slave3
```
- 复制压力逐级分摊
- Master 挂掉后，Slave1 可快速晋升（配合 Sentinel）
- 网络和资源消耗更低

📌 面试加分项： “链式复制不仅减轻主节点负担，还简化了故障转移拓扑。”

如果你正在准备面试，记住这句话就能打动面试官：

“让 Redis Master 专心抗并发，其他脏活累活交给 Slave 或外围系统——这才是高可用缓存架构的起点。”

Redis 性能陷阱全拆解：90% 的团队错在让 Master 干了不该干的活