Redis Command Info 命令详解：从新手到进阶的实用指南
在 Redis 的众多命令中，INFO 命令或许不是最常被调用的一个，但它却是系统运维和性能排查中不可或缺的“万能钥匙”。无论是你正在调试缓存性能，还是想快速了解当前 Redis 实例的运行状态，INFO 命令都能提供一份详尽的“体检报告”。
这个命令不改变任何数据，也不会对性能造成影响，它只是安静地告诉你：当前 Redis 正在做些什么、用了多少内存、连接了多少客户端、是否开启了持久化……就像一位尽职的系统管家，默默记录着一切。
今天我们就来深入解析这个看似低调却极其实用的命令——Redis Command Info 命令。
什么是 Redis Command Info 命令？
INFO 命令是 Redis 提供的一个只读命令，用于获取 Redis 实例的详细运行信息。它返回一个结构化的文本信息，内容涵盖服务器状态、内存使用、客户端连接、持久化、主从复制、慢查询等多个维度。
你可以把它想象成一台服务器的“系统健康检查工具”。当你打开电脑，看到 CPU 占用率、内存使用情况、网络连接数时，INFO 命令就是 Redis 的“系统监控面板”。
执行方式非常简单：
INFO
这将返回完整的 Redis 信息摘要。如果你只想看某一部分内容，比如内存使用情况，可以指定类别：
INFO memory
或者查看持久化状态：
INFO persistence
✅ 小贴士：
INFO命令支持多个类别，用逗号分隔即可，如INFO memory,clients,persistence。
INFO 命令返回的主要信息分类
INFO 命令返回的信息分为多个逻辑模块，每个模块都对应着 Redis 的不同运行维度。下面我们将逐一拆解这些模块，帮助你真正读懂每一条数据的含义。
服务器信息（server）
这部分告诉你 Redis 实例的基本身份信息，包括版本、运行模式、操作系统、架构等。
redis_version:7.0.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:5c7f8f8e8b9a
redis_mode:standalone
os:Linux 5.15.0-105-generic x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:11.4.0
run_id:5d64e3a2b5a0f3e8c3f2d1a0b1c5d9f7e4a6b8c9
tcp_port:6379
uptime_in_seconds:123456
uptime_in_days:1
redis_version：当前 Redis 版本，比如 7.0.12，建议保持更新以获取安全补丁。redis_mode：运行模式，standalone表示单机模式，cluster表示集群模式。uptime_in_seconds：Redis 已运行的秒数，可用于判断是否异常重启。tcp_port：监听的端口，默认是 6379。
💡 比喻：这就像你查看手机的“设置 - 关于手机”页面，告诉你手机型号、系统版本、运行时长等基本信息。
内存使用情况（memory）
内存是 Redis 的核心资源，INFO memory 是最常被监控的部分。
used_memory:10485760
used_memory_human:10.00M
used_memory_rss:15728640
used_memory_rss_human:15.00M
used_memory_peak:12582912
used_memory_peak_human:12.00M
used_memory_peak_perc:83.33%
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
used_memory：Redis 实际使用的内存字节数。used_memory_rss：操作系统分配给 Redis 进程的物理内存（包括 Redis 本身 + 内存碎片）。used_memory_peak：历史最高内存使用量，可用于判断是否出现内存泄漏。maxmemory：最大内存限制（如果设置了maxmemory配置），0 表示无限制。
🔍 实际建议：
used_memory_rss应该略大于used_memory，但差距不应过大。如果used_memory_rss远大于used_memory，说明内存碎片严重，可考虑重启或开启active-defrag自动碎片整理。
客户端连接信息（clients）
这部分告诉你当前有多少客户端正在连接 Redis。
connected_clients:15
client_recent_max_input_buffer:2048
client_recent_max_output_buffer:2048
blocked_clients:0
connected_clients：当前连接的客户端数量。如果突然飙升，可能是攻击或程序 Bug。blocked_clients：被BLPOP、BRPOP等阻塞命令阻塞的客户端数量。正常情况下应为 0，若持续非零，说明有大量阻塞操作。
⚠️ 警告：如果
connected_clients持续增长且无法释放，可能是连接未正确关闭，建议检查代码中是否调用了close()或quit()。
持久化状态（persistence）
持久化是 Redis 数据安全的保障。INFO persistence 会告诉你 RDB 和 AOF 的工作状态。
rdb_changes_since_last_save:1234
rdb_last_save_time:1712345678
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:1
rdb_current_bgsave_time_sec:-1
aof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
rdb_last_save_time：上次 RDB 快照保存的时间戳（UNIX 时间）。aof_enabled：是否启用 AOF（追加日志）持久化。aof_rewrite_in_progress：AOF 重写是否正在进行。重写是为了压缩日志文件大小。
🛠️ 实用建议：如果
rdb_last_save_time已经很久未更新，说明持久化可能失败了。需要检查磁盘空间、权限或配置。
主从复制状态（replication）
如果你使用 Redis 主从架构，INFO replication 能告诉你主库和从库的同步状态。
role:master
connected_slaves:2
slave0:ip=192.168.1.100,port=6380,state=online,offset=123456,lag=0
slave1:ip=192.168.1.101,port=6380,state=online,offset=123456,lag=0
master_repl_offset:123456
repl_backlog_active:1
repl_backlog_size:104857600
repl_backlog_first_byte_offset:1
repl_backlog_histlen:123456
role：当前节点角色，master或slave。connected_slaves：连接的从库数量。lag：从库与主库的延迟（单位：秒）。如果lag> 0，说明同步有延迟。repl_backlog_histlen：复制积压缓冲区中已使用的字节数。
📌 关键点：
lag持续大于 0 时，说明从库跟不上主库的写入速度，可能影响读写分离的性能。
慢查询日志（slowlog）
慢查询日志是性能调优的重要依据。INFO slowlog 可以告诉你慢查询的统计信息。
slowlog_len:20
slowlog_max_len:128
slowlog_log_slower_than:10000
slowlog_sample_rate:1
slowlog_len：当前慢查询日志的条数。slowlog_log_slower_than：慢查询的阈值（单位：微秒），默认 10000 微秒（10 毫秒）。slowlog_max_len：最大记录条数。
🧩 使用建议：将
slowlog_log_slower_than设置为 5000 微秒（5 毫秒）以下，有助于发现潜在性能瓶颈。
实际案例：如何用 INFO 命令排查问题？
假设你的系统突然变慢，用户反馈“缓存读取延迟高”。我们可以这样一步步排查：
-
查看连接数
执行INFO clients，发现connected_clients从 100 突增至 2000，说明连接未释放。 -
检查内存使用
执行INFO memory，发现used_memory持续增长，used_memory_peak也在上升，怀疑内存泄漏。 -
查看持久化状态
执行INFO persistence，发现rdb_last_save_time已 3 小时未更新，说明 RDB 持久化失败。 -
检查慢查询
执行INFO slowlog，发现slowlog_len超过 100，说明存在大量慢查询。
最终定位问题：程序中未正确关闭 Redis 连接，导致连接池耗尽，同时 AOF 重写失败，造成磁盘满，最终导致性能急剧下降。
✅ 教训：定期监控
INFO返回的关键指标，是预防线上故障的第一道防线。
总结与建议
Redis Command Info 命令虽然简单，但它的价值不可估量。它不仅是调试工具，更是运维的“第一手资料”。通过定期分析 INFO 的输出，你可以：
- 及早发现内存泄漏
- 监控连接池使用情况
- 判断持久化是否正常
- 定位慢查询瓶颈
建议将 INFO 命令集成到你的监控系统中，比如通过脚本定期调用并记录关键字段。你甚至可以写一个简单的 Shell 脚本，自动分析 used_memory 是否超过阈值，lag 是否异常。
🎯 最后提醒：
INFO命令是免费的、无副作用的、高效的。别让它被你忽略。每一次系统异常，都可以从它开始排查。
Redis Command Info 命令，看似不起眼，却是你与 Redis 深度沟通的桥梁。掌握它，就等于掌握了一把打开性能之门的钥匙。