connectiontimeout是tcp连接建立阶段的超时，sotimeout是连接建立后的读写超时；前者需设1–3秒，后者按业务rt分位数上浮20%～50%；lettuce须显式开启tcp keepalive并调优参数，jedis需协调maxwaitmillis与timeout避免叠加超时。
Redis客户端连接超时（ConnectionTimeout）和读写超时（SoTimeout）的区别
ConnectionTimeout 是建立 TCP 连接阶段的等待上限，比如 DNS 解析慢、服务端未监听、网络中间设备拦截，都会卡在这里；SoTimeout（也叫 socket timeout 或 read/write timeout）是连接已建立后，read() 或 write() 系统调用阻塞的最大时间。很多用户把两者混为一谈，结果调大了 SoTimeout 却解决不了连接失败问题。
常见错误现象：java.net.SocketTimeoutException: Read timed out 属于 SoTimeout；java.net.ConnectException: Connection refused 或长时间无响应后抛 java.net.SocketTimeoutException: connect timed out 才是 ConnectionTimeout 问题。
- ConnectionTimeout 应设为 1–3 秒：太短容易误判网络抖动，太长会让故障感知延迟
- SoTimeout 建议从 1000ms 起步，按业务 RT 分位数（如 P99=800ms）上浮 20%～50%，避免单次慢请求拖垮线程池
- Spring Data Redis 默认
timeout同时作用于 ConnectionTimeout 和 SoTimeout，需显式拆分配置（如 Lettuce 的ClientOptions或 Jedis 的JedisPoolConfig）
Lettuce 客户端开启 TCP keepalive 并调优参数
Lettuce 默认不启用 TCP keepalive，当连接中间经过 NAT、防火墙或负载均衡器时，可能被静默断连，后续请求直接卡死在 read，直到 SoTimeout 触发——这不是超时设置不合理，而是连接已失效却没被及时发现。
必须手动开启并调小探测间隔，否则依赖 OS 默认值（Linux 通常 2 小时），完全无法满足 Redis 长连接场景。
- 启用方式：在
ClientResources中配置SocketOptions.TCP_KEEPALIVE为true - 关键参数（需通过
SocketOptions设置）：TCP_KEEPIDLE（首次探测前空闲秒数）、TCP_KEEPINTERVAL（探测间隔）、TCP_KEEPCOUNT（失败探测次数）。建议设为30/10/3，即空闲 30 秒后开始探测，每 10 秒一次，连续 3 次失败则关闭连接 - 注意：这些参数在 macOS 和部分旧版 Linux 内核中支持不一致，生产环境需验证
ss -i或netstat -no输出是否生效
Jedis 连接池中 timeout 与 maxWaitMillis 的协同关系
JedisPool 的 maxWaitMillis 控制从连接池获取连接的等待时间，它和底层 socket 的 timeout 是两层超时，容易叠加导致“明明只设了 1000ms 却等了 2000ms 才报错”。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
典型误配：timeout=1000 + maxWaitMillis=1000 → 最坏情况：等 1 秒拿不到连接，再花 1 秒执行命令失败，总耗时近 2 秒且堆栈里只显示 JedisConnectionException，掩盖真实瓶颈。
-
maxWaitMillis应显著小于业务整体超时（例如接口 SLA 是 1500ms，这里设 300–500ms 更合理） -
timeout（即 SoTimeout）建议设为 800–1200ms，确保单次命令可完成，又不至于让慢查询长期占着连接 - 务必开启
testOnBorrow=true或更推荐的testWhileIdle=true+timeBetweenEvictionRunsMillis=30000，避免拿到已断开的连接
如何验证 TCP keepalive 和 timeout 是否真正生效
光改配置不验证，等于没调。最直接的方式是模拟中间链路断连：在客户端和服务端之间加一层可控的网络中断（如 iptables DROP 或 tc netem delay loss），观察客户端行为。
验证点有三个：连接是否被及时回收、异常是否快速抛出、重连是否触发。不要依赖日志关键词，要看实际耗时和连接状态。
- 用
lsof -i :6379或ss -tnp | grep :6379查看 ESTABLISHED 连接的timer字段（Linux），出现keepalive表示已启用 - 抓包确认：客户端在空闲期发出 TCP ACK + ACK（keepalive probe），服务端回应 ACK；若服务端宕机，客户端应在
TCP_KEEPIDLE + TCP_KEEPINTERVAL × TCP_KEEPCOUNT后关闭连接 - 代码中捕获
RedisCommandTimeoutException（Lettuce）或JedisConnectionException（Jedis）时，检查getCause()是否为SocketTimeoutException或IOException，区分是真超时还是连接已断
超时不是越大越好，TCP keepalive 也不是开了就万事大吉——参数必须匹配你的网络拓扑、中间设备保活策略和业务容忍度。线上调参后，一定要用真实链路故障做闭环验证。
