redis-cli --latency 输出的 min/avg/max/stddev 中，stddev >1ms 即需警惕抖动，常见表现为 min 很低、max 突增、stddev 持续 >2ms 而 avg 正常，反映网络或服务端不稳定，可能引发应用超时重试或连接池打满。
redis-cli --latency 采样结果怎么看抖动
它输出的不是单次延迟，而是持续采样的最小值、平均值、最大值和标准差（stddev），其中 stddev 超过 1ms 就值得警惕——说明网络或 Redis 服务端响应不稳定，不一定是带宽问题，更可能是队列积压、CPU 抢占或网卡中断不均。
常见错误现象：min 很低（如 0.1ms）、max 突然跳到 20ms+、stddev 持续 >2ms，但 avg 看着还“正常”。这时候应用层可能已出现超时重试或连接池打满。
- 用
redis-cli --latency -h <hostname> -p <port></port></hostname>启动，建议至少运行 60 秒以上，避免偶然毛刺干扰判断 - 如果 Redis 启用了密码认证，必须加
-a <password></password>，否则会连到无认证的默认实例（或报错退出），导致误判 - 不要在 Redis 主节点负载高时采样，
--latency本身会发PING命令，加重服务端压力，建议搭配redis-cli --latency-history分时段观察
和应用真实延迟对不上？检查客户端连接路径
redis-cli --latency 测的是本机到 Redis 的 TCP RTT + 服务端处理 PING 的时间，而应用延迟还包括：DNS 解析、连接池获取连接、序列化反序列化、命令排队、pipeline 批处理开销等。所以即使 --latency 显示稳定，应用仍可能抖动。
使用场景：当你发现应用日志里 io.lettuce.core.RedisCommandTimeoutException 频发，但 --latency 数据良好，大概率是客户端侧的问题。
- 确认应用和
redis-cli是否走同一条网络路径（比如是否都绕过代理、是否同属一个 Kubernetes Pod 网络平面） - 检查客户端是否启用了
tcp-nodelay（Lettuce 默认开启，Jedis 需手动配置），禁用会导致小包合并，放大延迟抖动 - 用
ss -ti或tcpretrans查看连接是否存在大量重传，这是底层网络丢包的直接证据，--latency不会暴露这点
为什么 --latency 显示延迟低，但 monitor 看到命令执行慢
redis-cli --latency 只测 PING，而 redis-cli monitor 捕获的是所有命令的到达和服务端返回时间差。两者差异大，说明问题不在网络链路，而在 Redis 内部：比如 KEYS * 阻塞、大 value 序列化、AOF fsync 延迟、内存碎片导致 alloc 缓慢等。
性能影响：一个慢命令会让后续所有命令排队，--latency 因为只发 PING，且优先级高，容易“插队”，掩盖真实瓶颈。
- 运行
redis-cli --latency -l（loop 模式）同时开另一个终端跑redis-cli monitor | head -n 100，对比时间戳，能快速定位是否命令执行阶段拖慢 - 检查
INFO commandstats中cmdstat_get:calls=...后面的usec_per_call，若远高于--latency的avg，说明命令处理本身有压力 - 注意
monitor本身会显著降低 Redis 性能，仅临时诊断，不可长期开启
跨机房/云厂商场景下 --latency 的局限性
当 Redis 实例在异地（如上海 ECS，应用在深圳容器），--latency 只反映单向链路质量，无法体现跨公网 NAT、SLB、安全组策略变更、运营商路由抖动等中间环节的影响。此时最大值频繁突增，但标准差未必高——因为抖动是周期性或偶发性的，不是随机分布。
兼容性影响：某些云 Redis 服务（如阿里云 Tair、腾讯云 CRS）对 PING 命令做了限频或代理转发，--latency 结果可能失真，甚至返回 NOAUTH Authentication required 却不提示密码错误。
- 务必用
redis-cli -h <host> -p <port> -a <pass> PING</pass></port></host>手动测试连通性和基础认证，排除代理层拦截 - 在应用部署节点上运行
mtr --report <redis-host></redis-host>，看哪一跳延迟突增或丢包，比单纯依赖--latency更准 - 如果必须跨地域访问，考虑启用 Redis 的
replica-serve-stale-data no配合本地哨兵探测，而不是只信客户端单点采样
真正难定位的抖动，往往藏在 --latency 和应用日志之间那几十毫秒的“灰色间隙”里：TCP 重传队列、内核 socket buffer 溢出、cgroup CPU throttling、甚至网卡驱动版本缺陷。别只盯着 Redis 自己。
