connected_clients是准实时值，每次执行INFO时遍历连接链表；instantaneous_ops_per_sec是100ms延迟的滑动平均；used_memory原子更新但mem_fragmentation_ratio因依赖系统调用而滞后数秒；expired_keys等累计值仅在事件触发时更新。
INFO 命令返回的多数指标不是实时更新的，而是周期性采样或延迟计算的结果；直接拿 instantaneous_ops_per_sec 或 connected_clients 当毫秒级监控值会误判。
INFO 中哪些字段是“准实时”的，哪些是“延迟更新”的
Redis 的 INFO 输出里混着三类数据来源：即时计算值、定时采样值、后台异步统计值。不区分就容易把缓存值当真相。
-
connected_clients是即时值 —— 每次执行 INFO 时遍历当前连接链表，基本可视为实时 -
instantaneous_ops_per_sec是过去 1 秒的滑动平均值，由 Redis 内部每 100ms 更新一次计数器再推算得出，存在最多 100ms 延迟 -
used_memory是每次内存分配/释放时原子更新的，但mem_fragmentation_ratio依赖used_memory_rss，而后者来自sbrk()或mallinfo()系统调用，可能滞后几秒（尤其 jemalloc 下） -
expired_keys、evicted_keys这类累计值只在键真正过期或淘汰时递增，不会主动扫描统计，所以长期没触发淘汰就一直是 0
为什么 INFO stats 里的延迟指标看起来“跳变”或“卡住”
Redis 不为每个命令单独打时间戳，而是靠周期性采样 + 滑动窗口估算延迟分布，latencystats 和 instantaneous_ops_per_sec 都受这个机制影响。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
latencystats默认每 250ms 采样一次命令执行耗时，且只保留最近 16384 个样本；如果 QPS 很低，可能几十秒才攒够一个有效窗口，导致输出为空或长时间不变 -
instantaneous_ops_per_sec的底层是两个 1 秒前的计数器差值，若 Redis 正在做bgsave或 AOF rewrite，主线程被阻塞，采样点可能丢失，造成数值突降甚至为 0 - 某些字段如
rdb_last_bgsave_time_sec是上一次操作结束时写入的，只要没新快照，它就永远不更新 —— 不代表“当前正在执行”，只代表“上次花了多久”
想获取更及时的状态，该换什么方式
INFO 是快照式诊断工具，不是流式监控接口。真要盯住变化节奏，得绕开它或补手段。
- 用
redis-cli --stat命令替代手动轮询 INFO —— 它内部每秒发一次INFO stats并只显示关键字段，自动处理了采样抖动 - 对连接数、内存等关键指标，配合
MONITOR+ 简单脚本做事件驱动捕获（注意MONITOR有性能损耗，仅调试用） - 生产环境务必通过
CONFIG GET hz查看当前配置的hz值（默认 10），它决定了键过期检查、客户端超时清理等后台任务的频率，间接影响 INFO 中expired_keys、client_longest_output_list等字段的更新灵敏度 - 不要依赖
INFO replication中的master_last_io_seconds_ago判断主从断连 —— 它只在心跳检测失败后才更新，实际断连到字段变化可能间隔长达 60 秒（取决于repl-timeout）
最常被忽略的一点：INFO 本身也是个 Redis 命令，执行过程会进入命令队列、参与排队和响应，高负载下它的返回时间本身就可能超过 10ms —— 所以别指望用它来测亚毫秒级抖动。
