redis客户端阻塞主因是主线程被同步操作卡住，调高maxclients反而加剧命令排队积压；真正有效的解法是规避o(n)命令、用unlink替代del，并优化数据结构设计。

Redis客户端阻塞绝大多数不是网络或客户端本身的问题，而是主线程被同步操作卡住——调整配置只是辅助手段，真正起效的配置必须配合业务行为修正。

为什么maxclients调高反而更易阻塞？

很多人误以为增加maxclients能缓解阻塞，实际恰恰相反：更多连接意味着更多命令排队等待单线程处理，一旦出现慢查询或大Key，积压会更严重。

• maxclients默认是10000，但若业务大量使用短连接（如未复用连接池），频繁建连/断连会消耗CPU，间接拖慢主线程
• 真实瓶颈不在连接数上限，而在每个连接发来的命令是否“轻量”：一个HGETALL比一千个GET更容易引发阻塞
• 建议先用redis-cli info clients | grep connected_clients确认当前活跃连接数，若长期低于500，调高maxclients毫无意义

slowlog-log-slower-than设成0真能抓全慢命令？

可以，但不推荐。设为0会让所有命令都记入慢日志，导致日志膨胀、内存占用上升，且掩盖真正耗时异常的命令。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 生产环境建议设为10000（10ms），这是Redis默认值，对绝大多数业务足够敏感
• 若发现延迟毛刺集中在2–5ms区间，可临时下调至5000，排查后务必恢复
• 注意：slowlog get 10看到的只是“执行时间”，不含网络传输和排队时间；如果slowlog里没记录，但客户端超时，大概率是前面有长命令在排队

appendfsync everysec为何有时仍导致写阻塞？

因为Redis主线程会主动检查AOF fsync进度：若距离上次fsync超过2秒，后续写命令会被强制阻塞，直到fsync完成。

• 这不是配置失效，而是保护机制——避免AOF缓冲区堆积过多，宕机丢失数据
• 触发该阻塞的典型场景是磁盘I/O慢（如机械硬盘、IO争抢）、或AOF重写期间子进程占满IO带宽
• 验证方式：redis-cli info persistence | grep aof_delayed_fsync，值>0说明已发生过延迟fsync
• 根治方法不是改appendfsync为no（丢数据风险），而是换SSD、降低AOF重写频率、或把AOF和RDB放在不同物理盘

timeout配置对阻塞问题几乎无效

timeout只控制空闲连接自动断开，对正在执行的命令无任何影响。它解决的是连接泄漏，不是阻塞。

• 设timeout 300，意思是5分钟没发命令的连接会被踢掉，但不影响第1秒就发了LRANGE huge_list 0 -1的连接
• 真正缓解阻塞的配置是io-threads（Redis 6+）：开启后网络读写可并行化，但仅加速协议解析和socket I/O，不加速命令执行
• 最关键的还是业务侧规避KEYS、FLUSHALL、SMEMBERS等O(n)命令，以及用UNLINK替代DEL

配置调整永远只是止痛药，真正的阻塞根源藏在命令复杂度和数据结构设计里——比如一个HGETALL查10万字段的Hash，再怎么调slowlog-log-slower-than也救不了主线程。