通过 `INFO` 命令分析 Redis 的内存、CPU、网络与持久化状态

好嘞！各位观众老爷们，晚上好！我是你们的老朋友，江湖人称“Bug终结者”的程序猿老王。今儿个咱们不聊代码，咱们聊聊Redis这个“内存数据库小王子”的心脏健康报告，也就是用 INFO 命令来扒一扒它的内存、CPU、网络和持久化的小秘密。

别觉得 INFO 命令简单，它可是Redis的“体检报告”，能让你对Redis的运行状态了如指掌。咱们今天就来好好解读解读这份报告，看看Redis这小子到底健康不健康。

开场白：Redis，你还好吗？（INFO 命令的概览）

想象一下，Redis就像一个辛勤工作的快递小哥，每天风里来雨里去，处理各种数据包裹。为了保证他能高效工作，我们得定期给他做个体检，看看他有没有什么健康问题。INFO 命令就是这个体检工具。

执行 redis-cli info 命令，你会得到一大段文本，就像一份详细的体检报告。这份报告包含了很多信息，按照功能模块被分成了不同的 sections。下面咱们就来逐一解读这些 sections，看看Redis的各项指标是否正常。

第一部分：内存体检报告（Memory Section）

内存对于Redis来说，就像血液对于人体一样重要。如果内存不足或者使用不当，Redis就会变得迟钝甚至崩溃。所以，内存管理是Redis健康的关键。

INFO memory 命令可以获取内存相关的详细信息。咱们挑几个重要的指标来说说：

• used_memory: 这是Redis实际使用的内存大小（以字节为单位）。这个指标非常重要，如果它持续增长，说明你的数据在不断增加，或者存在内存泄漏的风险。你需要密切关注这个指标，并根据实际情况进行调整。

• used_memory_human: 这个和used_memory一样，只是换成了人类可读的格式，比如 "1.23G" 这种。方便你一眼看出用了多少内存，省得数0了，是不是很贴心？

• used_memory_rss: 这是Redis进程实际占用的物理内存大小（Resident Set Size）。这个值通常会比 used_memory 大，因为包含了Redis进程的额外开销，比如代码、堆栈等。

• used_memory_peak: 这是Redis曾经使用过的最大内存大小。你可以通过这个指标来了解Redis的内存使用峰值，以便更好地评估内存需求。

• used_memory_peak_human: 同上，人类可读版本。

• mem_fragmentation_ratio: 这是一个非常重要的指标，表示内存碎片率。它的计算公式是 used_memory_rss / used_memory。

  • 如果这个值接近1，说明内存碎片很少，内存利用率很高。
  • 如果这个值大于1，说明存在内存碎片，内存利用率较低。值越大，碎片越严重。
  • 如果这个值小于1，说明Redis使用了交换空间（swap），这通常意味着内存不足，性能会受到严重影响。

  想象一下，你的房间里堆满了各种杂物，虽然东西不多，但却占用了大量的空间，这就是内存碎片。Redis的内存碎片会导致内存利用率下降，甚至引发性能问题。

• maxmemory: 这是Redis配置的最大内存限制。如果Redis使用的内存超过了这个限制，它会根据配置的策略（maxmemory-policy）来删除一些数据，以释放内存。

• maxmemory_human: 同上，人类可读版本。

• maxmemory_policy: 这是Redis使用的内存淘汰策略。常见的策略有：

  • noeviction: 当内存用完时，不删除任何数据，直接报错。这是最严格的策略，可以保证数据的完整性，但也容易导致Redis崩溃。
  • allkeys-lru: 从所有key中，移除最近最少使用的key。
  • volatile-lru: 从设置了过期时间的key中，移除最近最少使用的key。
  • allkeys-random: 从所有key中，随机移除key。
  • volatile-random: 从设置了过期时间的key中，随机移除key。
  • volatile-ttl: 从设置了过期时间的key中，移除剩余时间最短的key。

  选择合适的内存淘汰策略非常重要，它可以保证Redis在内存不足的情况下，依然能够正常运行。

表格：内存指标解读

指标名称	含义	建议
used_memory	Redis实际使用的内存大小	监控趋势，持续增长可能存在问题。
used_memory_rss	Redis进程占用的物理内存大小	与 used_memory 比较，计算内存碎片率。
mem_fragmentation_ratio	内存碎片率 (used_memory_rss / used_memory)	接近1：正常；大于1：存在碎片；小于1：使用了交换空间。
maxmemory	Redis配置的最大内存限制	根据实际需求合理配置，避免内存溢出。
maxmemory_policy	内存淘汰策略	根据业务场景选择合适的策略，保证Redis在内存不足的情况下，依然能够正常运行。

第二部分：CPU负载报告（CPU Section）

CPU是Redis的“大脑”，负责执行各种指令。如果CPU负载过高，Redis的响应速度就会变慢，甚至出现阻塞。

INFO cpu 命令可以获取CPU相关的详细信息。咱们也挑几个重要的指标来说说：

• used_cpu_sys: Redis进程在内核态消耗的CPU时间（以秒为单位）。
• used_cpu_user: Redis进程在用户态消耗的CPU时间（以秒为单位）。
• used_cpu_sys_children: 后台子进程（比如AOF rewrite）在内核态消耗的CPU时间。
• used_cpu_user_children: 后台子进程在用户态消耗的CPU时间。

这些指标可以帮助你了解Redis进程的CPU使用情况。如果 used_cpu_sys 很高，说明Redis在执行一些系统调用，比如读写磁盘或者网络通信。如果 used_cpu_user 很高，说明Redis在执行一些计算密集型的操作，比如排序或者聚合。

如果CPU负载持续过高，你需要分析Redis的慢查询日志，找出导致CPU负载过高的原因，并进行优化。

第三部分：网络通信报告（Network Section）

Redis是一个网络服务，它需要通过网络与客户端进行通信。网络连接的质量直接影响Redis的性能。

INFO stats 命令（注意，不是 INFO network，网络信息在 stats 中）可以获取网络相关的统计信息。咱们挑几个重要的指标来说说：

• total_connections_received: Redis接受的连接总数。
• total_commands_processed: Redis处理的命令总数。
• instantaneous_ops_per_sec: 每秒处理的命令数。这是一个非常重要的指标，反映了Redis的吞吐量。
• rejected_connections: 由于达到最大连接数限制而被拒绝的连接数。如果这个值不为0，说明你的Redis服务器已经超负荷运转了，需要增加最大连接数限制或者优化客户端连接管理。
• connected_clients: 当前连接的客户端数量。

通过这些指标，你可以了解Redis的网络连接情况和吞吐量。如果 instantaneous_ops_per_sec 持续下降，说明Redis的性能可能出现了问题。你需要检查网络连接是否正常，或者Redis是否被阻塞。

第四部分：持久化状态报告（Persistence Section）

Redis提供了两种持久化方式：RDB（快照）和AOF（Append Only File）。持久化可以保证Redis在发生故障时，数据不会丢失。

INFO persistence 命令可以获取持久化相关的详细信息。咱们挑几个重要的指标来说说：

• rdb_bgsave_in_progress: 是否正在进行RDB后台保存操作。
• rdb_last_save_time: 上次成功保存RDB文件的时间戳。
• rdb_last_bgsave_status: 上次RDB后台保存操作的状态（ok 或 err）。
• aof_enabled: AOF是否启用。
• aof_rewrite_in_progress: 是否正在进行AOF rewrite操作。
• aof_last_rewrite_time_sec: 上次AOF rewrite操作耗时（秒）。
• aof_last_bgrewrite_status: 上次AOF rewrite操作的状态（ok 或 err）。
• aof_pending_rewrite: 是否有AOF rewrite操作正在等待执行。

通过这些指标，你可以了解Redis的持久化状态。如果 rdb_bgsave_in_progress 或 aof_rewrite_in_progress 持续为 yes，说明Redis正在进行持久化操作，可能会影响性能。如果 rdb_last_bgsave_status 或 aof_last_bgrewrite_status 为 err，说明持久化操作失败了，你需要检查日志，找出原因。

表格：持久化指标解读

指标名称	含义	建议
rdb_bgsave_in_progress	是否正在进行RDB后台保存操作	避免在高负载时进行RDB备份，以免影响性能。
rdb_last_save_time	上次成功保存RDB文件的时间戳	定期检查，确保RDB备份正常进行。
aof_enabled	AOF是否启用	根据数据重要性选择是否启用AOF。
aof_rewrite_in_progress	是否正在进行AOF rewrite操作	AOF rewrite会消耗大量资源，避免频繁执行。
aof_last_bgrewrite_status	上次AOF rewrite操作的状态（ok 或 err）	检查错误日志，确保AOF rewrite正常进行。

第五部分：其他重要指标（Stats & Server Section）

除了以上几个重要的 sections，INFO 命令还包含一些其他有用的指标，比如：

• uptime_in_seconds: Redis服务器的运行时间（以秒为单位）。
• redis_version: Redis服务器的版本号。
• connected_clients: 当前连接的客户端数量。
• used_memory_lua: Lua脚本使用的内存大小。
• keyspace_hits: 键命中次数。
• keyspace_misses: 键未命中次数。

keyspace_hits 和 keyspace_misses 可以帮助你了解Redis的缓存命中率。缓存命中率越高，说明Redis的性能越好。你可以通过优化数据结构或者调整缓存策略来提高缓存命中率。

实战演练：如何利用 INFO 命令诊断问题

理论讲了一大堆，咱们来点实际的。假设你发现你的Redis服务器突然变慢了，你应该如何利用 INFO 命令来诊断问题呢？

1. 首先，执行 redis-cli info 命令，获取Redis的完整体检报告。
2. 查看 memory section，看看 used_memory 是否接近 maxmemory。 如果是，说明Redis内存不足，需要考虑增加内存或者调整内存淘汰策略。
3. 查看 memory section，看看 mem_fragmentation_ratio 是否过高。 如果是，说明存在内存碎片，需要考虑重启Redis或者进行内存整理。
4. 查看 cpu section，看看 used_cpu_sys 和 used_cpu_user 是否过高。 如果是，说明CPU负载过高，需要分析慢查询日志，找出导致CPU负载过高的原因，并进行优化。
5. 查看 stats section，看看 instantaneous_ops_per_sec 是否下降。 如果是，说明Redis的吞吐量下降了，需要检查网络连接是否正常，或者Redis是否被阻塞。
6. 查看 persistence section，看看 rdb_bgsave_in_progress 或 aof_rewrite_in_progress 是否持续为 yes。 如果是，说明Redis正在进行持久化操作，可能会影响性能。
7. 查看 keyspace_hits 和 keyspace_misses，计算缓存命中率。 如果缓存命中率过低，需要优化数据结构或者调整缓存策略。
8. 最后，查看Redis的日志文件，看看是否有错误或者警告信息。

通过以上步骤，你可以逐步排查Redis的性能问题，并找到问题的根源。

总结：INFO 命令，Redis健康的守护神

INFO 命令是Redis运维的必备工具。它可以让你对Redis的运行状态了如指掌，及时发现和解决问题。掌握 INFO 命令的使用方法，就像拥有了一个Redis的“健康监测仪”，可以随时监控Redis的健康状况，保证Redis的稳定运行。

希望今天的分享对大家有所帮助。记住，定期给你的Redis做个体检，让它保持健康，才能更好地为你服务！

好啦，今天的讲座就到这里。下次有机会，咱们再聊聊Redis的其他有趣话题。拜拜！👋