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

Redis节点出问题了咋办？教你一步步看故障，别慌，这里有全攻略

水靖荷
问答
2025-12-28 13:19:49
2

综合自多个技术社区和运维经验分享）

兄弟,搞技术的谁没遇到过Redis半夜告警？屏幕一亮，心里咯噔一下，先别慌，深呼吸，慌解决不了问题，有条理地排查才能快速搞定，下面我就用大白话，带你走一遍排查流程，就跟看病一样，先问诊，再检查，最后开药。

第一步：先别乱动，搞清楚症状（现象收集）

接到报警或者自己发现不对劲,第一件事不是立马去重启，重启确实可能暂时解决问题，但根儿没找到，它还会复发，你先得问问：

报警信息是啥？ 是内存满了？还是连接数爆了？或者是响应超时？报警邮件/短信里的每一个字都看清楚。
业务侧有啥反馈？ 是某个功能完全不能用，还是只是变得特别慢？是全体用户都这样，还是部分用户？这能帮你快速判断问题的影响范围。
问题是什么时候开始的？ 最近有没有对服务器、Redis配置或者应用程序做过什么变更？比如是不是刚上线了新功能，或者有没有哪个兄弟手滑改了什么配置，这叫“近期变更调查”，非常重要。

第二步：上手检查，看看Redis到底咋样了（基础检查）

症状大概了解了,现在需要登录到服务器，给Redis做个“体检”。

Redis还活着吗？ 最简单的方法，用 redis-cli 连上去，打个 ping 命令，如果它回你一个 PONG，说明服务进程还在，能响应，如果连不上或者没反应，那可能就是进程挂掉了。
看看系统资源： 打开你的监控工具（比如宝塔面板、云监控、或者简单的 top 命令），重点看三样东西：
- CPU使用率： 是不是一直100%？偶尔高峰正常，持续高位就有问题。
- 内存使用率： 这是Redis的重灾区，看看是不是真的被用满了，Linux系统下可以用 free -h 命令看整体内存，但更关键的是看Redis自己用了多少。
- 网络和磁盘IO： 如果Redis在做持久化（比如生成RDB文件或者AOF重写），磁盘IO可能会很高，这也会拖慢正常请求。

第三步：深入Redis内部，找病根儿（Redis状态分析）

如果Redis进程健在,但性能很差，就需要深入内部看看了。

Redis节点出问题了咋办？教你一步步看故障，别慌，这里有全攻略

信息大全：INFO 命令 这是你的终极武器，在 redis-cli 里输入 INFO，会刷出一大屏信息，别晕，我们挑重点看：
- INFO memory： 重点看 used_memory 和 used_memory_rss，简单理解，used_memory 是Redis自己认为用了多少内存，used_memory_rss 是操作系统分配给它的实际物理内存，如果rss远大于used_memory，说明内存碎片有点严重了。
- INFO stats： 看看 keyspace_hits 和 keyspace_misses，这代表缓存命中和未命中的次数，如果misses非常高，可能你的缓存策略有问题，或者有大量不存在的key被访问（比如恶意攻击）。
- INFO persistence： 如果发现Redis突然变慢，看看这里的 last_fork_usec，这个值如果很大，说明上次做RDB持久化fork子进程时耗时很长，这可能就是当时服务卡顿的元凶。
- INFO replication： 如果你是主从架构，一定要看这个！检查 role 看它自己是主库还是从库，master_link_status 如果是从库，要看它和主库的连接状态是不是 up，如果变成 down 了，那从库的数据就是旧的，会出大问题。
慢查询日志： Redis可以记录执行时间超过设定阈值的命令，用 SLOWLOG GET 命令看看最近有哪些慢查询，说不定你会发现某个同事写了个 KEYS * 这种超级耗时的命令在生产环境跑，拖累了整个Redis。
看看有哪些“大Key”： 如果一个Key对应的Value特别大（比如好几MB），读写它都会很耗时，还可能引起网络阻塞，虽然没有直接命令能列出所有大Key，但可以用 redis-cli --bigkeys 这个工具来扫描个大概（生产环境慎用，会影响性能），或者用 DEBUG OBJECT key名 来查看某个特定key的大小。

第四步：对症下药，常见问题速查手册

根据上面的检查,你大概能定位到问题了，下面是一些常见问题的应对思路：

Redis节点出问题了咋办？教你一步步看故障，别慌，这里有全攻略

问题：内存满了。
- 药方：
  1. 检查是否设置了过期时间（TTL），很多key可能应该过期但没设置。
  2. 检查内存淘汰策略（maxmemory-policy），如果是 noeviction（不淘汰），那满了就写不进去了，可以根据业务情况改成 allkeys-lru 或 volatile-lru 等。
  3. 如果是因为确实有超大Key,考虑能不能拆分这个Key。
  4. 最后一招：扩容，加内存。
问题：CPU占用率高，响应慢。
- 药方：
  1. 检查慢查询日志,优化慢查询命令。
  2. 检查是否有大量键过期,Redis的过期清理机制在特定情况下也会引起延迟。
  3. 看看是不是有复杂的O(N)命令（HGETALL 一个字段很多的Hash）被频繁调用。
问题：连接数爆了。
- 药方：
  1. 检查应用代码,是不是有地方建立了连接没关闭，导致了连接泄漏。
  2. 适当调大 maxclients 参数（但要确保你服务器资源够用）。
  3. 检查是否有恶意攻击,比如短时间大量连接。
问题：主从同步失败。
- 药方：
  1. 检查网络,主从节点之间能不能通？
  2. 查看主从节点的日志,通常会有详细的错误信息。
  3. 如果数据差得太多,有时候重启同步（在从节点上执行 SLAVEOF 命令重新指定主节点）比等它自己追更快。