把 Redis 的性能与稳定性调到最佳目 录一、导读二、内存优化2.1 关键指标2.2 内存碎片整理2.3 数据与编码优化三、性能压测3.1 redis-benchmark3.2 压测要点四、监控体系4.1 INFO 常规巡检4.2 慢查询4.3 全链路监控五、其他调优项六、本篇小结一、导读前几讲解决了「能跑、能高可用、能避坑」本讲聚焦「跑得快、看得清、扛得住」从内存优化、性能压测到监控体系把调优方法论落到可执行的命令与指标上。调优不是盲目调参而是先量化、再优化、后验证。二、内存优化2.1 关键指标先用 INFO memory 摸清内存现状redis-cli INFO memory# used_memory_human 逻辑数据占用# used_memory_rss 实际物理内存# mem_fragmentation_ratio 碎片率 rss / used2.2 内存碎片整理碎片率mem_fragmentation_ratio过高意味着内存碎片多。仅当 ratio 1.5 且 rss - used 100MB 时才值得干预且需分配器为 jemalloc、Redis ≥ 6.2。开启 activedefrag 并配合四个协同参数activedefrag yesactive-defrag-ignore-bytes 100mbactive-defrag-threshold-lower 12active-defrag-cycle-min 100active-defrag-cycle-max 5002.3 数据与编码优化优先使用紧凑编码小 Hash / List / ZSet 自动用紧凑表避免单值过大。为大 key 做拆分、为热点数据设置合理 TTL及时清理过期键。选用合适的内存淘汰策略缓存用 allkeys-lru / allkeys-lfu业务数据用 noeviction。三、性能压测3.1 redis-benchmarkRedis 自带基准测试工具模拟 N 个并发客户端发送 M 个请求常用参数redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -k 1# -c 并发连接数 -n 总请求数 -d 数据大小# -P 管道请求数 -q 只输出每秒请求数redis-benchmark -t set,get,lpush -q# 只测指定命令输出每秒请求数QPS3.2 压测要点压测在独立客户端节点进行避免与服务端争抢资源。用 -r 随机 key避免命中同一 key 造成假象。关注 QPS 与延迟含 p99单测只测命令不代表真实业务。开启 -P 观察 Pipeline 带来的吞吐提升。四、监控体系4.1 INFO 常规巡检指标含义关注点used_memory / rss逻辑 / 物理内存碎片率、是否接近 maxmemorykeyspace_hits / misses命中 / 未命中命中率 hits / (hitsmisses)connected_clients连接数是否接近上限instantaneous_ops_per_sec实时 QPS波动与容量total_commands_processed累计命令数长期趋势4.2 慢查询用 SLOWLOG 定位阻塞命令如大集合操作、KEYS及时优化或移到从库redis-cli SLOWLOG GET 10redis-cli SLOWLOG LEN4.3 全链路监控生产推荐 Prometheus redis_exporter Grafana 组合redis_exporter 暴露标准指标redis_up、redis_memory_used_rss_bytes、redis_commands_total 等Prometheus 抓取Grafana 绘制大盘并告警。请求量rate(redis_commands_total[5m])。内存redis_memory_used_rss_bytes。可用性redis_up。五、其他调优项方向手段说明连接maxclients / timeout控制连接上限避免耗尽句柄网络Pipeline / 批量命令减少往返 RTT提升吞吐IO多线程网络 IO6.0io-threads 提升收发能力持久化混合持久化 / 独立 SSD降低 fork 与刷盘对主线程影响过期随机 TTL / 定期清理避免集中失效六、本篇小结调优是一套「先量化 → 再优化 → 后验证」的方法论内存看碎片与淘汰压测看 QPS 与延迟监控靠 INFO / SLOWLOG / Prometheus 三件套。调优目标不是压榨单点极限而是让 Redis 稳定、可控、可观测。