Redis的INFO命令是排查性能问题和容量规划时最常用的入口之一。执行INFO后，Redis会返回以井号开头的多个区块，每个区块内是成对的键值数据，例如 used_memory:1048576 就代表当前内存占用。相比MONITOR命令会逐条打印客户端请求，INFO读取的是服务端内部维护的计数器快照，开销极低，适合在线上频繁执行。
一、INFO命令的输出结构与常用参数
完整执行 redis-cli info 会得到十几个以井号开头的区块，例如 Server、Clients、Memory、Persistence、Stats、Replication、CPU、Cluster、Keyspace。每个区块由多个键值对组成，键名采用小写英文字符加下划线，值则根据指标类型可能是整数、浮点数或字符串。这种设计让INFO命令既适合人工快速查看，也方便脚本通过管道解析。
如果只想查看某个区块，可以使用 info section 语法，例如 info memory 只返回内存相关指标。Redis 7之前的版本也支持同时指定多个区块，用空格分隔，如 info memory replication。需要注意，不同Redis版本返回的指标数量会略有差异，升级后如果有依赖某些字段的监控脚本，应当逐个确认字段是否仍然存在。
INFO命令的参数中，default 表示返回默认区块集合，all 表示返回全部区块。很多自动化运维工具会定期执行 redis-cli info all 并全量存储，便于事后回溯。下面是一段精简后的输出结构示例，实际输出内容更多。
$ redis-cli info server # Server redis_version:7.0.5 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:abcdef123456 redis_mode:standalone os:Linux 5.15.0-67-generic x86_64 arch_bits:64 process_id:2048 tcp_port:6379 uptime_in_seconds:86400 uptime_in_days:1
从服务器区块可以看到进程号、监听端口、运行时长和操作系统信息。运行时长对于判断实例是否刚刚重启过非常直观，如果 uptime_in_seconds 很小，但业务请求量很高，需要警惕预热阶段或意外重启带来的缓存击穿。
二、内存相关指标与碎片率判断
内存问题在Redis运维中最常见，而INFO Memory区块提供了判断内存健康度的关键数据。used_memory 是Redis分配器实际分配给数据的总字节数，used_memory_rss 是操作系统视角的常驻内存大小，二者并不相同。当 used_memory_rss 明显大于 used_memory 时，说明存在内存碎片；如果 used_memory_rss 小于 used_memory，通常表示部分数据被换出到了交换分区，性能会受到严重影响。
判断碎片最直接的指标是 mem_fragmentation_ratio，它的计算方式为 used_memory_rss 除以 used_memory。正常情况下该值在1到1.5之间，超过1.5代表碎片较多，可以考虑通过 CONFIG SET activedefrag yes 开启主动碎片整理。如果该值长期低于1，则需要检查系统是否启用了swap，或者是否设置了过大的 maxmemory 导致内存压力。
$ redis-cli info memory # Memory used_memory:123456 used_memory_human:120.56K used_memory_rss:200704 used_memory_peak:1572864 mem_fragmentation_ratio:1.63 maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction mem_allocator:jemalloc-5.1.0
上面示例中碎片率为1.63，说明已经存在一定程度的内存浪费。如果实例设置了 maxmemory，还需要结合 maxmemory_policy 观察是否发生键淘汰。生产环境不建议使用 noeviction 策略，因为写入请求会直接报错，可能影响业务。常见的策略包括 allkeys-lru 和 volatile-lru，具体选择取决于缓存数据和持久数据的比例。
另外，used_memory_peak 记录了历史内存使用的最大值，配合当前 used_memory 可以判断内存增长是否已经见顶。如果峰值持续上升，说明缓存写入量在增加，需要提前规划扩容或优化键的过期时间。
三、持久化与复制状态指标
持久化区块是判断数据安全风险的核心区域。RDB相关指标中，rdb_last_bgsave_status 表示最近一次后台保存快照的状态，值为 ok 表示成功，值为 err 表示失败。如果该指标长期为 err，需要查看 rdb_last_bgsave_time_sec 和Redis日志，确认是否因为内存不足或磁盘写入故障导致。
AOF相关指标同样重要。aof_enabled 表示AOF是否开启，aof_last_write_status 表示最近一次AOF缓冲写入磁盘的状态。AOF重写通过 aof_rewrite_in_progress 反映，值为1表示正在重写，0表示空闲。如果重写频繁发生，说明AOF文件增长过快，可能存在大量重复写命令或过期键未及时清理。
复制区块用于判断主从节点的同步健康度。role 字段说明当前实例是 master 还是 slave。在主节点上，connected_slaves 表示在线从库数量；在从节点上，master_link_status 表示与主库的连接是否正常。master_last_io_seconds_ago 是从库与主库最近一次通信的间隔秒数，如果该值持续大于5秒，需要警惕主从链路延迟。
$ redis-cli info replication # Replication role:slave master_host:192.168.0.1 master_port:6379 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 slave_repl_offset:123456 master_repl_offset:123456
上面示例中，从库的 master_link_status 为 up，且 slave_repl_offset 与 master_repl_offset 相等，说明复制进度完全一致，没有积压。如果偏移量差值持续增大，说明从库追不上主库的写入速度，需要排查从库性能或网络带宽。
四、基于INFO的监控告警指标清单
把INFO命令应用于日常监控时，不能把所有指标都纳入告警，否则会出现大量无效通知。建议将指标分为实时告警和趋势分析两类。实时告警关注那些一旦异常就会立刻影响业务可用性的指标，例如 rdb_last_bgsave_status 为 err、aof_last_write_status 为 err、master_link_status 为 down、mem_fragmentation_ratio 超过2、connected_clients 接近配置上限等。
趋势分析则适合观察长期变化规律，例如 total_net_input_bytes 和 total_net_output_bytes 可以反映带宽压力，keyspace_hits 与 keyspace_misses 可以计算缓存命中率。缓存命中率计算公式为 keyspace_hits / (keyspace_hits + keyspace_misses)，通常建议保持在90%以上。如果命中率突然下降，往往意味着业务访问模式发生变化，大量未命中的键直接访问了后端数据库。
$ redis-cli info stats | grep keyspace_ keyspace_hits:1000 keyspace_misses:20 $ redis-cli info stats | grep total_net total_net_input_bytes:987654 total_net_output_bytes:1234567
除了上述指标，CPU区块中的 used_cpu_sys 和 used_cpu_user 记录了Redis进程消耗的CPU时间。如果 used_cpu_sys 占比较高，说明内核态开销大，可能与频繁的网络中断或内存分配有关；如果 used_cpu_user 占比较高，通常说明Redis执行了过多复杂命令或慢查询。结合 instantaneous_ops_per_sec 与 total_commands_processed，可以区分瞬时压力与长期负载。
最后需要记住，INFO命令返回的是采样时刻的快照数据，有些指标如 instantaneous_ops_per_sec 只是短时间内的估计值，单次查看意义有限，连续多次采集并观察趋势才能准确判断实例运行状态。把INFO和慢查询日志、客户端列表结合起来，可以更完整地还原一次性能问题的发生过程。
Redis INFO命令内存碎片率持久化状态修改时间：2026-08-20 13:21:24