Redis 性能瓶颈时如何处理？

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

内存瓶颈
- 现象：频繁触发 OOM 或 used_memory 接近物理内存。
- 解决：
  - 升级服务器内存（如从 32GB 升级到 128GB）。
  - 启用 Redis 6.0+ 的 maxmemory-policy 合理淘汰策略（如 allkeys-lru）。
  - 监控 used_memory_rss 和 used_memory，避免内存碎片（超过 1.5 倍时需重启或使用 MEMORY PURGE）。
CPU 瓶颈
- 现象：used_cpu_sys 或 used_cpu_user 持续高位，QPS 无法提升。
- 解决：
  - 升级 CPU（如从 4 核升级到 16 核）。
  - 启用 Redis 6.0+ 的多线程 I/O（io-threads 4）。
  - 避免复杂命令（如 KEYS *、SORT），改用 SCAN 或客户端分片。
网络瓶颈
- 现象：instantaneous_ops_per_sec 接近网卡带宽（如千兆网卡理论峰值 125MB/s）。
- 解决：
  - 升级网卡（如万兆网卡）。
  - 启用压缩（如 lzf 压缩 RDB 文件）。
  - 使用连接池减少 TCP 握手开销。

持久化优化
- 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。
内存分配器
- 现象：mem_allocator 使用 jemalloc 但仍有碎片。
- 解决：
  - 编译时指定 MALLOC=libc 或 MALLOC=tcmalloc（需测试性能差异）。
  - 定期重启 Redis 清理碎片（生产环境需谨慎）。
超时与重试
- 设置 timeout 0（默认不超时），但需监控慢查询（slowlog-log-slower-than 10000）。
- 客户端启用重试机制（如 Jedis 的 retryAttempts）。

减少大键（Big Key）
- 现象：MEMORY USAGE key 返回值超过 10KB。
- 解决：
  - 拆分大键（如将 Hash 拆分为多个小 Hash）。
  - 使用 HSCAN 替代 HGETALL。
热点键（Hot Key）
- 现象：INFO keyspace 中某些键的访问量远高于其他键。
- 解决：
  - 使用本地缓存（如 Guava Cache）减少 Redis 访问。
  - 将热点键迁移到独立 Redis 实例（如分片集群）。
批量操作
- 使用 MGET/MSET 替代多次 GET/SET。
- 使用 Pipeline 减少 RTT（如 redis-cli --pipe 导入数据）。

读写分离
- 适用场景：读多写少（如 10:1）。
- 实现：
  - 主节点写，从节点读（replicaof）。
  - 客户端路由（如 Spring Data Redis 的 ReadFrom 策略）。
分片集群
- 适用场景：单实例内存或 QPS 达到上限。
- 方案：
  - Redis Cluster（自动分片，支持 16384 个槽）。
  - Twemproxy/Codis（需手动管理分片）。
缓存穿透/雪崩/击穿防护
- 穿透：空值缓存（如 SET key "" EX 60）。
- 雪崩：随机过期时间（如 EX rand(60,120)）。
- 击穿：互斥锁（如 SETNX 锁 + 双重检查）。

实时监控
- INFO 命令：关注 instantaneous_ops_per_sec、used_memory、keyspace_hits。
- MONITOR 命令（生产环境慎用，影响性能）。
- Prometheus + Grafana：监控 redis_commands_processed_total 等指标。
慢查询分析
- SLOWLOG GET 10 查看最近 10 条慢查询。
- 优化慢查询（如将 HGETALL 改为 HSCAN）。
性能测试
- redis-benchmark -n 100000 -c 50 模拟高并发。
- 使用 memtier_benchmark 测试混合读写场景。

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