Redis读超时问题别怕，教你怎么设置让它不再烦人还返回结果

Redis读超时问题别怕，教你怎么设置让它不再烦人还返回结果

你是不是遇到过这种情况：你的应用程序本来跑得好好的，突然之间，页面上开始转圈圈，日志里冒出一大堆“Read timed out”的错误，用户急得直跳脚，你也跟着头大，这个烦人的Redis读超时问题，确实让很多开发者感到困扰，但别担心，今天我们就来把这个问题拆解清楚，告诉你该怎么设置，才能让它既不影响性能,又能稳稳地拿到结果。

我们得明白，为什么会有读超时？就是你的应用程序（客户端）向Redis服务器发送了一个请求（比如要查一个用户信息），然后就开始等着Redis回话，客户端可没那么多耐心，它设定了一个时间，比如1秒钟，如果超过1秒Redis还没把数据传回来，客户端就等不及了，它会认为这次请求失败了，于是抛出一个读超时异常，但这个时候，Redis服务器可能根本不知道这回事,它可能还在吭哧吭哧地处理你的请求呢。

到底是什么原因导致了Redis“反应慢”呢？根据一些技术社区像知乎和CSDN上的讨论,常见的原因有几个：

第一，网络问题，这是最直观的原因，你的应用服务器和Redis服务器之间的网络线路不稳定，或者带宽不够，数据包在路上堵车了，或者干脆丢了，这就好比快递小哥在路上遇到了大塞车,你等半天也收不到包裹。

第二，Redis服务器自身压力大，如果Redis正在处理一个非常耗时的命令（比如一次性获取一个包含几百万个元素的集合，或者执行一个复杂的Lua脚本），或者同时有海量的请求涌进来，导致CPU飙高，它就没法及时响应你的新请求了，这就好像超市只有一个收银台，却突然来了一个旅行团排队结账,后面零散的顾客就只能干等着。

第三，Big Key和慢查询，这是非常常见的一个坑，所谓“Big Key”，就是指一个key对应的value特别大，比如一个几MB甚至几十MB的字符串，或者一个包含数万成员的集合，读取这种key会非常耗费网络带宽和服务器资源，而“慢查询”就是指那些执行时间很长的命令，Redis有个慢日志功能，可以记录下这些“慢操作”，如果你的操作出现在了慢日志里，那它很可能就是导致超时的“元凶”。

第四，客户端连接池配置不当，客户端（比如Java用的Jedis、Lettuce）通常会通过连接池来管理跟Redis的连接，如果连接池的最大连接数设置得太小，在高并发时，所有连接都被占用了，新的请求就只能排队等待有可用的连接，这个等待时间一旦超过读超时设置,就会报错。

知道了原因，我们就可以对症下药了，设置的关键在于找到一个平衡点：既要给Redis足够的时间去完成可能较慢的操作，又不能无休止地等下去，影响用户体验,下面是一些实用的设置建议：

合理设置读超时时间

别拍脑袋定一个值，你需要了解你的业务，你的应用能容忍多长的延迟？一个后台数据报表任务可能等个10秒都没关系，但一个用户登录操作等2秒就极限了，你需要监控Redis的慢查询日志（使用SLOWLOG GET命令），看看你的常用命令通常的执行时间是多少，根据这些信息，设定一个比平均执行时间稍长，但又符合业务容忍度的值，如果大部分命令都在100毫秒内完成，偶尔有峰值到500毫秒，那么将读超时设置为1-2秒可能是个合理的起点，不要一上来就设置成30秒甚至0（无限等待）,那会带来更大的风险。

优化Redis使用习惯，从根源减少慢操作

这是治本的方法。

• 避免Big Key：拆分大key，比如一个大的Hash可以按一定规则拆成多个小的Hash；一个大的集合可以按类型或时间分片。
• 禁用危险命令：在生产环境，通过配置rename-command将KEYS、FLUSHALL等非常耗时的命令重命名为一个复杂的、不易猜到的字符串，或者直接禁掉,防止误操作。
• 使用高效命令：比如批量操作使用MGET、MSET替代循环的GET和SET；查询集合成员用SSCAN替代SMEMBERS,避免一次性返回巨大结果集阻塞服务器。

调整客户端连接池参数

以常用的Jedis为例,你需要关注这几个参数：

• maxTotal：连接池最大连接数，如果并发量高,需要适当调大。
• maxWaitMillis：当连接池耗尽时，应用获取连接的最大等待时间，这个值应该小于你的读超时时间，否则可能出现连接还没等到,读超时先发生了的尴尬情况。
• testOnBorrow：获取连接时是否进行有效性检查，建议在生产环境设为true,避免拿到已经失效的连接。

实施重试机制（但要谨慎）

对于因为网络抖动导致的偶发性超时，可以在客户端代码中加入重试逻辑，第一次读超时了，等一小会儿再试一次，但这里有个非常重要的原则：重试机制绝对不能用于非幂等性操作（比如给计数器+1），否则可能导致数据不一致，它只适用于纯粹的查询操作（GET等），而且重试次数不宜过多，通常1-2次即可,否则会加重服务器负担。

监控、监控、再监控

光设置好还不够，你得时刻关注它们，搭建监控系统，密切关注Redis服务器的CPU、内存、网络流量、慢查询数量等指标，监控客户端应用的超时错误率，一旦发现超时异常增多，马上根据监控指标去排查是网络问题、Big Key问题还是服务器负载问题。

解决Redis读超时问题，不是一个参数就能搞定的，它需要你先分析原因，然后多管齐下：合理设置超时时间、优化代码和Redis使用方式、调整连接池、并辅以谨慎的重试和持续的监控，把这些方法结合起来，你就能大大降低读超时发生的概率，让你的应用和Redis之间的协作变得更加顺畅可靠,从此告别烦人的超时错误。