Redis读超时到底咋回事，排查思路和实操经验分享

关于Redis读超时这个问题，我结合自己以前踩过的坑和网上一些技术社区像掘金、知乎上大家的讨论，给你捋一捋，这问题说白了就是，你的应用程序去Redis数据库里拿数据，等了好久（超过了设定的时间，比如1秒、2秒），Redis那边还没把数据送回来，你的程序就急了,抛出一个读超时的错误。

读超时到底是咋回事？

你别把它想得太复杂，本质上就是一次请求-响应没在规定时间内完成，就像你点外卖，平台告诉你30分钟送达，结果过了40分钟骑手还没到，你就可能取消订单或者投诉了，Redis的读超时也是这个道理，原因可能出在“路上”（网络），也可能出在“餐厅”（Redis服务器本身）。

排查思路：从简单到复杂，从外到内

别一上来就怀疑Redis服务器要挂了，大概率问题不在那儿，按照这个顺序查,能省不少力气。

先看看是不是网络“堵车”了？

这是最常见的原因,你的应用程序和Redis服务器之间的网络链路出了问题。

• 网络延迟高吗？ 你可以在应用服务器上，用 ping 命令一直ping一下Redis服务器的IP地址，看看返回的时间（延迟）高不高，稳不稳定，如果动不动就几十上百毫秒，甚至丢包，那网络环境肯定有问题，可能是机房网络波动,也可能是你们公司网络本身就不稳定。
• 带宽够用吗？ 虽然Redis通常数据量不大，但如果你在做大数据量的读取（比如一个很大的Hash键），或者同时有大量操作，可能会把网络带宽占满，导致请求排队，可以用 iftop 这类工具看看网络流量。
• 连接数够用吗？ 你的应用程序是不是用了连接池？如果连接池的最大连接数设得太小，在高并发的时候，所有连接都被占用了，新的读请求就得排队等着，等着等着就超时了，去看看连接池的监控,看看活跃连接数是不是打满了。

再瞧瞧Redis服务器自己是不是“忙不过来”？

如果网络没问题,那就要看看Redis本身是不是压力太大了。

• CPU用满了吗？ 用 top 命令看看Redis进程的CPU使用率，如果持续接近100%，说明Redis正在拼命处理任务，可能没空及时响应你的读请求，可能是你正在执行 keys * 这种慢查询把CPU拖垮了。
• 内存够用吗？ 运行 info memory 命令，看看Redis用了多少内存，如果内存快用完了，操作系统会开始用Swap（交换分区），就是把内存里不常用的数据放到硬盘上，硬盘比内存慢成千上万倍，一旦发生Swap，Redis的性能会急剧下降，导致所有操作都变慢,读超时也就不奇怪了。
• 有没有“慢查询”？ 这是关键中的关键，Redis提供了慢查询日志功能，你可以设置一个时间阈值（比如10毫秒），执行时间超过这个阈值的命令都会被记录下来，通过 slowlog get 命令查看最近哪些命令比较慢，常见元凶有：keys *（千万别在生产环境用）、对大集合（Set、List）做全量读取、缺乏索引的复杂查询等。

最后想想是不是命令本身有问题？

有些命令天生就比较“慢”。

• 是不是用了阻塞命令？ BLPOP、BRPOP 这种，它们会一直等着直到有数据 pop 出来，如果你的超时时间设得比阻塞命令的阻塞时间还短,那肯定就会超时。
• 操作的数据是不是太大了？ 比如你存了一个包含几十万元素的Set，然后要执行 SMEMBERS 命令把全部元素取出来，序列化、网络传输这个过程本身就很耗时，应该考虑用 SSCAN 这种分批读取的命令。

实操经验分享

光说思路可能还是有点虚,分享几个实实在在的经验。

• 慢查询日志是救星。 有一次我们线上环境突然频繁报读超时，但CPU和内存看着都正常，第一反应是网络问题，但网络团队查了半天说链路没问题，最后才想起来去查慢查询日志（slowlog get 10），发现有一个后台脚本在执行 HGETALL 一个非常大的Hash键，这个键有好几万个字段，每次执行都要几百毫秒，堵住了其他简单的GET命令，解决方法就是把那个脚本优化掉,或者把大Hash拆小。
• 警惕O(N)命令。 有个经典案例，有人用 KEYS * 命令在线上环境模糊匹配键，这个命令的时间复杂度是O(N)，N是数据库里key的总数，当key有几百万个的时候，这个命令会直接让Redis卡住好几秒，导致所有请求全部超时，这种操作一定要用 SCAN 命令替代。
• 连接池配置很重要。 我们的一个服务在晚高峰会偶发超时，查了所有指标，Redis服务器很健康，网络也正常，最后发现是应用侧连接池的maxWait（获取连接的最大等待时间）设得太短了，在高并发时，连接被借完，新请求等不到连接，稍微一等就超时了，适当调大maxWait或者增加最大连接数就解决了。
• 监控是预防的关键。 不能等出了问题再查，一定要有完善的监控：Redis服务器的CPU、内存、网络流量、连接数、慢查询数量，设置好告警，一旦有指标异常，就能提前介入,避免小问题演变成线上故障。

碰到Redis读超时，别慌，按照“网络 -> Redis服务器负载 -> 具体命令”这个路径，一步步缩小范围，结合慢查询日志这个利器，大部分问题都能找到根儿上，平时把监控做好,就能防患于未然。