Redis info那些你可能没注意但特别有用的运维小秘密详细说说

很多人用Redis的INFO命令，可能就只看个used_memory（用了多少内存）和connected_clients（连了多少客户端），然后就关掉了，但其实INFO命令返回的信息里，藏着很多能提前发现问题的“宝贝”，只是它们不太起眼，今天我们就来挖一挖这些秘密。

第一个小秘密：看instantaneous_ops_per_sec不如看evicted_keys（被驱逐的键数）

来源：在INFO命令的Stats区块里。

你肯定知道instantaneous_ops_per_sec，它表示Redis每秒处理多少条命令，这个数字高通常代表服务繁忙，但一个更关键、更能直接反映“痛苦”的指标是evicted_keys，这个数字记录了因为内存不足，Redis被迫删除了多少个键来腾出空间。

如果你的Redis设置了最大内存（maxmemory）并且内存快满了，Redis就会根据你设定的策略（比如LRU）开始淘汰一些键，这时候，evicted_keys的值就会开始上涨。这个数字一旦开始动，就是一个明确的警报，它告诉你：你的内存已经不够用了，数据库正在“忍痛割爱”地删除数据，这可能会影响到你的业务逻辑（比如明明没删的数据却读不到了），相比之下，ops_per_sec高可能只是业务繁忙，而evicted_keys高则意味着业务可能正在受损。

第二个小秘密：keyspace_hits和keyspace_misses（键空间命中与未命中）算出的命中率

来源：同样在INFO命令的Stats区块里。

这两个数字单独看没什么意义,但把它们放在一起计算一下，就非常有用了，公式很简单：命中率 = keyspace_hits / (keyspace_hits + keyspace_misses)。

这个命中率是判断你的缓存是否健康的核心指标,这个比率应该非常高，比如95%甚至99%以上，如果命中率很低，比如掉到了80%以下，那就说明很多请求都没有从Redis里拿到数据，而是直接去查后端的数据库（比如MySQL）了，这会给数据库带来巨大压力，导致整个系统变慢，你可能需要检查一下：是不是缓存的数据结构设计不合理？或者是不是缓存Key的过期时间设得太短了？

第三个小秘密：master_link_status（主从链接状态）

来源：在INFO命令的Replication区块里，但只有从库（Slave）上才有这个信息。

当你搭建了Redis主从复制时,怎么快速知道从库和主库的连接是否正常呢？登录到从库服务器，执行INFO replication，找到master_link_status这一行，如果它的值是up，那就表示主从之间的连接是通畅的，同步是正常的，如果它变成了down，那就坏事了，说明从库已经和主库失联了，这时候你就得赶紧排查网络问题或者主库是否宕机了，这是一个非常直接的状态检查，比去看日志要快得多。

第四个小秘密：aof_last_bgrewrite_status和rdb_last_bgsave_status（上次持久化状态）

来源：分别在INFO命令的Persistence区块里。

Redis有两种主要的持久化方式：RDB（快照）和AOF（日志），它们都会在后台执行（bgsave或bgrewriteaof），问题是，你怎么知道上次后台保存数据是成功还是失败了呢？答案就藏在这两个字段里。

正常情况下,它们的值都应该是ok，如果哪天你发现其中一个变成了err，那就意味着上一次的持久化操作失败了，你的数据可能没有成功地写入磁盘，这是一个非常严重的隐患，因为一旦Redis宕机，你可能会丢失更多的数据，定期检查这两个状态，能让你及时发现问题，并手动触发一次持久化或者重启服务来修复。

第五个小秘密：blocked_clients（被阻塞的客户端）

来源：在INFO命令的Clients区块里。

这个数字表示有多少个客户端正在因为执行阻塞命令（比如BLPOP、BRPOP或者因为事务）而被卡住等待，在正常情况下，这个数字应该是0。

如果blocked_clients持续大于0，甚至越来越多，你就需要警惕了，这可能意味着你的某个消费者处理消息太慢，或者遇到了死锁之类的问题，大量的阻塞客户端会消耗Redis的资源，并可能影响其他正常命令的执行。

第六个小秘密：used_memory_rss和used_memory的比值（内存碎片率）

来源：used_memory_rss和used_memory都在INFO命令的Memory区块里。

used_memory是Redis实际存储数据占用的内存。used_memory_rss是操作系统告诉你的Redis进程总共占用了多少物理内存，由于内存分配器的机制，used_memory_rss通常会比used_memory大一些，这个比值就是内存碎片率。

一个健康的碎片率通常在1.0到1.5之间，如果这个比值超过了1.5，甚至更高，说明内存碎片化很严重了，这会导致Redis虽然看起来还有空闲内存，但却无法分配出连续的空间来存储新的大Key，从而可能触发Key的驱逐（evicted_keys上涨），如果碎片率太高，你可能需要考虑重启Redis服务，或者检查是否有大量删除大Key的操作。

下次再运行INFO命令时，别只看一眼内存和客户端数就关掉，多花几十秒钟，扫一眼上面提到的这几个“小秘密”，你就能对Redis的健康状况有一个更深入、更前瞻的了解，很多潜在的问题在酿成大祸之前就能被你发现。