Redis读超时别忽视，调一调设置速度能快不少，体验差别挺明显

用手机App时，刷着刷着就卡住了，页面转了半天圈圈，最后弹出一个“网络错误”或者“请求超时”，这口锅可能真的不该由你的网络来背，而是应用背后的服务器和它使用的数据库“对话”超时了，如果这个数据库碰巧是Redis，那么一个看似不起眼的“读超时”设置,可能就是影响你体验的关键。

这话可不是我瞎说的，很多在实际项目中摸爬滚打过的开发者都深有体会，在知乎上有开发者在分享性能优化经验时就提到，他们遇到过因为Redis读超时（read timeout）设置得过短，导致在高并发场景下，大量原本可以成功的请求，仅仅因为网络的一个小小波动或Redis实例瞬间的压力抖动，就被判定为失败，直接拖垮了整个服务的响应速度和平稳性。（引用来源：知乎平台多位开发者的实战经验分享）

那这“读超时”到底是个啥呢？咱们说得再直白点，想象一下，你去一家很火的餐厅点餐，你告诉服务员你要什么（应用程序向Redis发送一个读取数据的命令），然后就开始等待，这个“读超时”就是你愿意等待服务员把菜端上来的最长时间，如果你性子特别急，只愿意等5秒钟（超时时间设得很短），那么只要服务员在后厨因为同时要处理的订单太多，稍微慢了一点点，超过5秒还没来，你可能就拍桌子走人了（应用程序认为这次请求失败），但实际情况可能是，你刚起身，服务员就端着菜跑出来了，可你已经不要了,这次服务就白白浪费了。

反过来，如果你特别有耐心，愿意等上半个小时（超时时间设得很长），那也会出问题，万一服务员不是忙，而是压根儿就把你的单子忘了，或者后厨出了什么状况（比如Redis服务器真的宕机了，或者出现了严重的性能问题），你就会一直傻等在那里，干着急，没法点下一道菜，也没法结账走人（应用程序线程被长时间挂起，无法处理新的请求），这会导致你的体验极差，而且餐厅的翻台率也大大降低（服务器资源被耗尽，无法服务更多用户）。

这个“读超时”的值，不能设得太短，也不能设得太长，得找一个“刚刚好”的黄金平衡点，这个点在哪里呢？它没有一个放之四海而皆准的标准答案，完全取决于你的具体业务和系统环境,你需要考虑几个因素：

第一，你的业务对延迟的容忍度是多少？比如是一个实时竞价的系统，要求毫秒级的响应，那么超时时间可能就要设得非常短，哪怕牺牲一部分成功率也要保证速度，但如果是一个后台生成报表的任务，慢几秒钟甚至几分钟用户都能接受，那超时时间就可以设得长一些,确保任务能成功完成。

第二，你的网络环境怎么样？如果你的应用程序和Redis服务器都在同一个机房的内网，网络延迟很低而且很稳定，比如平均响应时间在1毫秒以内，那么你完全可以把读超时设为10毫秒或几十毫秒，这样一旦出现超过这个时间的情况，大概率就是Redis实例本身出了点小问题，及时失败并启用备用方案（比如去读数据库）是合理的，但如果你的Redis服务是在云端，网络路径比较复杂，偶尔有个几十毫秒的波动很正常，那你把超时设成10毫秒就是自找麻烦了,会导致大量的误判。

第三，你希望失败的时候发生什么？是宁愿稍微多等一会儿换来成功，还是快速失败然后尝试别的办法？对于登录验证这种关键操作，你可能希望多给Redis一点时间，确保能读到用户的会话信息，避免用户被误判为未登录，而对于一些非核心的、有缓存更好的功能（比如文章点赞数显示），如果Redis一时半会儿没响应，直接显示一个默认值（比如0）可能比让用户干等着体验更好。

在实际操作中，调整这个参数往往能带来“立竿见影”的效果，我记得有个技术博客里提到过一个案例，他们有一个服务接口的响应时间总是不稳定，时快时慢，经过层层排查，最后发现是连接Redis的客户端读超时设置成了1秒，而在他们的网络环境下，Redis的正常操作通常都在5毫秒内完成，但在高峰期，偶尔会有一些请求的响应时间达到100-200毫秒，这本来是完全正常的波动，但因为超时设得太紧，这些稍微慢一点的请求全部被当成了超时失败，应用程序里又设置了重试机制，一次失败立刻重试一次，导致瞬间流量几乎翻倍，反而进一步加重了Redis的负担，形成了恶性循环，后来他们只是简单地把读超时参数从1000毫秒调整到了3000毫秒，那个接口的稳定性立刻大幅提升，P99响应时间（最慢的那1%的请求的响应时间）下降了非常明显。（引用来源：某技术博客中的实际故障排查案例）

所以说，千万别小看Redis客户端配置里那几个关于超时的参数，比如连接超时（connection timeout）、读超时（read timeout/socket timeout），它们就像是水龙头的阀门，拧得太紧，水流不畅；拧得太松，水花四溅，花点时间，根据你的实际情况，耐心地调一调，找到一个最适合你业务的“甜蜜点”，可能只是改一个数字、重启一下应用服务的事儿，但给你带来的，将是用户抱怨的减少、系统稳定性的提升，以及更加流畅顺滑的使用体验，这种投入产出比极高的事情，何乐而不为呢？下次当你感觉系统时不时“卡一下”的时候，不妨先去检查一下你的Redis超时设置,说不定就有意想不到的惊喜。