redis latency-monitor-threshold 阈值需基于实测内在延迟动态设定，单位为微秒，必须先 config set latency-monitor-threshold 0 启用框架再设具体值；推荐阈值为基线最大延迟的20–100倍，通过 redis-cli --intrinsic-latency 100 在服务端执行获取准确基线。
延迟阈值不是固定值，而是基于基线性能动态设定的
Redis 的 latency-monitor-threshold 不能拍脑袋设成 10ms 或 100ms——它必须是你当前实例在低负载下测出的「内在延迟」的合理倍数。比如基线是 50μs，设阈值为 5000μs（100 倍）比设 1000μs 更有意义；否则大量正常波动会被误报。
用 redis-cli --intrinsic-latency 测基线，必须在服务端执行
这个命令测的是 Redis 进程自身处理能力，不含网络开销，所以得登录到 Redis 所在机器运行：
- 执行
redis-cli --intrinsic-latency 100，持续 100 秒，足够捕获偶发毛刺 - 关注输出里的
Max latency so far最大值，不是平均值——它代表你系统能容忍的「最差但尚可接受」延迟 - 如果最大值是 230μs，那阈值设 5000μs（≈22 倍）比较稳妥；若跑出过 1200μs，则阈值至少拉到 10000μs 以上
- 别在客户端机器上跑，否则混入了网络抖动，基线失真
latency-monitor-threshold 单位是微秒，且需先设为 0 再生效
很多人直接 CONFIG SET latency-monitor-threshold 5000 失败，是因为 Redis 默认关闭该监控框架：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 先执行
CONFIG SET latency-monitor-threshold 0启用框架 - 再执行
CONFIG SET latency-monitor-threshold 5000设具体阈值（单位：μs） - 该配置不持久化，重启后失效，需写入
redis.conf中的latency-monitor-threshold行 - 设太小（如 100）会导致日志刷屏；设太大（如 1000000）等于没开监控
阈值要和业务场景对齐，不是越小越好
金融交易类应用可能要求 P99 延迟 ≤ 2ms，那基线 50μs 对应的阈值就得压到 2000μs；而内部管理后台 P99 ≤ 50ms 就够用，阈值可放宽到 50000μs：
- 用
LATENCY LATEST查最近触发的延迟事件，看是否真影响业务请求 - 结合
SLOWLOG GET 5看慢查询是否同步发生——如果延迟尖峰时没慢命令，可能是后台 RDB/AOF 或内存碎片导致 - 阈值只管「单次事件」，不反映持续性压力；长期 avg latency 上升 3 倍，即使没触发阈值也该排查
真正容易被忽略的点是：阈值只记录「超时瞬间」，但 Redis 单线程特性意味着一次长延迟会阻塞后续所有命令——所以哪怕每小时只触发 1 次，也可能造成下游批量超时。盯住 LATENCY LATEST 输出里的时间戳和持续时长，比单纯看阈值是否触发更关键。
