1. 为什么我劝你别再把 info 当成看一眼内存的指令很多人对 Redis 的info指令的印象大概停留在运维排障时敲一下看看内存用了多少、连接数多少这个层面。我早期也是这样直到有一次线上一个缓存集群出现间歇性超时监控大盘上 QPS 和内存都正常最后是靠info里latency和commandstats两段数据才定位到问题——某个业务方在批量调用一个复杂度很高的命令把单线程堵住了。从那以后我才真正把info当成一个诊断仪表盘来用而不是一个内存查看器。info是 Redis 内置的状态查询指令它把服务端运行时的各类指标按模块分段输出涵盖服务基本信息、客户端连接、内存占用、持久化状态、主从复制、CPU 消耗、命令调用统计、集群状态、键空间分布等。它能解决的问题非常实际判断实例是否健康、定位性能瓶颈、评估容量水位、排查主从延迟、审计命令使用是否合理。适合谁来参考我觉得三类人最该吃透它——一是负责 Redis 运维的工程师二是写业务代码但需要对自己用的命令负责的后端开发三是做容量规划和稳定性建设的同学。哪怕你只是刚接触 Redis 的新手把info的各段含义搞明白也比背一堆命令语法更有长期价值因为它直接对应这个实例现在到底怎么样这个最核心的问题。这篇内容我会按整体设计思路—分段细节拆解—实操排查流程—常见坑与速查表的顺序展开中间穿插我自己踩过的坑和参数判断经验。所有命令和输出结构都基于 Redis 的通用实现不同版本字段会有增减我会在关键处标注版本差异避免你照着老资料对不上号。2. info 指令的整体设计与输出结构拆解2.1 一条指令背后的分段设计逻辑info最容易被忽略的设计点是它默认并不返回全部内容而是按段section组织你可以只取关心的部分。这个设计不是随便定的背后是性能与可读性的权衡全量info在指标很多的实例上输出可能上千行如果每次排障都拉全量既浪费带宽也干扰阅读。所以 Redis 允许你用info section精确取段比如info memory只看内存、info replication只看主从。默认不带参数执行info时返回的是默认段集合通常包括 server、clients、memory、persistence、stats、replication、cpu、cluster、keyspace 这些核心段而commandstats、latencystats、errorstats这类统计段默认不返回需要显式指定。这个细节很多人不知道导致排查命令级问题时敲了info却找不到commandstats还以为是指令不支持。从实现角度看info是同步执行的它会在主线程里遍历各个模块收集指标。这意味着在超大实例上频繁调用全量info本身也会占用一点主线程时间虽然单次开销很小但如果你写了个脚本每秒全量拉一次累积起来就不是小事了。我的建议是日常监控用info的指定段且采集间隔别太激进需要全量快照时再拉全量。2.2 各段职责的横向对照为了让你一眼看清每段管什么我整理了一张对照表。这张表是我自己排障时贴在便签上的版本按排障时最常看的顺序排列段名核心职责典型排障场景是否默认返回server版本、运行模式、运行时长、配置文件路径确认实例身份、版本兼容性是clients当前连接数、阻塞连接、最大连接数连接打满、连接泄漏是memory内存占用、碎片率、峰值、淘汰统计内存告警、碎片过高是persistenceRDB/AOF 状态、最近保存结果持久化失败、fork 阻塞是stats命令总数、命中未命中、过期键数命中率低、键过期异常是replication主从角色、偏移量、从库状态主从延迟、复制断开是cpu用户态/内核态/后台 CPU 消耗CPU 飙高定位是commandstats各命令调用次数与耗时慢命令、命令滥用否latencystats各命令延迟百分位分布尾延迟分析否errorstats各类错误计数客户端报错归因否cluster集群状态、槽位分配集群健康检查是keyspace各库键数量与过期键数量键分布、过期堆积是这张表的价值在于当你遇到某类问题时能立刻知道该看哪一段而不是盲目全量拉。比如连接数告警直接看 clients主从延迟直接看 replication路径非常清晰。2.3 为什么指定段比全量更值得养成习惯我见过不少团队的监控脚本是这么写的定时执行info然后把整段文本丢进解析器提取几个字段。这种写法能跑但有两个隐患。第一全量输出随版本升级字段会变解析器容易因为多了一行而报错第二全量拉取在指标多的实例上开销更大。改成info memory、info stats这种精确取段后解析逻辑更稳定采集开销也更可控。还有一个更隐蔽的点info的输出格式是段名 冒号分隔的键值对不同版本对同一字段的单位可能调整比如内存单位、时间单位如果你用全量文本做正则匹配很容易匹配到别的段里同名字段。指定段之后解析范围被限定出错概率大幅下降。这是我在维护一套跨版本监控采集时踩过的坑后来全部改成按段采集才稳定下来。3. 核心分段逐项拆解与关键字段解读3.1 server 与 clients先确认我是谁、谁在连我info server这段看起来最静态但排障时它是第一步。里面几个字段值得重点关注redis_version决定你能用哪些特性、字段是否存在redis_mode告诉你这是单机、哨兵还是集群模式模式不同后续排查路径完全不同uptime_in_seconds反映实例运行时长如果这个值很小但你印象中实例跑了很久那说明它刚重启过可能是崩溃重启必须查日志config_file能确认实例加载的是哪个配置文件避免改了配置没生效的乌龙——我遇到过好几次运维改的是 A 路径的配置实例实际加载的是 B 路径白折腾半天。info clients这段字段不多但极其关键。connected_clients是当前连接数maxclients是上限两者一对比就知道水位。blocked_clients表示正在阻塞等待的客户端数量比如执行了阻塞类命令的客户端这个值持续偏高往往意味着有业务在用阻塞操作且没设合理超时。client_recent_max_input_buffer和client_recent_max_output_buffer反映客户端缓冲区峰值如果输出缓冲区异常大可能是某个客户端消费太慢导致服务端堆积严重时会拖垮内存。注意connected_clients接近maxclients时新连接会被拒绝业务侧表现为连接超时。这时候别急着调大上限先确认是不是连接池配置不合理或存在连接泄漏盲目调大只是把问题往后推。3.2 memory内存水位与碎片率的正确读法info memory是大家最熟的一段但真正读对的人不多。核心字段有这么几个used_memory是 Redis 分配器统计的已用内存used_memory_rss是操作系统视角的常驻内存used_memory_peak是历史峰值mem_fragmentation_ratio是rss / used_memory的比值也就是碎片率。碎片率怎么判断我的经验是比值在 1 到 1.5 之间基本正常超过 1.5 说明内存碎片偏多可以考虑在低峰期做碎片整理具体手段取决于版本支持情况如果比值小于 1说明部分内存被换出到磁盘了这通常意味着物理内存紧张性能会明显下降属于危险信号。这里要强调碎片率不是越低越好略大于 1 是健康的因为分配器本身有管理开销。还有一个常被误读的字段是used_memory_dataset和used_memory_overhead的区分。前者是纯数据占用后者是管理结构开销。如果你的数据量不大但used_memory_overhead很高可能是键数量太多导致元数据开销大这时候要考虑是否键的粒度太细、能否合并。maxmemory和maxmemory_policy也要一起看确认淘汰策略是否和业务预期一致——我见过把策略设成不淘汰、结果内存打满后写入直接报错的案例业务方还以为是 Redis 挂了。3.3 persistence持久化状态里的隐藏信号info persistence这段在排障时经常被跳过但它藏着不少信号。rdb_last_bgsave_status和aof_last_bgrewrite_status告诉你最近一次后台保存是否成功如果是 err说明持久化已经出问题了只是还没影响到读写所以没人发现。rdb_last_save_time是最近一次成功保存的时间戳如果这个时间离现在很久而你的配置是定时保存那就要怀疑保存是否被阻塞或失败了。rdb_changes_since_last_save表示自上次保存以来有多少次写操作这个值持续增长而不回落说明保存一直没成功触发。latest_fork_usec记录最近一次 fork 的耗时微秒这个字段很关键fork 耗时过长会阻塞主线程导致请求毛刺。如果这个值达到几十毫秒甚至更高说明实例数据量大或系统内存压力大需要考虑调整保存策略或拆分实例。提示aof_rewrite_in_progress和rdb_bgsave_in_progress为 1 时表示后台任务正在进行此时主线程可能受 fork 影响。排查延迟毛刺时把毛刺时间点和这两个字段对照往往能对上。3.4 stats 与 commandstats命中率与命令画像info stats里最常看的是keyspace_hits和keyspace_misses两者算出命中率。命中率低不一定是坏事要看业务模型如果大量请求本来就是查不存在的键比如防穿透逻辑低命中率是正常的但如果预期高命中却很低就要查是不是键设计有问题、过期时间太短、或者缓存被频繁淘汰。expired_keys和evicted_keys也要分开看前者是自然过期后者是被淘汰策略清掉的后者持续增长说明内存不够用了。info commandstats默认不返回需要显式指定。它按命令维度给出calls调用次数、usec总耗时微秒、usec_per_call单次平均耗时。这段是定位谁在拖慢实例的利器。我的用法是先看calls排序找出高频命令再看usec_per_call找出单次耗时高的命令两者交叉就能锁定问题命令。比如某个遍历类命令调用次数不多但单次耗时极高或者某个简单命令调用量巨大导致总耗时占比高都能从这里看出来。info latencystats更进一步给出各命令延迟的百分位分布如 p50、p99、p999适合分析尾延迟。平均值会掩盖长尾百分位才能反映真实用户体验。如果你的业务对 p99 敏感这段比commandstats的平均值更有参考价值。3.5 replication 与 cpu主从健康与算力去向info replication里role告诉你当前是主还是从connected_slaves是从库数量每个从库的offset和主库的master_repl_offset对比差值就是从库延迟的字节数。延迟持续增大说明从库同步跟不上可能是网络带宽、从库负载或主库写入太猛。master_link_status为 down 时表示主从连接断了这是必须立刻处理的信号。info cpu这段字段少但信息密度高used_cpu_sys是内核态消耗used_cpu_user是用户态消耗used_cpu_sys_children和used_cpu_user_children是后台子进程消耗。如果used_cpu_sys异常高可能是系统调用频繁或网络 IO 压力大如果used_cpu_user高多半是命令计算密集。把 CPU 消耗和commandstats对照能进一步确认是哪个命令在吃算力。4. 实操排查流程从 info 到定位问题的完整路径4.1 第一步建立基线别等出事才看排查的前提是知道正常长什么样。我的做法是在实例稳定运行一段时间后采集一次各段的基准值存档包括连接数区间、内存水位、命中率、命令耗时分布等。有了基线异常时一对比就能看出偏离。比如平时connected_clients在 200 左右突然涨到 800即使没到上限也值得警惕可能是连接泄漏的前兆。采集基线时建议用指定段而不是全量脚本里按段解析成结构化数据存起来。下面是一个采集思路的伪代码示例展示如何按段取数并提取关键字段# 分别采集关键段避免全量输出带来的解析不稳定 redis-cli info clients clients.txt redis-cli info memory memory.txt redis-cli info stats stats.txt redis-cli info replication replication.txt拿到文本后按行解析键:值即可。这里的关键经验是采集脚本要对字段缺失做容错不同版本字段有增减硬编码字段名一旦缺失就报错会导致整个采集链路中断。我一般会给每个字段设默认值缺失时记录告警而不是直接崩。4.2 第二步按症状选段缩小排查范围不同症状对应不同段这是提效的核心。我整理了一个症状到段的映射实际排障时按这个走基本不会跑偏症状表现优先查看的段重点字段连接超时、拒绝连接clientsconnected_clients、maxclients、blocked_clients内存告警memoryused_memory、mem_fragmentation_ratio、evicted_keys请求变慢、毛刺commandstats、latencystats、persistenceusec_per_call、p99、latest_fork_usec主从数据不一致replicationmaster_repl_offset、从库 offset、master_link_status持久化异常persistencerdb_last_bgsave_status、aof_last_bgrewrite_statusCPU 飙高cpu、commandstatsused_cpu_user、高频高耗时命令缓存命中率下降statskeyspace_hits、keyspace_misses、evicted_keys这张表不是教条实际排查往往是多段联动。比如请求变慢我会先看latencystats确认是哪个命令的尾延迟高再看commandstats确认它的调用量和平均耗时最后看persistence排除 fork 阻塞三步下来基本能定性。4.3 第三步用 commandstats 做命令级归因的实操记录分享一次真实的排查过程细节做了脱敏。某段时间业务反馈偶发超时监控上 QPS 正常、内存正常、连接数正常常规指标全绿。我先拉了info latencystats发现某个读类命令的 p99 明显高于其他命令接着拉info commandstats看到这个命令的usec_per_call是同类命令的好几倍calls也不低。进一步确认是业务方在循环里对这个命令做了大量调用且每次操作的集合规模很大。定位之后处理方式不是去调 Redis 参数而是推动业务侧改调用方式把循环调用改成批量操作减少单次操作的数据规模。改完之后 p99 回落超时消失。这个案例说明info的价值不只是看服务端状态更是把服务端状态翻译成业务侧可行动的问题。如果只盯着内存和连接数这个问题永远定位不到。提示commandstats的统计是累计值重启后会清零。做对比分析时要么在重启后重新建立基线要么用两次采集的差值来计算区间内的真实调用情况直接看累计值容易误判。4.4 第四步把 info 接入日常巡检的落地方式单次排障靠人敲命令没问题但要长期稳定得把info的关键字段接入巡检。我的做法是选一组红线指标做定时检查连接数水位超过 80% 告警、碎片率超过 1.5 告警、命中率低于基线一定比例告警、主从 offset 差值超过阈值告警、持久化状态为 err 立即告警。这些指标不需要全量采集按段取数即可开销可控。巡检脚本里有个细节值得说告警阈值要结合基线动态调整而不是写死。比如连接数上限是 10000但你的基线只有 200那 80% 的 10000 是 8000等真到 8000 早就出事了。更合理的做法是基于基线设相对阈值比如超过基线 3 倍就预警。这个思路是我在被阈值写死导致告警太晚坑过之后改的。5. 常见问题与排查技巧实录5.1 info 输出字段对不上、找不到某段怎么办最常见的问题是我照着资料找某个字段结果输出里没有。原因通常有两个一是版本差异字段是后续版本新增的老版本没有二是段没选对某些段默认不返回必须显式指定。解决办法是先info全量看一眼有哪些段再针对性地info section。如果确认版本支持但字段仍缺失检查是不是该功能没启用比如没开集群就不会有完整的 cluster 段内容。还有一种情况是字段名相似导致看错比如内存相关的字段有好几个前缀相近的单位也不同。我的习惯是看字段时连带看它的单位后缀如_bytes、_usec、_seconds避免把微秒当毫秒、把字节当 KB。5.2 碎片率忽高忽低到底该不该处理碎片率波动是正常的分配器在分配释放过程中本来就会产生碎片。判断要不要处理看两点一是碎片率是否持续高于阈值比如长期在 1.5 以上二是used_memory_rss是否明显高于used_memory且影响了系统内存。如果只是短时波动不用管如果持续偏高且内存吃紧再考虑在低峰期做整理。整理本身有开销别在业务高峰做。5.3 主从延迟看着不大业务却读到旧数据info replication里的 offset 差值小不代表业务读到的就是新数据。如果业务读的是从库而从库同步存在网络往返和本地应用延迟即使 offset 差值很小也可能读到旧值。排查这类问题除了看 offset还要看从库的slave_repl_offset增长是否连续、主库写入是否集中在某些时段。我的经验是对一致性要求高的读别依赖从库对延迟敏感的监控把 offset 差值和业务侧读到的数据版本做交叉验证比单看 offset 更可靠。5.4 常见问题速查表问题现象可能原因排查动作info 里找不到 commandstats该段默认不返回显式执行 info commandstats连接数缓慢上涨不回落连接泄漏或连接池配置不当看 clients 段结合客户端侧连接管理排查内存没满但写入报错淘汰策略为不淘汰且已达上限看 memory 段的 maxmemory 与 policy请求毛刺与持久化时间吻合fork 阻塞主线程看 persistence 段 latest_fork_usec命中率骤降键集中过期或缓存被大量淘汰看 stats 段 expired_keys、evicted_keys主从 offset 差值持续增大从库同步跟不上看 replication 段排查网络与从库负载CPU 用户态偏高计算密集型命令调用过多结合 commandstats 定位高耗时命令5.5 几个我踩过的坑直接抄结论第一个坑曾经用全量info做监控采集某次版本升级后多了一个段解析脚本的正则匹配到了错误字段导致内存告警误报。结论是按段采集、按字段解析别用全量文本做模糊匹配。第二个坑把used_memory当成操作系统实际占用去和机器内存对比结果误判内存充足实际used_memory_rss已经接近物理内存上限。结论是容量评估看 rss分配器视角看 used_memory两者要一起看。第三个坑主从延迟排查只看 offset 差值忽略了从库自身的负载结果从库因为其他任务 CPU 打满同步慢但 offset 差值看起来不大。结论是主从问题要两端一起看别只盯主库指标。第四个坑commandstats的累计值在重启后清零做趋势对比时没注意得出命令调用量骤降的错误结论。结论是统计类字段要区分累计值和区间值重启是重要分界点。6. 把 info 用出价值的几个进阶思路6.1 用 info 做容量规划而不是事后救火容量规划的核心是趋势不是瞬时值。定期采集used_memory、connected_clients、keyspace的键数量画出增长曲线就能预估什么时候需要扩容。我的经验是留出至少 30% 的内存余量应对峰值和碎片别等用到 90% 才动手。键数量的增长也要关注键太多会导致元数据开销上升即使数据量不大也可能内存吃紧。6.2 用 commandstats 反推业务代码的合理性commandstats不只是运维工具开发也能用。定期看自己业务用到的命令的调用量和单次耗时能发现很多代码层面的问题循环里调单条命令、对大集合做全量操作、用了复杂度高的命令却没控制数据规模。这些问题在代码 review 时不一定看得出来但在commandstats里一目了然。我现在的习惯是新业务上线一段时间后主动拉一次commandstats看看自己贡献了哪些命令、耗时占比多少相当于给代码做一次运行时体检。6.3 建立自己的 info 解读清单最后分享一个我一直在用的方法把最常看的字段整理成一张个人清单标注每个字段的正常范围、异常含义、对应动作。清单不用很长十几二十个字段就够覆盖大部分场景。时间久了你会发现排障时根本不需要全量拉取看一眼清单上的几个关键字段问题方向就出来了。这份清单会随着你踩坑不断更新它本身就是你经验的沉淀。我个人在实际操作中的体会是info这个指令的门槛不在会不会敲而在看不看得懂、看不看得准。同样一段输出新手看到的是数字老手看到的是实例的健康画像和潜在风险。把每个字段背后的含义、单位、正常区间、异常信号搞清楚再结合业务场景去解读info才真正从看一眼内存变成诊断整个实例的入口。后续如果你想把这块用得更深可以沿着按段采集做监控—按症状建排查路径—按命令做业务归因这条线继续扩展每一步都能落到具体的脚本和清单上不需要额外的工具就能跑起来。