Redis INFO 命令：打开潘多拉的魔盒，窥探 Redis 的灵魂！ (或者，如何成为 Redis 侦探)
大家好，我是你们的老朋友，一个沉迷于代码海洋的老水手。今天，我们要一起扬帆起航，探索 Redis 这片广袤大陆上一个极其重要的工具——INFO 命令。
别看 INFO 命令只有短短几个字母，它可是 Redis 世界里的“瑞士军刀”，是诊断 Redis 实例健康状况的“听诊器”，是深入了解 Redis 内部运作机制的“X光片”。毫不夸张地说，掌握 INFO 命令，就等于拥有了洞察 Redis 灵魂的能力！
想象一下，你是一位经验丰富的侦探，面对一个神秘的案件——Redis 性能突然下降，连接时断时续，数据神秘失踪…… 你需要什么？当然不是靠瞎猜！你需要线索，需要证据，需要真相！ 而 INFO 命令，就是你手中的放大镜，帮你从蛛丝马迹中找到真凶。
准备好了吗？ 让我们一起打开这个“潘多拉的魔盒”，看看里面藏着什么秘密！
一、 INFO 命令： 简单的命令，强大的力量
INFO 命令的语法非常简单：
INFO [section]其中 section 是可选参数，用于指定要查询的信息类别。如果不指定 section，则返回所有信息。
敲黑板！重点来了！ 这些 section 可不是随便写的，它们代表了 Redis 实例的不同方面，就像人体的各个器官，每个都承载着重要的功能。 常见的 section 包括：
server: 关于 Redis 服务器的一般信息，比如版本号、操作系统、运行时间等等。clients: 关于客户端连接的信息，比如连接数、阻塞客户端数等等。memory: 关于内存使用情况的信息，比如已用内存、峰值内存等等。persistence: 关于持久化配置和状态的信息，比如 RDB 和 AOF 的配置、最近一次保存时间等等。stats: 关于服务器的统计信息，比如查询次数、命中率等等。replication: 关于主从复制的信息，比如角色、主节点地址等等。cpu: 关于 CPU 使用情况的信息。commandstats: 关于命令执行统计的信息，比如每个命令的调用次数、平均执行时间等等。cluster: 关于 Redis 集群的信息。keyspace: 关于数据库的信息，比如每个数据库的键的数量、过期键的数量等等。errorstats: 关于错误命令统计的信息。modules: 关于已加载模块的信息。all: 返回所有信息 (默认选项)。default: 返回默认信息，与不指定section相同。
看到这么多 section，你是不是有点眼花缭乱了？ 别担心，我们接下来会逐一分析，让你对每个 section 的作用了如指掌。
二、 深入剖析 INFO 命令的各个 section
好了，现在让我们开始解剖 Redis，看看每个 section 里面都藏着什么宝贝。
1. server section： Redis 的“身份证”
server section 包含了 Redis 服务器的基本信息，就像一个人的身份证一样，可以让你快速了解 Redis 的身份。
| 字段名 | 含义 | 例子 |
|---|---|---|
redis_version |
Redis 服务器版本 | 7.0.5 |
redis_git_sha1 |
Redis Git SHA1 提交哈希值 | 00000000 |
redis_git_dirty |
Redis Git dirty flag，如果 Redis 是从一个未提交状态构建的，则为 1，否则为 0 | 0 |
redis_build_id |
Redis 构建 ID | 0000000000000000 |
redis_mode |
Redis 运行模式，可以是 standalone 或 cluster |
standalone |
os |
运行 Redis 服务器的操作系统 | Linux 5.15.0-69-generic x86_64 |
arch_bits |
架构（32 或 64 位） | 64 |
multiplexing_api |
Redis 使用的事件循环机制 | epoll |
atomicvar_api |
Redis 使用的原子变量 API | atomic-builtin |
gcc_version |
用于编译 Redis 的 GCC 版本 | 11.3.0 |
process_id |
Redis 服务器进程 ID | 1234 |
process_supervision |
进程管理程序，例如 systemd 或 supervisord | no-supervision |
tcp_port |
Redis 监听的 TCP 端口 | 6379 |
server_time_usec |
服务器当前时间，以 Unix 时间戳（微秒）表示 | 1678886400000000 |
uptime_in_seconds |
Redis 服务器运行的总秒数 | 3600 |
uptime_in_days |
Redis 服务器运行的总天数 | 1 |
hz |
Redis 服务器每秒执行的任务数 | 10 |
configured_hz |
Redis 配置的每秒执行的任务数 | 10 |
lru_clock |
Redis LRU 时钟，用于 LRU 淘汰算法 | 12345678 |
executable |
Redis 服务器可执行文件的路径 | /usr/local/bin/redis-server |
config_file |
Redis 配置文件路径 | /etc/redis/redis.conf |
io_threads_active |
当前活跃的 IO 线程数 | 1 |
通过 server section，你可以快速了解 Redis 的版本、操作系统、运行时间等信息，这些信息对于诊断问题和进行版本升级都非常重要。
2. clients section： 了解客户端连接情况
clients section 提供了关于客户端连接的信息，比如连接数、阻塞客户端数等等。
| 字段名 | 含义 | 例子 |
|---|---|---|
connected_clients |
已连接客户端的数量（不包括通过复制连接的客户端） | 10 |
cluster_connections |
已连接到集群的客户端的数量 | 0 |
maxclients |
Redis 服务器可以处理的最大客户端连接数 | 10000 |
client_recent_max_input_buffer |
最近连接客户端的最大输入缓冲区 | 2048 |
client_recent_max_output_buffer |
最近连接客户端的最大输出缓冲区 | 0 |
blocked_clients |
正在等待阻塞命令（例如 BLPOP）的客户端数量 |
0 |
tracking_clients |
正在跟踪服务器端缓存的客户端数量 | 0 |
clients_in_timeout_table |
在超时表中注册的客户端数量 | 0 |
如果 connected_clients 数量过高，可能意味着 Redis 服务器压力过大，需要进行优化。 如果 blocked_clients 数量过高，可能意味着有大量的客户端在等待阻塞命令，需要检查阻塞命令的执行情况。
3. memory section： 关注内存健康
memory section 提供了关于内存使用情况的信息，这是 Redis 性能的关键指标之一。
| 字段名 | 含义 | 例子 |
|---|---|---|
used_memory |
Redis 分配器分配的总内存（以字节为单位） | 1048576 |
used_memory_human |
used_memory 的人类可读格式 |
1.00M |
used_memory_rss |
操作系统分配给 Redis 进程的内存（常驻集大小，以字节为单位） | 2097152 |
used_memory_rss_human |
used_memory_rss 的人类可读格式 |
2.00M |
used_memory_peak |
Redis 峰值内存使用量（以字节为单位） | 1572864 |
used_memory_peak_human |
used_memory_peak 的人类可读格式 |
1.50M |
used_memory_peak_perc |
峰值内存使用量占总内存的百分比 | 150.00% |
used_memory_overhead |
Redis 为了维护数据结构而使用的内存开销（以字节为单位），包括客户端缓冲、查询缓冲、复制积压缓冲区等 | 209715 |
used_memory_startup |
Redis 启动时使用的内存（以字节为单位） | 524288 |
used_memory_dataset |
Redis 数据集大小（以字节为单位），不包括开销 | 838861 |
used_memory_dataset_perc |
数据集大小占总内存的百分比 | 80.00% |
allocator_allocated |
分配器分配的内存（以字节为单位） | 1048576 |
allocator_active |
分配器当前活跃的内存（以字节为单位） | 1572864 |
allocator_resident |
分配器常驻内存（以字节为单位） | 2097152 |
total_system_memory |
系统总内存（以字节为单位） | 8589934592 |
total_system_memory_human |
total_system_memory 的人类可读格式 |
8.00G |
used_memory_lua |
Lua 脚本引擎使用的内存（以字节为单位） | 0 |
used_memory_vm_eval |
VM 评估器使用的内存（以字节为单位） | 0 |
used_memory_scripts_eval |
脚本评估器使用的内存（以字节为单位） | 0 |
number_of_cached_scripts |
缓存的脚本数量 | 0 |
maxmemory |
Redis 配置的最大内存限制（以字节为单位） | 0 |
maxmemory_human |
maxmemory 的人类可读格式 |
0B |
maxmemory_policy |
Redis 使用的内存淘汰策略 | noeviction |
allocator_frag_ratio |
分配器碎片率（allocator_active / allocator_allocated） |
1.50 |
allocator_frag_bytes |
分配器碎片字节数（allocator_active - allocator_allocated） |
524288 |
allocator_rss_ratio |
分配器 RSS 比率（allocator_resident / allocator_active） |
1.33 |
allocator_rss_bytes |
分配器 RSS 字节数（allocator_resident - allocator_active） |
524288 |
rss_overhead_ratio |
RSS 开销比率（used_memory_rss / used_memory） |
2.00 |
rss_overhead_bytes |
RSS 开销字节数（used_memory_rss - used_memory） |
1048576 |
mem_fragmentation_ratio |
内存碎片率（used_memory_rss / used_memory） |
2.00 |
mem_fragmentation_bytes |
内存碎片字节数（used_memory_rss - used_memory） |
1048576 |
mem_not_counted_for_replication |
未计入复制的内存（以字节为单位） | 0 |
active_defrag_running |
是否正在运行活跃的碎片整理 | 0 |
lazyfree_pending_objects |
等待 lazyfree 释放的对象数量 | 0 |
lazyfreed_objects |
已经 lazyfree 释放的对象数量 | 0 |
如果 used_memory 超过了 maxmemory，Redis 会根据配置的 maxmemory_policy 进行内存淘汰，这可能会影响性能。 mem_fragmentation_ratio 越高，说明内存碎片越严重，也可能会影响性能。
4. persistence section： 守护数据的安全
persistence section 提供了关于持久化配置和状态的信息，确保你的数据不会因为服务器宕机而丢失。
| 字段名 | 含义 | 例子 |
|---|---|---|
loading |
Redis 是否正在加载 RDB 文件 | 0 |
rdb_changes_since_last_save |
自上次成功保存 RDB 文件以来的更改次数 | 100 |
rdb_bgsave_in_progress |
是否正在进行 RDB 后台保存 | 0 |
rdb_last_save_time |
上次成功保存 RDB 文件的时间戳（Unix 时间戳） | 1678886400 |
rdb_last_bgsave_status |
上次 RDB 后台保存的状态（ok 或 err） |
ok |
rdb_last_bgsave_time_sec |
上次 RDB 后台保存所用的时间（秒） | 1 |
rdb_current_bgsave_time_sec |
当前 RDB 后台保存所用的时间（秒），如果正在进行 | 0 |
rdb_last_cow_size |
上次 RDB 保存期间的写时复制大小（以字节为单位） | 0 |
aof_enabled |
AOF 是否启用 | 1 |
aof_rewrite_in_progress |
是否正在进行 AOF 重写 | 0 |
aof_rewrite_scheduled |
是否安排了 AOF 重写 | 0 |
aof_appendonly_buffer_bytes |
AOF 追加缓冲区的大小（以字节为单位） | 0 |
aof_appendonly_buffer_free |
AOF 追加缓冲区可用的字节数 | 0 |
aof_current_size |
AOF 文件当前大小（以字节为单位） | 1048576 |
aof_base_size |
AOF 重写后的基准大小（以字节为单位） | 1048576 |
aof_pending_rewrite |
是否有挂起的 AOF 重写操作 | 0 |
aof_fd |
AOF 文件的文件描述符 | 5 |
aof_last_rewrite_time_sec |
上次 AOF 重写所用的时间（秒） | 1 |
aof_current_rewrite_time_sec |
当前 AOF 重写所用的时间（秒），如果正在进行 | 0 |
aof_last_bgrewrite_status |
上次 AOF 重写的状态（ok 或 err） |
ok |
aof_last_write_status |
上次 AOF 写入的状态（ok 或 err） |
ok |
aof_last_cow_size |
上次 AOF 重写期间的写时复制大小（以字节为单位） | 0 |
module_fork_in_progress |
是否有模块正在进行 fork 操作 | 0 |
module_fork_pid |
模块 fork 操作的 PID | 0 |
module_fork_last_cow_size |
上次模块 fork 操作期间的写时复制大小（以字节为单位） | 0 |
如果 rdb_bgsave_in_progress 或 aof_rewrite_in_progress 为 1，说明 Redis 正在进行持久化操作，这可能会影响性能。 你可以通过 rdb_last_save_time 和 aof_last_rewrite_time_sec 了解上次持久化操作的时间和耗时，从而评估持久化策略是否合理。
5. stats section： 追踪服务器的脉搏
stats section 提供了关于服务器的统计信息，比如查询次数、命中率等等，可以帮助你了解 Redis 的运行状态。
| 字段名 | 含义 | 例子 |
|---|---|---|
total_connections_received |
Redis 服务器接受的总连接数 | 1000 |
total_commands_processed |
Redis 服务器处理的总命令数 | 10000 |
instantaneous_ops_per_sec |
Redis 服务器每秒处理的命令数（最近 1 秒） | 100 |
instantaneous_input_kbps |
Redis 服务器每秒接收的输入流量（千字节） | 10 |
instantaneous_output_kbps |
Redis 服务器每秒发送的输出流量（千字节） | 20 |
rejected_connections |
由于达到 maxclients 限制而被拒绝的连接数 |
0 |
sync_full |
主从同步期间执行的完全同步次数 | 1 |
sync_partial_ok |
主从同步期间执行的部分同步成功次数 | 10 |
sync_partial_err |
主从同步期间执行的部分同步失败次数 | 0 |
expired_keys |
过期键的总数 | 100 |
evicted_keys |
由于达到内存限制而被淘汰的键的总数 | 10 |
keyspace_hits |
成功的查找键的总数 | 1000 |
keyspace_misses |
未成功的查找键的总数 | 100 |
pubsub_channels |
当前活动发布订阅频道数 | 10 |
pubsub_patterns |
当前活动发布订阅模式数 | 5 |
latest_fork_usec |
最近一次 fork 操作的耗时（微秒） | 10000 |
migrate_cached_sockets |
迁移缓存的套接字数 | 10 |
slave_expires_tracked_keys |
从节点跟踪的过期键数 | 100 |
active_defrag_hits |
活跃碎片整理成功移动的对象数 | 100 |
active_defrag_misses |
活跃碎片整理未能移动的对象数 | 10 |
active_defrag_key_hits |
活跃碎片整理期间键查找的命中数 | 1000 |
active_defrag_key_misses |
活跃碎片整理期间键查找的未命中数 | 100 |
keyspace_hits 和 keyspace_misses 可以用来计算缓存命中率，命中率越高，说明 Redis 的性能越好。 expired_keys 和 evicted_keys 可以用来了解键的过期和淘汰情况，如果数量过多，可能意味着需要调整键的过期策略或增加 Redis 的内存。
6. replication section： 监控主从复制
replication section 提供了关于主从复制的信息，确保你的数据能够安全可靠地复制到多个节点。
| 字段名 | 含义 | 例子 |
|---|---|---|
role |
Redis 实例的角色（master 或 slave） |
master |
connected_slaves |
连接到主节点的从节点数量 | 2 |
slave0:ip |
从节点 0 的 IP 地址 | 192.168.1.100 |
slave0:port |
从节点 0 的端口 | 6379 |
slave0:state |
从节点 0 的状态（online 或 offline） |
online |
slave0:offset |
从节点 0 的复制偏移量 | 12345678 |
slave0:lag |
从节点 0 的延迟（秒） | 0 |
master_replid |
主节点的复制 ID | abcdef1234567890abcdef1234567890 |
master_replid2 |
主节点的第二个复制 ID（用于部分同步） | 00000000000000000000000000000000 |
master_repl_offset |
主节点的复制偏移量 | 12345678 |
second_repl_offset |
第二个复制偏移量 | -1 |
repl_backlog_active |
复制积压缓冲区是否激活 | 1 |
repl_backlog_size |
复制积压缓冲区的大小（字节） | 1048576 |
repl_backlog_first_byte_offset |
复制积压缓冲区的起始偏移量 | 1234567 |
repl_backlog_histlen |
复制积压缓冲区中已存储的数据量（字节） | 1000000 |
如果 role 为 slave，你可以通过 master_host 和 master_port 了解主节点的地址和端口。 你可以通过 slaveX:state 和 slaveX:lag 了解从节点的状态和延迟，如果延迟过高，可能意味着主从复制存在问题。
7. cpu section： 诊断 CPU 瓶颈
cpu section 提供了关于 CPU 使用情况的信息，可以帮助你诊断 CPU 瓶颈。
| 字段名 | 含义 | 例子 |
|---|---|---|
used_cpu_sys |
Redis 服务器使用的系统 CPU 时间（秒） | 10.00 |
used_cpu_user |
Redis 服务器使用的用户 CPU 时间（秒） | 20.00 |
used_cpu_sys_children |
Redis 子进程使用的系统 CPU 时间（秒） | 0.00 |
used_cpu_user_children |
Redis 子进程使用的用户 CPU 时间（秒） | 0.00 |
如果 used_cpu_sys 和 used_cpu_user 较高，可能意味着 Redis 服务器存在 CPU 瓶颈，需要进行优化。
8. commandstats section： 分析命令执行情况
commandstats section 提供了关于命令执行统计的信息，可以帮助你了解每个命令的调用次数、平均执行时间等等。
| 字段名 | 含义 | 例子 |
|---|---|---|
cmdstat_get:calls |
GET 命令的调用次数 |
10000 |
cmdstat_get:usec |
GET 命令的总执行时间（微秒） |
1000000 |
cmdstat_get:usec_per_call |
GET 命令的平均执行时间（微秒） |
100 |
cmdstat_set:calls |
SET 命令的调用次数 |
5000 |
cmdstat_set:usec |
SET 命令的总执行时间（微秒） |
500000 |
cmdstat_set:usec_per_call |
SET 命令的平均执行时间（微秒） |
100 |
通过分析 commandstats section，你可以找到执行时间较长的命令，并进行优化。
9. cluster section： 探索集群的奥秘
cluster section 提供了关于 Redis 集群的信息，只有在 Redis 运行在集群模式下才会显示。
| 字段名 | 含义 | 例子 |
|---|---|---|
cluster_enabled |
集群模式是否启用 (1: 是, 0: 否) | 1 |
cluster_state |
集群状态 (ok: 正常, fail: 失败) | ok |
cluster_slots_assigned |
已分配的槽数量 | 16384 |
cluster_slots_ok |
状态为 OK 的槽数量 | 16384 |
cluster_slots_pfail |
状态为 PFAIL (疑似失败) 的槽数量 | 0 |
cluster_slots_fail |
状态为 FAIL (失败) 的槽数量 | 0 |
cluster_known_nodes |
集群已知节点数量 | 3 |
cluster_size |
集群中至少有一个槽的节点数量 | 3 |
cluster_current_epoch |
集群当前纪元 | 5 |
cluster_my_epoch |
节点当前纪元 | 5 |
cluster_stats_messages_sent |
节点发送的消息统计 (可以使用cluster_stats_messages_sent_ping, cluster_stats_messages_sent_meet 等查看具体消息类型) |
cluster_stats_messages_sent_ping=123,cluster_stats_messages_sent_meet=456 |
cluster_stats_messages_received |
节点接收的消息统计 (可以使用cluster_stats_messages_received_ping, cluster_stats_messages_received_meet 等查看具体消息类型) |
cluster_stats_messages_received_ping=789,cluster_stats_messages_received_meet=012 |
通过 cluster section，你可以了解集群的状态、节点数量、槽分配情况等等，从而监控集群的健康状况。
10. keyspace section： 观察数据库的健康
keyspace section 提供了关于数据库的信息，比如每个数据库的键的数量、过期键的数量等等。
| 字段名 | 含义 | 例子 |
|---|---|---|
db0:keys |
数据库 0 中的键的数量 | 1000 |
db0:expires |
数据库 0 中设置了过期时间的键的数量 | 100 |
db0:avg_ttl |
数据库 0 中键的平均生存时间（毫秒） | 10000 |
db1:keys |
数据库 1 中的键的数量 | 500 |
db1:expires |
数据库 1 中设置了过期时间的键的数量 | 50 |
db1:avg_ttl |
数据库 1 中键的平均生存时间（毫秒） | 5000 |
通过 keyspace section，你可以了解每个数据库的键的数量和过期情况，从而监控数据库的健康状况。
11. errorstats section： 错误命令统计
errorstats section 提供了关于错误命令统计的信息，方便排查客户端的错误。
| 字段名 | 含义 | 例子 |
|---|---|---|
errorstat_WRONGTYPE:count |
WRONGTYPE 错误的计数 |
100 |
errorstat_NOSCRIPT:count |
NOSCRIPT 错误的计数 |
50 |
12. modules section： 已加载模块信息
modules section 提供了关于已加载模块的信息，如果使用了 Redis 模块，可以通过这个 section 查看。
| 字段名 | 含义 | 例子 |
|---|---|---|
module:name |
模块名称 | my_module |
module:ver |
模块版本 | 1.0 |
三、 INFO 命令的实际应用： 案例分析
光说不练假把式，让我们来看几个 INFO 命令的实际应用案例。
案例 1： 诊断 Redis 内存溢出
有一天，你的 Redis 服务器突然变得非常缓慢，甚至开始拒绝连接。 你怀疑是内存溢出导致的。 你可以使用以下命令来查看内存使用情况：
INFO memory如果 used_memory 接近或超过了 maxmemory，并且 evicted_keys 数量很高，那么可以确定是内存溢出导致了性能问题。 你可以采取以下措施来解决问题：
- 增加 Redis 的内存
- 调整
maxmemory_policy，选择更合适的内存淘汰策略 - 优化你的数据结构，减少内存占用
- 分析哪些键占用了大量的内存，并进行优化
案例 2： 诊断 Redis 主从复制延迟
你的 Redis 主从复制环境出现了延迟，从节点的数据更新不及时。 你可以使用以下命令来查看主从复制状态：
INFO replication如果 slaveX:lag 很高，说明从节点的延迟很高。 你可以采取以下措施来解决问题：
- 检查主从节点之间的网络连接是否正常
- 检查主节点的 CPU 和内存负载是否过高
- 调整复制缓冲区的大小
- 考虑使用 Redis 集群来提高数据复制的性能
案例 3： 优化 Redis 命令执行效率
你的 Redis 服务器处理的命令数量很多，但是吞吐量却很低。 你可以使用以下命令来查看命令执行统计信息：
INFO commandstats通过分析 commandstats section，你可以找到执行时间较长的命令，并进行优化。 例如，你可以使用 Redis Pipeline 来批量执行命令，减少网络延迟。 还可以优化你的 Lua 脚本，提高执行效率。
四、 INFO 命令的注意事项
INFO命令会返回大量的信息，可能会对服务器性能产生一定的影响，所以不要频繁地执行INFO命令。INFO命令返回的信息是动态变化的，所以每次执行INFO命令的结果可能都不一样。- 不同的 Redis 版本，
INFO命令返回的信息可能略有不同。
五、 总结： 掌握 INFO 命令，成为 Redis 大师
INFO 命令是 Redis 世界里的一把万能钥匙，它可以帮助你了解 Redis 的内部运作机制，诊断 Redis 的性能问题，优化 Redis 的配置。 掌握 INFO 命令，你就可以像一位经验丰富的医生一样，通过观察 Redis 的“体征”，判断 Redis 的“健康状况”，并开出“药方”，让你的 Redis 服务器始终保持最佳状态。
所以，下次当你遇到 Redis 问题时，不要慌张，不要盲目猜测，拿起你的 INFO 命令，打开这个“潘多拉的魔盒”，让真相浮出水面！ 相信你一定能成为一位真正的 Redis 大师！ 💪
希望这篇文章对你有所帮助。 谢谢大家！ 🙏