redis比较常见的性能问题

一、内存相关问题​
​1. 内存不足（OOM）​​
​现象​：OOM errors、响应超时、节点崩溃。
​原因​：
数据量超过 maxmemory 限制。
未设置合理淘汰策略（如 allkeys-lru）。
​解决​：
监控内存使用（INFO memory），预留 20%~30% 缓冲。
设置 maxmemory-policy（推荐 volatile-lru 或 allkeys-lru）。
拆分大 Key（见下文），开启内存碎片整理（activedefrag yes）。
​2. 内存碎片过高​
​现象​：mem_fragmentation_ratio > 1.5（INFO memory 查看），内存浪费严重。
​原因​：频繁修改、删除 Key（如 List 元素 pop/push）。
​解决​：
开启碎片整理：activedefrag yes + 调整 active-defrag-* 参数。
升级 Redis 6.2+（优化 jemalloc 碎片管理）。
避免频繁删除大 Key，重启节点释放碎片（谨慎操作）。
⚡ ​二、CPU 与延迟问题​
​1. CPU 跑满（100%）​​
​现象​：响应延迟飙升，slowlog 大量记录。
​原因​：
​复杂命令​：KEYS *、FLUSHALL、大数据集 SINTER/ZUNIONSTORE。
​过期 Key 集中清理​（active-expire-cycle 占用）。
​RDB/AOF 持久化​：bgsave 或 rewriteaof 时 fork 阻塞。
​解决​：
​禁用高危命令​：rename-command KEYS “”。
避免单 Key 过大（拆分集合类型）。
调整持久化策略：AOF 改为 everysec，减少 RDB 频率。
升级 SSD 磁盘（降低 fork 阻塞时间）。
​2. 慢查询（Slow Query）​​
​现象​：SLOWLOG get 记录大量 >10ms 操作。
​原因​：
​大 Key 操作​：获取 10MB 的 String，遍历 100 万成员的 Set。
​不合理管道​：PIPELINE 内堆积过多命令阻塞响应。
​解决​：
​所有操作时间复杂度必须为 O(1) 或 O(logN)​。
禁止 HGETALL、SMEMBERS → 用 HSCAN/SSCAN 分批次获取。
控制 Pipeline 命令数量（一般不超过 100/次）。
使用 redis-cli –latency 检测网络延迟问题。
📦 ​三、数据模型问题​
​1. 大 Key（Big Key）​​
​定义​：
String 类型 > 10 KB
集合类型（Hash/List/Set/ZSet）元素 > 5,000
​风险​：阻塞网络、内存溢出、持久化超时。
​排查​：redis-cli –bigkeys（生产慎用，改用离线分析工具）。
​优化​：
​拆分 Key​：Hash → user:{id}:profile_base + user:{id}:profile_detail。
​压缩​：gzip 压缩 String 值（需权衡 CPU）。
​分片读取​：ZRANGEBYSCORE → ZSCAN 分批操作。
​2. 热 Key（Hot Key）​​
​现象​：单 Key QPS > 5,000，节点流量不均。
​解决​：
​客户端缓存​：Redis 6.0+ Client-side Caching（CLIENT TRACKING）。
​读分离​：增加副本节点分担读压力。
​本地缓存​：在应用层用 Caffeine 或 Guava Cache 挡一层。
​分片存储​：将 Key 复制多份（如 hot_key_v1, hot_key_v2），轮询访问。
📡 ​四、网络与连接问题​
​1. 连接数耗尽​
​现象​：ERR max number of clients reached，新连接失败。
​原因​：
maxclients 设置过低（默认 10,000）。
客户端未释放连接（如连接池泄漏）。
​解决​：
调高 maxclients（需考虑系统句柄数限制）。
使用连接池（如 Lettuce、Jedis），检查泄漏（CLIENT LIST 看 idle 时间）。
​2. 网络拥堵​
​现象​：throughput 下降，延迟抖动。
​原因​：
单节点流量超过网卡上限（如 10 Gbps）。
跨机房访问（网络延迟增加）。
​解决​：
分片集群：增加节点分摊流量。
同机房部署：避免跨 AZ 访问。
升级网络：万兆网卡或 RDMA。
💾 ​五、持久化问题​
​1. AOF 阻塞写入​
​现象​：aof_delayed_fsync 计数上升，主线程阻塞。
​原因​：appendfsync always 每次写入同步磁盘（性能极差）。
​解决​：改为 appendfsync everysec（平衡性能与安全）。
​2. RDB fork 超时​
​现象​：bgsave 时主线程卡顿数秒。
​原因​：数据集大 + 磁盘慢，fork() 耗时过长。
​优化​：
使用 SSD 磁盘。
控制 save 频率（如从 save 60 10000 调整为 save 300 1000）。
关闭透明大页（THP）：echo never > /sys/kernel/mm/transparent_hugepage/enabled。
⚙️ ​六、集群与高可用问题​
​1. 数据倾斜​
​表现​：部分节点内存/CPU 使用率远超其他节点。
​解决​：
​均匀分片​：避免使用单一 hash tag（如 {user123}）。
扩容集群：增加分片数。
手动迁移 Slot（CLUSTER SETSLOT + MIGRATE）。
​2. 脑裂（Split-Brain）​​
​现象​：主从切换后数据丢失。
​预防​：
设置 min-slaves-to-write 1（至少 1 个从节点同步才可写）。
合理配置 cluster-node-timeout（默认 15s，避免过早切换）。