Redis查询突然卡顿是咋回事，性能到底哪里掉链子了？

Redis突然变慢，感觉像开车时猛地踩了一脚刹车，这事儿确实让人头疼，它不是无缘无故发生的，背后总有些原因，咱们就抛开那些难懂的专业术语，像唠家常一样,把可能掉链子的地方一个个揪出来。

你得先确定这个“卡顿”是全局性的还是个别现象，一个很简单的判断方法是：是所有的业务功能都变慢了，并且慢的时间点都差不多？还是只有某个特定的功能或某个用户在喊慢？

如果是个别现象，那问题可能出在应用程序或者网络链路的某个环节，不一定是Redis本身的锅，但如果是全局性的、大家同时感觉卡，那Redis就很有嫌疑了,我们就重点说说Redis自身可能出问题的几个方面。

第一，最可疑的“邻居”捣乱：操作系统和硬件。

很多时候，Redis觉得自己很委屈，因为问题根本不是出在它自己的代码上，而是它所在的“房子”——也就是服务器——出了问题。

• CPU突然被抢： Redis是单线程工作的（指处理命令的核心模块），它非常依赖CPU资源，如果服务器上突然来了一个“霸道”的进程，比如一个复杂的计算任务或者日志备份脚本，一下子把CPU资源占满了，Redis自然就没法及时处理你的命令了，卡顿就发生了，这就像你在一条单车道开车，前面突然有辆车慢吞吞地挡着，你只能干着急。（来源：Redis官方文档对单线程模型的说明）
• 内存不够，系统开始“折腾”： 这是非常常见的一个坑，Redis的所有数据都放在内存里，如果你的物理内存快用完了，操作系统的“内存管理器”就会开始干活，它会把内存中一些暂时不用的数据写到硬盘上一个叫“交换空间”的地方去，这个过程叫交换，硬盘的速度比内存慢成千上万倍，一旦Redis的某些关键数据被换到了硬盘上，下次需要读取时，系统就得去硬盘里翻找，这个延迟就非常恐怖了，必然导致所有请求都变慢，你可以检查一下服务器有没有发生交换。（来源：众多运维实践中的常见问题总结）
• 硬盘虽然不存数据，但日志可能是个负担： 虽然Redis数据在内存，但如果你开启了持久化（比如AOF日志），它还是会写硬盘的，如果这个硬盘是普通的机械硬盘，速度本身就很慢，当Redis需要做AOF重写（可以理解为日志压缩整理），或者只是单纯写AOF日志时，如果磁盘IO压力太大（比如和其他磁盘读写密集型服务部署在一起），写日志的操作就会被阻塞，进而拖慢处理命令的速度。（来源：Redis持久化机制相关文档）

第二，Redis自己“肚子”里的问题：内部操作和数据结构。

排除了外部环境，就得看看Redis自己是不是在“作妖”。

• 持久化操作的“大扫除”时刻： 上面提到了AOF重写，还有生成RDB快照（给内存拍个照存到硬盘），这两个都是重量级操作，尤其是生成RDB快照，为了保持数据一致性，Redis会使用操作系统的“写时复制”机制，当内存数据量很大时（比如20GB），这个fork操作本身可能会阻塞主线程长达数百毫秒甚至秒级，在这期间，Redis是无法响应任何请求的，虽然这是正常行为，但如果频率太高或者发生在业务高峰，用户感知就是一次明显的卡顿。（来源：Redis持久化机制相关文档）
• 遇到了“猪队友”命令： Redis绝大多数命令都很快，但有几个是著名的“慢操作”，比如在没有索引的情况下，对一个包含百万个元素的集合执行KEYS *命令，或者用HGETALL获取一个特别大的哈希表的所有字段，这些命令会一次性返回大量数据，并且处理耗时与数据量成正比，如果应用程序不小心在线上使用了这些命令，一旦遇到大数据量，就会长时间占用Redis的单线程，导致其他所有命令排队等待，这就是所谓的“慢查询”。（来源：Redis命令官方文档中对复杂度的标注）
• 内存碎片化严重： 你可以把Redis的内存想象成一个仓库，随着数据频繁地增删改，仓库里会留下很多零零碎碎的空隙，虽然Redis有自己整理碎片的能力，但有时候碎片率会很高，这样一来，当你需要存入一个比较大的数据时，可能找不到一块完整的足够大的空地，Redis就不得不花时间进行内存整理和搬运，这个过程也会引起延迟。（来源：Redis内存优化相关讨论）

第三，网络层面的“堵车”。

Redis本身健步如飞，但数据在来的路上或回去的路上“堵车”了。

• 连接数爆满： Redis能同时处理的连接数是有限的，如果应用程序没有正确管理连接（比如忘了关闭连接导致泄漏），或者突然遭遇超高并发，连接数达到上限，新的连接请求就会被拒绝,已有的连接也可能因为资源竞争而变慢。
• 网络带宽打满： 如果你的Redis存储了大量的大键（比如几百KB甚至几MB的字符串），在频繁读取时，可能会把服务器的网络带宽占满，这就像一条高速公路突然涌入了太多大货车，所有车辆的速度都不得不降下来，数据包在网络上传输的时间变长了,整体响应时间自然就增加了。

怎么着手排查？

当卡顿发生时，不要慌,可以按这个顺序快速看一眼：

1. 看服务器监控： 首先检查CPU使用率、内存使用情况（特别是swap使用量）、磁盘IO状态,这能快速判断是不是环境问题。
2. 用Redis自带命令： 使用redis-cli连接后，执行INFO命令看整体状态，更关键的是，使用SLOWLOG GET命令，这是Redis内置的慢查询日志，它会直接告诉你最近是哪些命令执行得慢，耗时多少，这是定位“猪队友”命令的最直接证据。
3. 检查客户端： 看看应用服务的日志，有没有连接错误或超时,确认一下有没有不当的大键操作或连接泄漏。

Redis卡顿就像人生病，需要望闻问切，从操作系统这个“大环境”，到Redis内部的“五脏六腑”，再到网络这个“血液循环系统”，一步步排查,总能找到那个掉链子的环节。