Redis响应时间变慢了，耗时问题挺严重，得赶紧查查原因

Redis突然变慢了,这事儿确实急人，别慌，咱们一步步来，就像给车子找毛病一样，先从最常见、最容易的地方查起。

第一，先看看是不是“内存”这个老伙计撑不住了。 这是最普遍的一个坑，根据 Redis 官方文档的说明，Redis 所有的数据都放在内存里，所以它对内存状况特别敏感，你得赶紧去检查一下，Redis 已经用了多少内存，是不是快达到你给设置的上限了，如果内存快用满了，Redis 可能会启动淘汰机制，根据你设定的规则（比如淘汰最不常用的数据）去删除一些数据来腾地方，这个操作本身就会耗时间，更糟糕的是，如果操作系统内存也不够，可能会发生“交换”（Swap），就是把内存里不活跃的数据临时挪到硬盘上去，硬盘的速度比内存慢成千上万倍，一旦发生这个，Redis 的性能就会断崖式下跌，你可以在服务器上运行一下 free -h 命令，看看交换分区（Swap）是不是被占用了，哪怕只用了一点点，对性能的影响也可能是巨大的。

第二，瞧瞧网络和连接数，是不是“路”太堵了。 有时候问题不在 Redis 本身，而在来往的路上，网络延迟突然增高，或者你服务器所在的网络带宽被打满了，都会让响应变慢，你可以用 ping 和 traceroute（在 Windows 上是 tracert）简单测一下网络延迟，连接数过多也是一个隐形杀手，根据一些运维工程师的分享，如果客户端连接数暴涨，比如从几十个变成几千个，Redis 光是处理这些连接的开销就很大，会挤占处理正常命令的资源，你可以用 Redis 的 INFO clients 命令看看当前连接数，如果高得异常，就得查查是不是哪个客户端在疯狂创建连接又没及时关闭。

第三，想想你最近有没有下过一些“笨重”的命令。 Redis 是单线程干活儿的，它一次只能处理一条命令，如果某条命令本身执行就需要很长时间，那它就会堵住后面所有的请求，哪些命令比较“笨重”呢？比如在没有设置范围的情况下直接对一个大集合（Set）或哈希（Hash）执行 HGETALL、SMEMBERS，或者在不该用的生产环境用了 KEYS 模式匹配命令（这个命令会遍历所有键），这些命令在处理海量数据时，耗时可能是毫秒级甚至秒级，整个 Redis 在此期间就无法响应其他客户端了，你需要去 Redis 的慢查询日志里找线索，Redis 可以配置一个阈值，把执行时间超过这个阈值的命令都记下来，看看日志里是不是频繁出现了某些特定的命令。

第四，检查一下“数据持久化”这个后台任务是不是在捣蛋。 Redis 为了把内存中的数据保存到硬盘上防止丢失，提供了两种主要的持久化方式：RDB（快照）和 AOF（记录每一条写命令），根据 Redis 的开发者解释，生成 RDB 快照是一个比较重的操作，需要 fork 出一个子进程来干活，如果你的数据量很大（比如几十个GB），fork 这个过程本身就可能非常耗时，在完成之前，主线程会被阻塞，导致服务暂停，同样，AOF 文件的持久化策略如果设置为“每次写入都同步”（appendfsync always），虽然最安全，但性能压力也最大，你可以检查一下 Redis 的日志，看看最近有没有发生 BGSAVE（后台保存）或者 AOF 重写，以及它们花了多长时间。

第五，看看服务器本身是不是“身体不适”。 Redis 的性能也依赖于它所在的服务器健康状态，如果服务器上同时运行着其他非常消耗 CPU 或磁盘 I/O 的程序（比如数据库、大数据计算任务），它们就会和 Redis 抢资源，特别是磁盘，AOF 持久化或者 RDB 保存的磁盘速度很慢（比如用普通机械硬盘而不是固态硬盘），或者磁盘已经满了，那持久化操作就会成为瓶颈，你可以用 top 命令看看 CPU 使用率，用 iostat 命令看看磁盘的读写等待时间，综合判断一下。

也想想一些“特殊”情况。 你的数据里有没有存在大量的“大键”（Big Key）？一个键对应的值（可能是一个列表或哈希）体积非常大，比如好几 MB 甚至几百 MB，操作这种大键，网络传输、序列化/反序列化、甚至清理它都会很慢，又比如，你是否在大量使用过期时间（TTL）？Redis 需要主动清理过期的键，如果同一时刻有海量的键同时过期，可能会引起短暂的延迟，还有一些更隐蔽的，比如内存碎片率太高，虽然总内存没满，但可用的连续内存不足了，也会影响效率。

排查的顺序,建议先从内存使用率和交换分区开始，这是影响最大、最直观的，然后看慢查询日志，揪出耗时的命令，接着检查持久化相关日志和配置，留意服务器整体的资源状况，多管齐下，通常就能定位到让 Redis“跑不动”的那个主要原因了。