当 Redis 遇到性能瓶颈时，需要从多个维度进行排查和优化。以下是系统化的解决方案，涵盖硬件、配置、数据模型、网络等关键点：

---

一、硬件资源优化

1. 内存瓶颈

   • 现象：频繁触发 OOM 或 used_memory 接近物理内存。
   • 解决：
     • 升级服务器内存（如从 32GB 升级到 128GB）。
     • 启用 Redis 6.0+ 的 maxmemory-policy 合理淘汰策略（如 allkeys-lru）。
     • 监控 used_memory_rss 和 used_memory，避免内存碎片（超过 1.5 倍时需重启或使用 MEMORY PURGE）。

2. CPU 瓶颈

   • 现象：used_cpu_sys 或 used_cpu_user 持续高位，QPS 无法提升。
   • 解决：
     • 升级 CPU（如从 4 核升级到 16 核）。
     • 启用 Redis 6.0+ 的多线程 I/O（io-threads 4）。
     • 避免复杂命令（如 KEYS *、SORT），改用 SCAN 或客户端分片。

3. 网络瓶颈

   • 现象：instantaneous_ops_per_sec 接近网卡带宽（如千兆网卡理论峰值 125MB/s）。
   • 解决：
     • 升级网卡（如万兆网卡）。
     • 启用压缩（如 lzf 压缩 RDB 文件）。
     • 使用连接池减少 TCP 握手开销。

---

二、配置参数调优

1. 持久化优化

   • RDB：
     • 调整 save 策略（如 save 900 1 改为 save 3600 1 减少触发频率）。
     • 使用 bgrewriteaof 替代频繁 bgsave。
   • AOF：
     • 启用 aof-use-rdb-preamble yes（Redis 4.0+ 混合持久化）。
     • 调整 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size。

2. 内存分配器

   • 现象：mem_allocator 使用 jemalloc 但仍有碎片。
   • 解决：
     • 编译时指定 MALLOC=libc 或 MALLOC=tcmalloc（需测试性能差异）。
     • 定期重启 Redis 清理碎片（生产环境需谨慎）。

3. 超时与重试

   • 设置 timeout 0（默认不超时），但需监控慢查询（slowlog-log-slower-than 10000）。
   • 客户端启用重试机制（如 Jedis 的 retryAttempts）。

---

三、数据模型与访问模式优化

1. 减少大键（Big Key）

   • 现象：MEMORY USAGE key 返回值超过 10KB。
   • 解决：
     • 拆分大键（如将 Hash 拆分为多个小 Hash）。
     • 使用 HSCAN 替代 HGETALL。

2. 热点键（Hot Key）

   • 现象：INFO keyspace 中某些键的访问量远高于其他键。
   • 解决：
     • 使用本地缓存（如 Guava Cache）减少 Redis 访问。
     • 将热点键迁移到独立 Redis 实例（如分片集群）。

3. 批量操作

   • 使用 MGET/MSET 替代多次 GET/SET。
   • 使用 Pipeline 减少 RTT（如 redis-cli --pipe 导入数据）。

---

四、架构扩展方案

1. 读写分离

   • 适用场景：读多写少（如 10:1）。
   • 实现：
     • 主节点写，从节点读（replicaof）。
     • 客户端路由（如 Spring Data Redis 的 ReadFrom 策略）。

2. 分片集群

   • 适用场景：单实例内存或 QPS 达到上限。
   • 方案：
     • Redis Cluster（自动分片，支持 16384 个槽）。
     • Twemproxy/Codis（需手动管理分片）。

3. 缓存穿透/雪崩/击穿防护

   • 穿透：空值缓存（如 SET key "" EX 60）。
   • 雪崩：随机过期时间（如 EX rand(60,120)）。
   • 击穿：互斥锁（如 SETNX 锁 + 双重检查）。

---

五、监控与诊断工具

1. 实时监控

   • INFO 命令：关注 instantaneous_ops_per_sec、used_memory、keyspace_hits。
   • MONITOR 命令（生产环境慎用，影响性能）。
   • Prometheus + Grafana：监控 redis_commands_processed_total 等指标。

2. 慢查询分析

   • SLOWLOG GET 10 查看最近 10 条慢查询。
   • 优化慢查询（如将 HGETALL 改为 HSCAN）。

3. 性能测试

   • redis-benchmark -n 100000 -c 50 模拟高并发。
   • 使用 memtier_benchmark 测试混合读写场景。

---

六、案例：从单实例到集群的迁移

1. 问题：单实例 Redis 内存 80GB，QPS 5 万，但写入延迟超过 50ms。
2. 优化步骤：
   • 启用多线程 I/O（io-threads 4），延迟降至 30ms。
   • 迁移到 Redis Cluster（3 主 3 从），QPS 提升至 15 万，延迟稳定在 10ms。
   • 热点键拆分到独立实例，延迟进一步降至 5ms。

---

总结

Redis 性能瓶颈的解决需结合 硬件升级、配置调优、数据模型优化、架构扩展 四方面。建议优先通过监控定位瓶颈点（如 INFO、SLOWLOG），再针对性优化。对于高并发场景，分片集群是最终解决方案，但需权衡运维复杂度。

我正在程序员刷题神器面试鸭上高效准备面试，9000+ 高频面试真题、800 万字优质题解，覆盖主流编程方向，跟我一起刷原题、过面试：
点击进入