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也救不了主线程。
