Redis到底卡在哪儿了？聊聊那些让它变慢的瓶颈问题

主要参考自知乎专栏“Redis深度历险”、Redis官方文档以及多位资深运维工程师的经验分享）

Redis被大家称为“快如闪电”的内存数据库，但有时候它也会莫名其妙地变慢，让人头疼，它到底卡在哪儿了呢？其实问题就出在几个关键的地方，我们一个一个来看。

最直观也最常见的问题就是内存不够用了，Redis的数据都放在内存里，这是它快的根本原因，内存是有限的，当内存快被写满时，Redis就要开始“打扫卫生”，清理掉一些数据来腾出空间，这个过程叫做内存淘汰，如果Redis配置了淘汰策略（比如淘汰最近最少使用的键），那么当内存不足时，它就需要一边处理新的读写请求，一边在庞大的键空间中寻找可以删除的键，这个查找和删除的过程是会消耗CPU资源的，尤其是在数据量非常大的时候，就会导致正常的请求处理被拖慢，感觉起来就是Redis卡顿了，更糟糕的是，如果内存彻底用尽，操作系统会启动一个叫做“交换”（Swap）的机制，把内存中一部分不常用的数据写到硬盘上，硬盘的速度比内存慢成千上万倍，一旦发生交换，Redis的性能就会呈现断崖式下跌，基本就不可用了。

一个容易被忽略的“隐形杀手”是持久化操作，为了数据安全，我们通常会配置Redis定期把内存中的数据保存到硬盘上（快照方式，也叫RDB），或者记录下每一个写操作命令（日志方式，也叫AOF），这两种方式都可能引起卡顿，先说RDB，当执行快照时，Redis会fork出一个子进程来专门负责写硬盘，这个fork操作本身，在数据量大的时候，可能会因为要复制父进程的内存页表而瞬间消耗大量CPU资源，导致主进程短暂停顿，如果服务器CPU本身就不够强劲，这个停顿会非常明显，而AOF方式，如果设置为每次写操作都同步刷盘（最安全模式），那么每次写入都要等待硬盘IO完成，这会严重拉低写入性能，即使设置为每秒同步一次，在同步的那一刻也可能因为硬盘IO压力大而产生轻微的延迟波动。

第三个瓶颈来自于网络，Redis虽然是单线程处理命令，但它的网络IO处理能力非常强，这并不意味着网络不会成为问题，如果客户端和Redis服务器之间的网络延迟很高（比如跨机房部署），那么即使Redis本身处理得再快，一个来回的通信也要花费几十甚至上百毫秒，用户感觉就是慢，如果客户端数量非常多，或者某些客户端发出了非常耗时的命令（后面会提到），导致网络连接被长时间占用，其他客户端的请求就只能排队等待，这也会造成整体响应变慢。

第四点,Redis有个著名的特性叫单线程模型，这意味着它在任何时刻只能处理一个命令，这个设计避免了多线程的复杂性和竞争问题，是Redis简单高效的关键，但这也成了一柄双刃剑，如果一个命令执行起来本身就很慢，那么它就会阻塞住后面所有的命令，就像高速公路上的唯一一个收费亭，前面有辆车磨磨蹭蹭，后面的车全得等着，哪些是“慢命令”呢？最常见的就是一次性获取很多数据的命令，比如keys *（获取所有键名），或者对一个大集合求交集、并集的操作，又或者是对一个特别长的列表进行遍历，这些命令的时间复杂度不是O(1)（即执行时间不随数据量增长），而是随着操作的数据量线性甚至指数级增长，一旦有人不小心在生产环境使用了keys *，很可能直接让Redis“假死”好几秒钟。

操作系统和硬件的环境也至关重要，如果Redis进程和别的CPU密集型应用（比如Java应用）部署在同一台机器上，它们会争抢CPU资源，导致Redis得不到及时调度，硬盘如果是普通的机械硬盘，那么在进行AOF重写或者RDB持久化时，缓慢的IO也会成为瓶颈，操作系统的一些内核参数，比如网络连接队列的长度、内存分配策略等，如果配置不当，也可能在高并发场景下导致性能问题。

Redis变慢通常不是单一原因造成的,而是内存、持久化、网络、单线程特性和运行环境这几个方面共同作用的结果，排查的时候，也需要从这些方面入手，先看内存使用情况，再看是否有慢查询，检查持久化配置和硬盘IO，最后评估网络和系统资源，这样才能准确地找到那个让它“卡住”的真正瓶颈。 结束）