延迟这个东西，平时看着平平无奇，一旦开始抖，排查起来能让人一整天坐在工位上说不出话。做 Redis 运维和开发的这些年，我处理过最多的线上问题不是"内存满了"也不是"主从断了"，而是响应延迟的波动——P99 从 2ms 突然窜到 80ms，过十分钟自己又好了，监控图上留下一根孤零零的尖刺，日志里什么都没写。这类问题最折磨人的地方在于它不像宕机那样给你明确信号，它只是让上游服务的超时率悄悄爬升，等到业务方找过来问"你们 Redis 是不是慢"，往往已经过去两三个小时了。
这篇内容把我对 Redis 响应延迟波动的完整理解整理出来：延迟到底该用什么口径去量、波动为什么分"周期性"和"随机性"两类、每一类最可能的元凶是什么、怎么用 SLOWLOG 之外的几个工具把问题从"感觉慢"收敛到"就是这一行配置"。适合已经能写基本命令、但在生产环境遇到延迟抖动仍然无从下手的朋友，也适合把这篇当成一份排查清单收着，下次出问题直接照着走。
1. 延迟波动比"慢"更难搞：先把手里的尺子校准
很多人第一反应是打开监控看平均延迟，看到 1.2ms 觉得挺健康，然后就卡住了。问题在于平均值是延迟指标里最不可信的一个。Redis 是单线程处理命令的模型（至少命令执行部分是），它的延迟分布天生是长尾的：99% 的请求在 0.2ms 完成，剩下 1% 可能撞上一次 fork 或者一次 AOF 刷盘，直接飙到 100ms。这 1% 混进平均值里几乎看不出来，但对上游来说就是实打实的超时。
1.1 分位数才是延迟的真实形状
我习惯同时看四个数：P50、P95、P99、P999。P50 反映常态处理能力，P99 和 P999 反映抖动程度。一个健康的 Redis 实例，P50 和 P999 的差距通常在 10 倍以内；如果 P50 是 0.3ms 而 P999 是 60ms，差距 200 倍，说明这个实例里存在某种间歇性的阻塞，即使平均值好看，也必须查。
这里有个容易忽略的细节：客户端测出来的延迟和 Redis 自己统计的延迟，口径完全不同。客户端测的是"从发出请求到收到响应"的完整链路，包含网络往返、连接池排队、客户端 GC 停顿；Redis 侧的命令耗时只统计"命令开始执行到执行完毕"。两者差多少，就是网络加排队的成本。这个差值本身就是非常有用的诊断信号，第 5 节会专门展开。
1.2 三条基线，缺一条就没法归因
排查延迟波动，我一般先建立三条基线，缺任何一条都会导致后面误判：
| 基线 | 测量方式 | 代表什么 | 典型健康值 |
|---|---|---|---|
| 机器固有延迟 | redis-cli --intrinsic-latency 100 | 脱离 Redis，纯内核与硬件的最长停顿 | 同机房内通常小于 1ms |
| 空载网络往返 | redis-cli --latency -h host -p port | 客户端到 Redis 的 RTT 加最小处理开销 | 同机房小于 0.5ms |
| 业务侧端到端延迟 | 应用埋点统计 | 真实用户体验到的耗时 | 与业务 SLA 对齐 |
--intrinsic-latency这个命令特别值得单独说，它做的事是：让当前进程空转 100 秒，期间不断读取时钟，记录两次读数之间的最大间隔。如果一台机器上跑出 15ms 甚至 50ms 的结果，那么这台机器上跑任何 Redis 都会抖，跟你的配置一点关系都没有——虚拟化平台的 CPU 抢占、NUMA 跨节点访问、甚至是宿主机上的其他负载，都会造成这种停顿。我遇到过一台云主机，--intrinsic-latency稳定输出 30ms 左右，换了配置、调了参数全都没用，最后换了宿主机才解决。这个命令只用五秒钟就能排除掉一整类可能性，性价比极高。
1.3 用--latency-history抓周期规律
redis-cli --latency只输出一个累计最大值，信息量有限。真正好用的是--latency-history，它按固定时间窗口（默认 15 秒）分段输出，能看到延迟随时间的变化曲线：
redis-cli -h 10.0.0.11 -p 6379 --latency-history -i 15输出大概长这样：
min: 0, max: 1, avg: 0.31 (15 samples) -- 15.01 seconds range min: 0, max: 62, avg: 0.54 (14 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.29 (15 samples) -- 15.01 seconds range第二段突然出现 max 62ms，第三段又恢复正常。这种"每隔一段时间出现一次尖刺"的模式，几乎直接指向后台任务——RDB 快照、AOF 重写、或者外部因素比如定时任务、日志轮转。如果尖刺出现的时间间隔非常规律，比如固定每 60 秒一次，那基本可以确定是某个周期性触发的动作。
排查时建议把
--latency-history长时间挂着跑，同时把 Redis 的INFO persistence和INFO stats每隔几秒采一次样，两个数据源按时间对齐看，尖刺出现的那一刻哪个指标变了，答案就出来了。
2. 把抖动分成两类：周期性的和随机的
拿到延迟曲线之后，我做的第一件事不是翻配置，而是给它分类。这个分类动作决定了后面八成的工作量往哪个方向投。分法很简单：尖刺出现有没有规律。
2.1 周期性抖动：后台任务的第一嫌疑
周期性抖动有几个经典面貌。一种是很规律的间隔，比如每 5 分钟、每 1 小时一次，这种多半跟触发型任务有关：定时 RDB 保存、AOF 自动重写（默认在 AOF 文件增长到上次重写后的 100% 且不小于 64MB 时触发）、外部定时脚本。另一种是不那么规律但频率很高，比如每隔几秒一次小抖动，这种要看是不是有客户端在做大批量扫描，或者主从复制的缓冲区在反复扩容。
我印象最深的一次是某个实例每 30 秒出现一次 40ms 左右的尖刺。翻了半天配置，最后发现是save 300 10之外的另一个情况：备份系统每 30 秒调一次BGSAVE做增量快照。这个操作本身设计上应该由上一次快照完成时间驱动，但备份脚本写成了固定间隔，碰上内存大的实例，两次 fork 之间的间隔比 fork 本身的耗时还短，等于一直在 fork。
fork 的代价值得单独讲，"fork 很快"这个说法在内存小的实例上成立，在大实例上完全不成立。fork 时需要复制父进程的页表，复制的成本跟页表项数量线性相关。一个 32GB 的实例，按 4KB 一页算有 800 万个页，每个页表项 8 字节，光页表复制就是 64MB 的内存拷贝，这还没算内核为每个页建立写保护的开销。实测下来这类实例 fork 一次 100ms 以上很常见。INFO stats里的latest_fork_usec记录了最近一次 fork 的微秒数，这个值超过 20000（20ms）就值得警惕了。
2.2 随机尖刺：命令本身与客户端的问题
随机尖刺就麻烦得多，因为它可能来自任何一层。我按概率从高到低排一下：
- 大 key 操作：对几百万字段的 Hash 做一次
HGETALL，或者对一个 10MB 的 String 做GET，单条命令就能占住主线程几十毫秒。这类命令特别隐蔽，因为它不"慢"——CPU 时间可能只有几毫秒，但网络传输和内存分配的开销都算在主线程头上。 - 复杂度超标的命令：
KEYS *、SMEMBERS大集合、ZRANGE大范围、SORT无 limit，这些在生产环境属于高危操作。 - 连接风暴：客户端连接数在短时间内冲高，Redis 需要为每个新连接分配内存、初始化结构，同时
ae事件循环要处理大量 accept 事件。 - 内存淘汰触发：当
maxmemory接近上限，每次写入都可能触发淘汰，如果淘汰策略是allkeys-lru且 key 数量巨大，采样和淘汰本身有开销。 - swap：这条单独拿出来讲，因为它的表现最暴力——一旦主线程的代码页或数据页被换出到磁盘，访问时就是毫秒级的磁盘 IO。Redis 数据量超过物理内存的那一刻，延迟曲线基本就废了。
2.3 一张症状对照表，先缩小范围
我不喜欢上来就讲一堆参数，排查效率最高的方式是先用症状缩小范围。下面这张表是我自己长期用的对照关系，可以直接照着往下找：
| 症状 | 高概率原因 | 优先验证手段 |
|---|---|---|
| 尖刺周期性出现，间隔固定 | RDB 保存、AOF 重写、外部定时任务 | INFO persistence采样对比 |
| 尖刺随写入量线性增加 | AOF fsync、磁盘 IO 饱和 | iostat -x 1看%util和await |
| 尖刺集中在部分命令 | 大 key、复杂度超标命令 | SLOWLOG GET+--bigkeys |
| 整段时间内延迟普涨 | CPU 饱和、swap、网络拥塞 | pidstat、vmstat、free -m |
| 只有客户端侧延迟高，服务端正常 | 连接池、客户端 GC、网络 | 两侧对比、客户端打点 |
| 主从切换或复制积压后出现 | 复制缓冲区、全量同步 | INFO replication |
这张表的价值在于避免"看到慢就去翻 slowlog"这种线性思维。实际上我处理过的案例里，SLOWLOG 里干干净净但延迟照样抖的情况非常多，因为slowlog-log-slower-than只统计命令执行时间，不包括在 socket 缓冲里排队的时间、不包括 fork 造成的停顿、更不包括网络往返。
3. 钻进服务端：从 SLOWLOG 到事件循环
确定问题在服务端之后，工具的使用顺序很关键。我用下来最有效的顺序是：先看INFO全局指标找异常，再用LATENCY系列命令定位具体事件，最后用SLOWLOG和大 key 扫描找命令级证据。反过来先看 SLOWLOG，容易被误导。
3.1 SLOWLOG 的盲区比想象中大
先把这个工具讲透，因为它被误用得太多了。SLOWLOG只记录命令实际执行所消耗的时间，阈值由slowlog-log-slower-than控制，单位微秒，默认 10000 即 10ms。它在三种情况下完全看不到问题：
第一，命令执行很快但排队很久。Redis 单线程处理命令，如果前面有一条耗时 50ms 的命令在跑，后面所有命令都要等，但每一条自己的执行时间依然很短，不会进慢日志。第二，fork 造成的停顿，主线程被暂停，这期间没有任何命令在执行，慢日志里一片空白。第三，网络传输时间，命令执行完把结果写进 socket 缓冲区就返回了，如果这个缓冲区满了或者客户端读得慢，主线程会阻塞在写操作上，这段也可能不计入。
所以在排查延迟抖动时，SLOWLOG的正确用法是"验证猜测"而不是"发现问题"。我会把阈值临时调到 5000 微秒跑一段时间：
redis-cli -p 6379 CONFIG SET slowlog-log-slower-than 5000 redis-cli -p 6379 SLOWLOG RESET # 观察一段时间后 redis-cli -p 6379 SLOWLOG GET 20 redis-cli -p 6379 CONFIG SET slowlog-log-slower-than 10000临时调低阈值这个操作别忘了改回来。慢日志本身占内存，而且
SLOWLOG GET返回的内容在日志量大的时候会影响一点性能，长期低阈值在生产环境不合适。
3.2 LATENCY 系列的三个子命令怎么分工
Redis 内置了一套延迟监控机制，原理是给若干关键事件打点，统计每个事件的最大耗时。开启方式很简单：
redis-cli -p 6379 CONFIG SET latency-monitor-threshold 100单位是毫秒，只有超过这个阈值的事件才会被记录。设成 0 是关闭，注意这点跟很多人的直觉相反。
三个子命令各有分工：
LATENCY LATEST：看所有被监控事件的最新一次、最大一次耗时，快速扫一眼有没有异常。LATENCY HISTORY <event>：看某个事件的历史时间序列，用来判断是不是周期性的。LATENCY DOCTOR：让 Redis 自己给一段人话分析，虽然措辞比较机械，但对没经验的人挺有用。
LATENCY LATEST的典型输出：
1) 1) "fork" 2) (integer) 1723600000 3) (integer) 118 4) (integer) 118四个字段分别是事件名、最近一次发生的时间戳、最近一次耗时、历史最大耗时。这里的fork事件 118ms 就很说明问题了。常见的事件名包括fork、aof-write、aof-fsync-always、aof-write-pending-fsync、expire-cycle、eviction-del、command。看到aof-write-pending-fsync数值大，基本就是磁盘 fsync 跟不上导致的写阻塞；看到expire-cycle大，说明过期 key 太多，清理周期占用了主线程。
3.3 新版本里的 latency-tracking，比 LATENCY 更细
Redis 7.0 之后引入了一套基于命令级别的延迟统计，跟前面的 LATENCY 是不同机制。它统计的是每条命令的延迟分位数，覆盖服务端执行加网络传输的完整时间：
redis-cli -p 6379 CONFIG SET latency-tracking yes redis-cli -p 6379 CONFIG SET latency-tracking-info-percentiles "50 99 99.9" redis-cli -p 6379 INFO latencystats输出里会按命令名给出 P50、P99、P999，形如latency_percentiles_usec_get:p50=0.150,p99=0.303,p99.9=1.023。这个信息在定位"是哪一类命令把延迟带高了"时非常直接——如果发现某个批量命令的 P999 是其他命令的几百倍，那它就是罪魁祸首，不需要再猜。我在 6.x 升级到 7.x 的实例上特别依赖这个指标，因为它能把"整体延迟高"拆到"某条命令延迟高"。
3.4 事件循环被谁堵住了：从 INFO 一路查到 perf
如果 LATENCY 没有记录到明显事件，但延迟确实在抖，就要怀疑主线程被某些"不产生延迟事件"的事情占住了。这时候看INFO stats和INFO commandstats：
redis-cli -p 6379 INFO stats | grep -E "instantaneous|total_commands|rejected" redis-cli -p 6379 INFO commandstats | sort -t: -k3 -rn | head -20instantaneous_ops_per_sec如果远低于预期，说明处理能力下降。commandstats里每条命令有calls、usec、usec_per_call，按usec排序能看到哪些命令累计消耗最多，按usec_per_call排序能看到单次最耗时的。两个视角都要看：前者反映整体压力来源，后者反映单条命令的重度。
再往下就要用系统层工具了。pidstat -p <pid> -u -r -d 1能同时看到 Redis 进程的 CPU、内存和磁盘，很实用。perf top -p <pid>能直接看热点函数，如果发现大量时间在memcpy、dictFind、lookupKey这类函数上，多半是大 key 或者单个大字典导致的。strace -c -p <pid>统计系统调用耗时，fsync、read、write出现异常数值就值得深挖。
3.5 内存相关的那几个隐形杀手
延迟抖动里有一类原因特别容易被忽略，就是内存层面的问题，因为它们不报错、不告警，只是让延迟慢慢变差。
swap排第一。free -m看 swap 使用量，只要不是 0 就应该警惕。vmstat 1里的si和so两列，非零就说明正在发生换页。我一般直接设置vm.swappiness = 1，不是 0 因为某些内核版本上 0 会引发 OOM 而非换页。
内存碎片排第二。INFO memory里的mem_fragmentation_ratio是used_memory_rss / used_memory，正常情况下在 1.0 到 1.5 之间。超过 1.5 说明 RSS 比实际数据占用大很多，可能是频繁增删导致碎片；小于 1 则说明已经用到了 swap，这是个危险信号。碎片率高的时候，分配器要在更多页上找空闲块，内存访问的局部性变差，CPU cache 命中率下降，延迟自然会涨。Redis 4.0 之后提供了activedefrag可以自动整理，但它本身消耗 CPU，需要在低峰期开启：
redis-cli -p 6379 CONFIG SET activedefrag yes redis-cli -p 6379 CONFIG SET active-defrag-ignore-bytes 100mb redis-cli -p 6379 CONFIG SET active-defrag-threshold-lower 10透明大页（THP）排第三，这个是最"玄学"的一个。THP 会把 4KB 的页合并成 2MB，本来是为了减少 TLB miss，但在 Redis 的 fork + COW 场景下，COW 的粒度从 4KB 变成了 2MB，一次写操作就要复制 2MB 内存，fork 期间的延迟会显著放大。官方文档一直建议关闭：
echo never > /sys/kernel/mm/transparent_hugepage/enabled这个设置要注意写进开机脚本，重启后会失效。我见过不止一个团队排查了几天延迟抖动，最后发现是机器重建之后没人重新关 THP。
4. 持久化：抖动最主要的固定来源
如果让我给"延迟波动的来源"排个序，持久化相关的能占一半以上。原因不复杂：RDB 和 AOF 本质上都是在内存数据库旁边挂一个磁盘写入，而磁盘的延迟比内存高几个数量级，一旦这条路径出现等待，主线程就会被拖住。
4.1 fork 的真实成本，跟你想的不一样
前面提了 fork 会复制页表，这里把账算清楚一点。fork 的耗时大致由三部分组成：页表复制、内存分配器元数据复制、以及后续 COW 缺页中断的累计开销。第一部分跟实例内存量线性相关，第二部分的量级较小，第三部分才是最难量化的——它在 fork 之后的整个快照期间持续发生，表现为延迟的持续轻微上升而不是一个尖刺。
实测数据大概是这样的：8GB 实例 fork 耗时 15~30ms，16GB 大约 40~70ms，32GB 可以到 100ms 以上，64GB 的实例在一些环境下能到 300ms。这个数字跟 CPU 主频、页大小、NUMA 配置都有关系，波动很大，所以不要拿别人的数据套自己的环境，一定要看自己实例的latest_fork_usec。
优化方向有三个。一是降低单实例体积，把 60GB 拆成三个 20GB，fork 耗时直接降一个量级，这也是我倾向于单实例不超过 16GB~20GB 的原因。二是减少 fork 次数，调整save策略、拉长 AOF 重写触发间隔，避免短时间内连续 fork。三是关掉 THP，减少 COW 的复制粒度。
还有一个细节容易被忽略：INFO stats里的total_forks记录了累计 fork 次数。如果你发现这个数增长得比预期快，说明有额外的 fork 在发生，可能是外部备份脚本，也可能是 AOF 重写被频繁触发（重写期间有新写入会再触发，形成连锁）。
4.2 AOF 三种刷盘策略的实际延迟曲线
appendfsync三个选项的差异，很多资料只讲理论，不讲实际表现，容易让人做错决策：
| 策略 | 机制 | 数据安全 | 延迟表现 |
|---|---|---|---|
always | 每条写命令都 fsync | 最好 | 延迟直接等于磁盘 fsync 延迟，机械盘上能到毫秒级 |
everysec | 后台线程每秒 fsync 一次 | 最多丢 1 秒 | 常态平滑，但 fsync 慢时会阻塞主线程 |
no | 交给操作系统 | 不可控 | 常态最快，但写缓冲堆积后会出现剧烈抖动 |
everysec是绝大多数场景的选择，但它有个隐藏问题：主线程在把 AOF 缓冲区内容写入文件时，如果发现上一次后台 fsync 还没完成，会阻塞等待。这就是aof-write-pending-fsync这个延迟事件的来源。所以"每秒 fsync 一次"不等于"永远不会因为 fsync 阻塞"，磁盘 IO 一旦吃紧，主线程照样卡。
aof-write事件记录的是主线程写 AOF 文件本身的耗时，如果这个值高，说明磁盘写入能力不足；aof-fsync-always只在always策略下有意义。这三个事件分开看，能准确判断是"写不进去"还是"刷不下去"。
4.3 一套渐进式的持久化优化方案
我不建议一上来就关持久化，那样数据风险太大。按风险从低到高，我通常这样推进：
第一步，错峰。把save策略调整到跟业务低峰对齐，比如save 900 1加save 300 10，去掉过于频繁的触发条件。如果实例只做缓存、数据可从 DB 重建，直接save ""关掉 RDB 也是常见做法。
第二步，分离磁盘。AOF 文件和 RDB 文件写到不同的物理盘，如果条件允许，AOF 单独挂一块 SSD。IO 争抢是延迟抖动最常见的物理原因之一，iostat -x 1里%util超过 70% 就要考虑扩容了。
第三步，重写期间不刷盘。设置no-appendfsync-on-rewrite yes，AOF 重写期间暂停 fsync，用"重写期间可能丢更多数据"换取"重写期间主线程不被阻塞"。这个取舍在多数缓存场景是可接受的，但要跟业务方明确沟通。
第四步，控制 AOF 重写触发条件。auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配合调整，避免重写过于频繁。我一般把min-size设到 4GB 以上，因为小文件重写虽然快，但频繁触发累积起来一样影响延迟。
第五步，考虑多线程 IO。Redis 6.0 引入的io-threads能把网络读写分摊到多线程，主线程只做命令执行，能明显缓解高并发下的延迟。配置方式是io-threads 4配合io-threads-do-reads yes，线程数建议不超过 CPU 核数的 3/4。
这些步骤里，第四步和第三步是最容易见效的，我处理的多数实例改完这两条延迟尖刺就少了一大半。光纤、SSD 这些硬件层面的升级效果当然更彻底，但成本考虑通常排在后面。
5. 客户端与网络：被误判成"Redis 慢"的重灾区
有一类投诉我遇到太多次：业务方说 Redis 延迟飙到几百毫秒，登录机器一看INFO里一切正常，--latency测出来 0.3ms。这种时候问题八成不在 Redis 这边，而在客户端到 Redis 之间。
5.1 连接池参数错配制造的假象
连接池的问题特别有欺骗性，因为它的症状跟服务端压力大的表现几乎一样。典型场景：池子最大连接数设得太小（比如 8），并发请求一多，大量线程在池子里等连接，等到的线程拿到的"延迟"里包含了排队时间，业务监控上看到的就是 Redis 变慢，但服务端一点压力都没有。
判断方法很简单，把客户端侧的"取连接耗时"和"命令执行耗时"分开打点。取连接耗时高就是池子不够，执行耗时高才是 Redis 的问题。这个拆分很多团队一开始没做，导致排查方向完全错。
池子配置的经验值：最大连接数不要超过maxclients的 1/3，留出余量给其他客户端和内部连接；最小空闲连接数设为最大值的 20% 到 30%，避免频繁创建销毁；连接空闲检测时间不要设太短，频繁的重连本身也有成本。另外，maxmemory之外的maxclients一旦被打满，新连接会被拒绝，客户端重试会形成雪崩，所以监控里要把connected_clients和rejected_connections都盯上。
5.2 超时与重试，会放大每一次抖动
这个问题比连接池更隐蔽：Redis 出现一次 50ms 的抖动，本该只影响那一次请求，但如果客户端超时设成 20ms 且配置了自动重试，这一次抖动会被放大成三次请求，重试的请求又可能撞上下一次抖动。在抖动频繁的时段，重试会造成请求量翻倍，把一次小抖动变成一次持续的延迟高峰。
我一直建议的原则是：Redis 客户端超时不要设得太激进，重试次数不要超过 1 次，并且重试要有退避。超时时间至少设到 P999 延迟的 2 到 3 倍，比如 P999 是 20ms，超时设 50ms 到 60ms。这样偶发的单次尖刺不会触发重试，只有真正的问题才会。
还有一个场景是 pipeline 和批量命令。用 pipeline 一次发 100 条命令，如果中间有一条大 key 命令，整个 pipeline 的耗时会被它拉长，而客户端的超时是针对整个 pipeline 的。这种时候拆小批次比调大超时更有效，我一般建议单批不超过 50 到 100 条，且批次内不要混入体积不确定的命令。
5.3 TCP 层面的几个细节
网络层面还有几个点，虽然不常出问题，但一旦出问题很难查：
TCP backlog：Redis 的tcp-backlog默认 511，对应内核的somaxconn。如果内核值是 128（很多系统默认），而 Redis 设的是 511，实际生效的是较小的那个。连接数突增时，accept 队列满了会导致握手被丢弃，客户端表现为连接超时。检查方式sysctl net.core.somaxconn，两边都调到 1024 或更大。
Nagle 算法：Redis 默认tcp-nodelay yes，关掉了 Nagle，避免小包延迟。这个一般不用动，但如果有人为了"减少包数量"手动关掉，就会引入最多 40ms 的延迟。
客户端缓冲区：client-output-buffer-limit配置不当，慢消费者会撑大输出缓冲区，Redis 内存上涨的同时，主线程往这个缓冲区写数据也可能阻塞。监控INFO clients里的client_recent_max_output_buffer，这个值异常大说明有客户端消费不过来。
5.4 一个复查清单，避免来回甩锅
延迟问题最容易演变成"不是我们的问题"的拉锯战。我一般用下面这套证据来定责，五分钟能出结论：
- 同时段采集服务端
INFO latencystats的 P99 和客户端埋点的 P99。 - 两个数字接近（差距小于 20%），问题在 Redis 侧，去查第 3、4 节。
- 客户端远高于服务端，问题在链路，先查连接池和网络。
- 客户端高但取连接耗时占比大，就是池子不够。
- 客户端高但重试次数多，就是超时设得太紧。
这套流程用下来，绝大多数"Redis 慢"的争议都能用数据说清楚，省下大量扯皮时间。
6. 从止血到治本：把抖动压进可接受区间
前面几节讲的是定位，这一节讲怎么收尾。我的做法是先做能立刻见效的止血动作，再安排结构性的改造，两者之间不冲突。
6.1 立刻能做的几个动作
按见效速度排，我通常先动这几项：
- 关闭 THP，写完记得持久化到开机脚本。
- 检查 swap 使用，
vm.swappiness调到 1，必要时加内存。 - 把
slowlog-log-slower-than临时调到 5ms，跑半小时捞一遍，看看有没有意外的大命令。 - 用
redis-cli --bigkeys扫一遍，同时对疑似大 key 用MEMORY USAGE确认体积。扫描要在从节点或者低峰期做，因为它本身会消耗资源。
--bigkeys的原理是对每种数据类型抽样SCAN，不会有阻塞风险，但也不是全量统计，所以它会漏。真要精确找大 key，得用SCAN配合MEMORY USAGE全量跑，代价高，一般只在怀疑有超大 key 的时候做。用OBJECT ENCODING能看编码方式，如果一个 Hash 的字段数超过hash-max-listpack-entries（默认 128）就会从紧凑编码转成哈希表，内存和访问开销都会跳一个台阶，这也是很多"看起来不大但很慢"的 key 的原因。
6.2 大 key 治理的实际收益
我给大 key 下个操作性定义：String 类型超过 10KB、集合类型元素数超过 5000，或者单 key 的MEMORY USAGE超过 1MB，就值得处理了。处理方式分三种：
拆分：把一个大 Hash 按业务维度拆成多个小 Hash，加一个前缀区分。比如用户属性按属性组拆成user:123:base、user:123:ext。拆分的关键是选对维度，按访问模式拆，经常一起读的放一起。
改造访问方式：HGETALL改成按需HMGET，SMEMBERS改成SSCAN分批，KEYS改成SCAN。这几个改动对延迟的改善非常直接，我在一个实例上把一个 200 万成员的 Set 从SMEMBERS改成SSCAN分页，那条命令的 P999 从 400ms 降到了 3ms 以内。
异步删除：删除大 key 用的是DEL会阻塞主线程，必须用UNLINK（4.0+），它把实际的内存释放交给后台线程。同样，过期删除在 4.0+ 也是异步的，但EXPIRE大 key 仍有开销，配合lazyfree-lazy-expire yes更稳妥。
6.3 监控怎么配才不会被噪音淹没
延迟监控配得太粗会漏，配得太细会天天告警。我的经验是按分位数设两级阈值：P99 超过基线的 3 倍报"关注"，P999 超过 50ms 报"告警"。这两个值要基于自己的基线动态调整，不要抄别人的数字。
需要采集的指标项，我列一个最小集合：
| 指标 | 来源 | 关注点 |
|---|---|---|
| P99 / P999 延迟 | INFO latencystats | 趋势变化，不看绝对值 |
latest_fork_usec | INFO stats | 超过 20000 就要看实例体积 |
mem_fragmentation_ratio | INFO memory | 大于 1.5 或小于 1 |
aof_last_bgrewrite_status | INFO persistence | 非 ok 就是异常 |
connected_clients | INFO clients | 接近 maxclients 的 80% |
evicted_keys | INFO stats | 非零说明内存不足 |
rejected_connections | INFO stats | 非零说明连接被打满 |
这七项加起来采集成本很低，但能覆盖绝大多数延迟问题的前置信号。尤其是evicted_keys，很多人不知道内存淘汰本身会产生延迟尖刺，等它开始大量淘汰的时候，延迟已经抖得不成样子了。
回归验证这件事我特别想强调：改完配置不要立刻宣布解决。至少观察一个完整的业务周期（通常 24 小时），并且要覆盖到之前出现尖刺的时间点。我吃过亏，改完当天一切正常，第二天同一时间尖刺又回来了，因为触发条件是备份任务，而我改的是 Redis 配置。验证的时候把变更记录和延迟曲线放在一起看，才能真正确定因果关系，而不是碰巧赶上了。
最后分享一个我后来养成的小习惯：每次延迟问题处理完，把当时的INFO all输出、延迟曲线截图、以及最终的根因分析存成一个文件，按时间归档。半年下来这会变成一份非常贴合自己环境的排查手册，比任何通用文档都好用，因为里面全是你自己踩过的坑。
