当前位置：首页 > 问答 > 正文

服务器端Redis缓存机制大致了解下，顺便看看服务器上redis的情况啥样

召安青
问答
2026-01-08 03:13:58
9

用户想了解一下服务器端的Redis缓存机制,并且想看看服务器上Redis的实际状况是什么样的，这个需求很常见，就是想对一个技术有个直观的感受，而不是一开始就陷入复杂的理论中，那我们就从最像日常生活的比喻开始，慢慢说清楚。

第一部分：Redis缓存机制像个啥？简单理解

可以把Redis想象成一个大楼前台或者餐厅里那个记忆力超强的领班,假设我们有一个非常庞大的图书馆（这就是我们的主数据库，比如MySQL），每次有读者（也就是我们的应用程序）想找一本书，都得自己跑进巨大的书库里一本一本翻找，虽然最后肯定能找到，但这个过程非常耗时费力，尤其是当很多读者都想找同一本热门书的时候，整个图书馆的效率就会很低。

这时候,我们就在图书馆门口设置了一个聪明的前台（这就是Redis），这个前台有个特点：记忆力特别好，反应超快，当第一个读者来问《三体》这本书在哪里时，前台可能会先跑进书库帮读者找到，然后他不仅把书给了读者，还瞬间记住了“《三体》在A区3排5架”这个信息，当第二个、第三个读者再来问同一本书时，这个前台根本不用再进书库，直接就能脱口而出位置信息，大大节省了大家的时间。

在这个比喻里：

图书馆书库：就是主数据库，数据持久化存储的地方，但直接查询慢。
前台：就是Redis，一个在内存中运行的缓存数据库，读写速度极快。
查询图书：就是应用程序需要获取数据。
前台记住位置：就是把从主数据库查到的数据临时存放在Redis里。
后续的快速回答：就是应用程序下次需要相同数据时，直接从Redis获取，避免了访问慢速的主数据库。

这就是缓存最核心的价值：提升读取速度，降低后端主数据库的压力，这个前台也不是万能的，比如书被挪了位置（主数据库的数据更新了），或者前台记的事情太多了有些忘了（缓存数据过期或被清除），这时候他还是需要重新进书库确认一下，这就引出了缓存机制中一些需要考虑的问题，比如缓存和主数据库的数据一致性如何保证、缓存的数据应该多久失效等。

第二部分：怎么看看服务器上Redis的“身体状况”？

现在我们知道Redis是个能干的前台了,那怎么检查一下我们服务器上的这位“前台”工作状态好不好呢？不需要太专业的命令，通过一些简单的操作就能有个大致的了解。

我们得连接到Redis,通常是在服务器的命令行里，输入 redis-cli 这个命令，就像走进前台办公室跟他对话一样，如果Redis设置了密码，可能还需要输入 auth 你的密码 来通过验证。

连接上去之后,我们可以问它几个简单的问题来了解情况：

“嗨，你还活着吗？”——检查基本状态 输入 ping，如果Redis正常，它会回答 PONG，这是最基础的连通性测试。
“你现在忙不忙？处理了多少事了？”——查看基本统计 输入 info 命令，它会吐出一大堆信息，不用怕，我们只看几个关键点就行。
- 可以输入 info stats 来看统计信息，里面有一行叫 total_commands_processed，这个数字告诉你Redis自启动以来一共处理了多少个命令，数字一直在涨，说明它一直在干活。
- 还有 keyspace_hits 和 keyspace_misses 这两个值很重要。hits 表示多少次查询成功在缓存里找到了数据（前台直接答上来了），misses 表示多少次没找到需要去查主数据库（前台得进书库）。hits 的数量远高于 misses，说明缓存的效果很好，这个前台帮了大忙，我们可以粗略算一下缓存命中率：hits / (hits + misses)，这个比率越高越好。
“你现在记着多少条信息了？”——查看数据量 输入 dbsize，它会告诉你当前数据库里有多少个key（可以理解为有多少条缓存记录），这个数字能让你心里有个数，缓存了多大容量的数据。
“你一共占用了多少内存？”——监控内存使用 输入 info memory，会显示内存相关信息，找 used_memory_human 这一行，它会用像 28M 这种人类容易读的格式告诉你Redis目前使用了多少内存，内存是Redis最重要的资源，如果占用过高就要警惕了。
“让我看看你都记了些啥？”——查看具体内容（谨慎使用） 如果想看看缓存里到底存了哪些东西，可以用 keys * 命令，它会列出所有的key，但是在生产环境要非常小心地使用这个命令，因为如果key非常多，这个命令可能会暂时阻塞Redis，影响服务，通常我们只是偶尔用于调试，或者用 keys some_pattern* 来模糊查找特定的key。