做运维这几年最怕的不是故障本身而是故障现象摆在你面前、所有常规手段都指向“没问题”的时刻。前阵子我就栽在一个Redis连接失败的问题上从第一条报错到定位根因前后花了整整三天。这三天里我换过连接池参数、调过内核keepalive、查过防火墙会话表甚至一度怀疑是客户端SDK的Bug最后发现“元凶”居然是一个被启动参数覆盖掉的配置项。写这篇文章是想把这三天踩过的坑、验证过的思路和最终的配置检查方法完整分享出来。尤其是那些遇到过“服务重启后正常、过一小时又连不上”这类诡异现象的同学这篇文章的排查路径可以直接套用。1. 故障现场应用报错“连接被重置”Redis 却活得好好的1.1 错误日志里的三类典型异常这次出问题的是三台应用服务器加一套 Redis 主从客户端用的是 Jedis。最开始只有凌晨的任务报错后来白天业务高峰期也开始出现。报错消息大致有三类redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pooljava.net.SocketException: Connection resetStackExchange.Redis.RedisConnectionException: No connection is available to service this operation当时第一反应是网络问题因为从监控面板看Redis 进程的 CPU、内存都正常主从也没有发生切换慢查询数量也没有明显增加。唯一让人不安的是这类异常的出现很有规律应用重启后会清静一段时间然后过 50 到 60 分钟第一批报错准会冒出来。起初我以为是负载均衡或者防火墙干的于是开始在网络链路上下工夫结果网络侧什么可疑的地方都没找到。这里想多说一句很多 Redis 连接问题之所以难排查不是报错信息有多复杂而是它表现得像“网络抖了一下”。尤其是Connection reset这种错误放在谁身上都会先怀疑交换机、防火墙或云安全组。恰恰是这种直觉让你很容易跳过对 Redis 自身配置的检查先去折腾一堆和根因无关的东西。1.2 初步验证“三条全过”反而更懵按照常规排查套路我在应用服务器上依次做了三件事用telnet redis_ip 6379检查端口返回 Connected说明 TCP 层可达。用redis-cli -a password ping返回 PONG说明 Redis 进程活着密码也没问题。用redis-cli -a password info server查看运行状态发现connected_clients不高远没有到maxclients上限。三条全过反而让人更懵。再加上 Redis Desktop Manager、Another Redis Desktop Manager 这类图形工具都能正常连接我一度觉得问题不在 Redis而在业务代码或连接池配置。后来复盘时才想明白这个判断做得太早了。图形工具大多每次执行完命令就释放底层连接或者空闲重连策略和业务长连接完全不同它们“正常”恰恰容易掩盖真相。如果当时能多看一眼CONFIG GET timeout整个排查可能十分钟就结束了。2. 三天排查链路从连接池到内核参数到底错在哪一层2.1 客户端连接池成了第一怀疑对象因为报错集中在“从连接池拿不到连接”和“连接被重置”大部分人进来都会先检查连接池配置。我也没有例外依次做了三件事把testOnBorrow从false改成了true让连接在借出之前先发一个 PING坏连接当场暴露。把maxTotal从 8 调大到 50担心是并发连接数不够导致获取不到资源。调小minEvictableIdleTimeMillis让空闲时间过久的连接被连接池主动淘汰。改完之后异常确实减少了一些但没有根治。现在复盘原因很简单testOnBorrow只能让客户端不把坏连接借出去并不能阻止 Redis 服务端在空闲后把连接关掉。它相当于给一个漏水的桶加了检查员看起来漏出去的水少了可桶底那个漏水点依然在。更要命的是testOnBorrow在高并发下会增加一次额外 RTT对性能有影响不适合长期开着。2.2 防火墙会话老化、LB空闲超时和内核 keepalive 都被“冤枉”了既然客户端连接池只是表象我开始往网络层挖。这种“每隔一段时间连不上”的现象太像中间网络设备把空闲会话清掉了。于是我查了应用服务器和 Redis 之间的防火墙老化时间、交换机会话表、负载均衡的空闲超时配置还把服务器内核参数改了一遍net.ipv4.tcp_keepalive_time 120 net.ipv4.tcp_keepalive_intvl 30 net.ipv4.tcp_keepalive_probes 3改完之后等待业务低峰期观察问题照旧。这说明网络层设备并没有主动丢包TCP 连接不是被中间设备“掐断”的。这步排查虽然没解决问题但排除掉了网络层的重大嫌疑让我后面能更果断地回过头查 Redis 本身。现在回看当时还忽略了一个关键点如果是网络设备会话老化那么故障间隔时间应该和网络设备配置高度相关通常不会精确到 60 分钟这样规整的数值。Redis 服务端恰好有一个timeout配置功能和“空闲超过 N 秒就断开”完全吻合但当时因为看过一遍redis.conf里写的是 0就把它排除了。这个盲区直接导致后面多折腾了一天。2.3 规律浮现应用重启后满血50分钟后再次倒下排查到第二天晚上我把所有异常事件的触发时间点拉出来发现一个规律每次应用重启后大约 50 到 60 分钟第一批连接失败一定会出现。如果是防火墙会话老化老化时间应该由网络设备决定不会和“60分钟”这么精确的数字绑定。我当时隐隐觉得Redis 服务端一定存在一个“到点就断”的机制。第三天上班我直接在应用服务器上执行了redis-cli -h redis_ip -a password CONFIG GET timeout返回结果是60。再查tcp-keepalive返回300。看到这两个值的瞬间整个问题的链条一下就完整了。之前所有“重启后好转、过一小时复发”的现象都能用这个配置解释服务端在连接空闲 60 秒后主动断开客户端却不知道继续拿着旧连接去发命令于是报错。3. 真凶落网启动参数里的--timeout 60覆盖了配置文件3.1 只看 redis.conf 不看运行时配置是这次事故的最大盲区这里有个很讽刺的插曲第二天我就打开过/etc/redis/redis.conf里面写的清清楚楚是timeout 0所以我直接把这个配置项从怀疑列表里划掉了。现在看这是最不该犯的错误。Redis 配置其实有三个层面配置文件里的默认值或显式值启动命令里的--配置名 值优先级高于配置文件运行时CONFIG SET修改的临时值优先级最高但不会写回文件。我们这台 Redis 由 systemd 管理用systemctl cat redis查看实际启动命令后才发现ExecStart里写的是/usr/bin/redis-server /etc/redis/redis.conf --supervised systemd --daemonize no --timeout 60。也就是说虽然配置文件里是timeout 0但启动命令额外加了一个--timeout 60把配置文件的默认值覆盖掉了。为什么会在启动命令里多出这个参数大概率是之前有同事为了“让 Redis 自动回收空闲连接、减少连接数占用”在 systemd unit 里临时加的参数既没有同步到 redis.conf也没有留任何注释。这种隐蔽性极强的问题靠肉眼检查配置文件是发现不了的必须用CONFIG GET或者查看进程启动参数才能看到真实值。3.2 timeout、tcp-keepalive 和客户端连接池的“三方博弈”timeout的单位是秒官方说明是客户端空闲 N 秒后服务端主动关闭连接默认 0 表示不启用。线上设置成 60意味着所有连接只要 60 秒内没有命令就会被 Redis 主动断开。这个机制本身并不奇葩很多高连接数场景确实想通过它回收闲置连接。真正的问题是它和客户端连接池的行为完全冲突了。客户端连接池并不会立刻感知服务端已经断开。以 Java 应用为例连接池里的空闲连接会保留很长时间默认的驱逐策略在一些版本里甚至接近“永久保留”。于是链路就变成了这样应用从连接池取出一条“看起来正常”的连接。这条连接距离上次使用已经超过 60 秒Redis 服务端早就把它关了。应用拿着这条连接发命令可读事件触发 IO 异常表现为Connection reset或Read timed out。这就能解释为什么重启应用能立刻恢复重启后连接池重建所有连接都是新的。但过 50 到 60 分钟最早一批连接又一次进入空闲超时区故障重现。不是精确到60秒是因为业务访问 Redis 的节奏并不均匀多条连接的空闲时间存在差异整体上就表现为“一小时后集中报错”。至于tcp-keepalive 300它原本的作用是让内核每隔 300 秒发送 TCP 探测报文确认对端是否存活。但问题在于timeout 60已经把连接关闭了内核的 keepalive 根本没有机会介入探测包也不会发出去中间设备自然看不到这个连接有活动。这两个参数放在一起等于一个在拆连接另一个使劲想保活最后保活方输得干干净净。3.3 为什么阻塞命令和图形工具都没暴露问题这次被两个“正常现象”干扰了很久线上采用 BRPOP 进行消息处理的模块一直没报错Redis Desktop Manager 也一直连得稳稳的所以有一段时间我甚至怀疑是不是不同语言客户端对 Redis 的处理方式不同。实际上问题纯粹出在连接的空闲状态上。Redis 文档里写得很清楚通过阻塞命令如 BRPOP或订阅命令SUBSCRIBE建立的连接不受timeout限制。因为这类连接即使没有数据往来也处于“正在被 Redis 跟踪”的状态服务端不会因为空闲把它们断掉。所以凡是用了 BRPOP 的模块哪怕业务上看起来没什么流量连接也一直健在。这给排查制造了巨大的噪音。而 Redis Desktop Manager 这类图形工具呢通常执行完命令就会释放连接或者空闲重连策略很短每次新建连接都发生在服务端断开之前。它不代表业务长连接的真实行为。想明白这两点你就不会再被“某些工具连得上、某些连不上”的表象带偏了。4. 修复与验证让配置在“文件、启动参数、运行时”三层完全一致4.1 临时止血与彻底修复三个地方必须一起改确认根因之后修复本身不难但要注意三个层面缺一不可运行时热修改先执行CONFIG SET timeout 0让当前所有连接立刻不再因为空闲被断开。注意这个修改不会写入配置文件一重启就丢了但可以当作应急止血。配置文件确认打开/etc/redis/redis.conf确认timeout 0或者直接注释掉这行因为默认就是 0。只在这里改没有用启动参数的优先级更高。启动参数清理编辑 systemd unit 或 override.conf去掉ExecStart后面的--timeout 60。如果保留了一个调优文件建议在文件头部加注释说明参数谁加的、为什么加、什么时候加。改完后执行systemctl daemon-reload systemctl restart redis重启后再一次执行CONFIG GET timeout确认返回的是0。同时用ps -ef | grep redis-server查看进程启动命令行确保已经看不到--timeout字样。双重确认才算真正改干净。4.2 用一条 raw socket 脚本复现整个故障为了验证修复效果我写了一个最底层的测试脚本绕开所有客户端 SDK直接用 TCP 连接观察 Redis 行为。这样做的好处是不受任何连接池、自动重连机制干扰能直接看到服务端到底有没有主动断开空闲连接。import socket import time s socket.create_connection((redis_ip, 6379), timeout5) s.sendall(bPING\r\n) print(first response:, s.recv(1024)) time.sleep(61) try: s.sendall(bPING\r\n) print(second response:, s.recv(1024)) except Exception as exc: print(second send/recv failed:, type(exc).__name__, exc) finally: s.close()在修复前跑这个脚本第二次 PING 大概率会触发ConnectionResetError或TimeoutError。修复后跑61 秒后连接依然活着第二次能正常收到PONG响应。这个脚本不依赖第三方库适合直接拿到现场验证问题也可以放进测试环境的回归用例里。4.3 客户端连接池参数也需要配合调整如果你不想把服务端timeout设成 0那一定要让客户端连接池的空闲淘汰时间小于服务端的timeout。比如服务端timeout 60客户端连接池就要保证空闲连接在 30 秒左右被回收并通过testWhileIdle定期检查连接健康状态。这样才能在服务端关掉连接之前主动放弃而不是等它变成一条坏连接。在我的案例里最终选择把服务端timeout设回默认的 0让连接保持长期存活依赖tcp-keepalive和应用层心跳清理异常连接。Redis 本身是很轻量的内存服务空闲连接的成本主要是文件描述符和少量内存没必要为了省资源去设置一个很短的timeout。如果连接数已经接近maxclients优先排查有没有连接泄漏而不是用粗暴的空闲断开来收拾局面。5. 除了 timeout还有哪些 Redis 配置会伪装成“连接失败”5.1 maxclients 与 tcp-backlog连接数到顶时的表现maxclients默认是 10000一般业务很难触达。可一旦应用存在连接泄漏客户端数量会逐步逼近上限。表现出来就是新连接建立时直接被拒绝客户端报Cannot connect或max number of clients reached而已经建立的连接不受影响。这看起来和 timeout 问题很像但看监控就能区分connected_clients会持续走高CONFIG GET maxclients能看到实际限制。另一个容易忽略的是tcp-backlog。Redis 只负责接收内核已完成握手的连接如果应用层 accept 不过来连接请求就会在内核队列里堆积。当并发连接非常大时tcp-backlog太小会导致客户端连接超时Redis 日志里却不一定有明显报错。遇到这种情况除了看 Redis 的tcp-backlog配置还要把系统级参数net.core.somaxconn一起调大两边保持一致才有效。5.2 bind、protected-mode 与 ACL权限类配置的典型坑如果是新环境部署连接失败更多是bind和protected-mode组合出来的问题。Redis 默认只监听127.0.0.1直接远程连接必然失败如果只写了bind 0.0.0.0但没关掉protected-mode非本机访问还是会被拒绝报错通常是DENIED Redis is running in protected mode。这个错误其实很友好会直接告诉你原因。怕就怕某些云镜像把 protected-mode 关了但bind设置错误造成“一部分机器能连、一部分不能连”的诡异现象。ACL 配置也要注意。Redis 6.0 之后可以通过 ACL 定义默认用户的权限和访问模式。这类问题最容易出现在版本升级后比如客户端连接串里明明带了密码但新配置里默认用户是nopass或者反过来默认用户设置了requirepass而客户端没传密码。遇到权限类连接错误时建议同时看ACL LIST和CONFIG GET requirepass不要只看一处。5.3 顺手能做的配置审计把“三天排查”压缩到十分钟经过这次事故我给自己列了一个 Redis 连接问题的快速检查清单分享出来遇到类似问题可以按顺序过一遍CONFIG GET timeout有没有配置过短的主动断开时间。CONFIG GET tcp-keepalive是否配置了合理的心跳间隔。CONFIG GET maxclients和CLIENT LIST连接数是否接近上限各连接的空闲时间IDLE是否异常。CONFIG GET protected-mode、CONFIG GET bind、ACL LIST监听地址、保护模式、权限配置是否匹配业务形态。systemctl cat redis或ps -ef | grep redis-server启动参数有没有悄悄覆盖配置文件。最后分享一个小技巧我后来在配置管理系统里给所有 Redis 节点加了一个定时巡检脚本每天拉一次CONFIG GET timeout和tcp-keepalive与预期值做比对出现偏差立即告警。别小看这一步它能把这类“查三天”的隐性问题消灭在真正影响业务之前。这次之后我也养成了一个习惯凡是排查连接类故障永远是先查运行时配置再查文件配置最后查启动参数。三个层面只要有一层不一致再老的司机都容易翻车。