会，但仅在大量小包、高并发短连接或频繁单命令调用时；瓶颈在于系统调用与上下文切换，而非命令执行，应优先用 pipeline 减少往返和 syscall 次数，并关闭 Nagle 算法（tcp-nodelay yes）。

Redis单线程模型下，网络IO真会拖垮性能？

会，但只在特定场景下——比如大量小包、高并发短连接、或客户端频繁发 GET/SET 单命令时。Redis 的单线程事件循环（基于 epoll/kqueue）本身效率极高，瓶颈往往不出在「执行命令」，而出在「收包/发包」的系统调用开销和上下文切换上。

关键不是换多线程（Redis 6+ 的 IO 线程只负责读写 socket，不处理命令逻辑），而是减少网络往返和系统调用次数。

用 pipeline 批量发命令，别一个一个 redis-cli 或 redis-py 调用

每个 TCP 包至少含 40 字节 IP+TCP 头，一次 GET key 实际可能发 60+ 字节。1000 次独立请求 ≈ 1000 次 syscall + 1000 个包；用 pipeline 合并后，可能就 1 个包 + 1 次 read + 1 次 write。

• Python 中避免这样写：r.get("a"); r.get("b"); r.get("c") —— 这是三次往返
• 改用 pipe = r.pipeline(); pipe.get("a"); pipe.get("b"); pipe.get("c"); pipe.execute()
• 注意：pipeline 不保证原子性，也不支持跨 slot 的 Redis Cluster 请求
• 如果命令间有依赖（比如用前一个结果决定下一个 key），pipeline 就不能用，得考虑 Lua 脚本

启用 TCP_NODELAY 和调整内核 socket 缓冲区

默认 Linux 下 TCP 会启用 Nagle 算法，把小包攒到 MSS 再发，对 Redis 这种低延迟场景反而是拖累。必须关掉 TCP_NODELAY，否则 pipeline 或 RESP2 多行响应可能被延迟 200ms。

• 服务端配置：在 redis.conf 加 tcp-nodelay yes（6.0+ 默认已开）
• 客户端也要配：比如 Java Jedis 构造时设 setTcpNoDelay(true)；Go redigo 里用 conn.SetNoDelay(true)
• 如果压测发现 netstat -s | grep "segments retransmitted" 偏高，可适当增大 net.core.wmem_max 和 net.ipv4.tcp_wmem，避免发包阻塞

警惕 client-output-buffer-limit 导致的隐式断连

当客户端消费慢（比如 SUBSCRIBE 后不及时读 PUBLISH 消息，或 monitor 模式下不处理输出），Redis 会缓存响应在 client output buffer。超出 client-output-buffer-limit 配置就强制断连——这不是网络超时，而是服务端主动 kill，容易误判为“连接不稳定”。

• 查当前缓冲区大小：CLIENT LIST 输出里的 omem 字段
• 默认 pubsub 是 client-output-buffer-limit pubsub 32mb 8mb 60，意思是：内存超 32MB 或连续 60 秒超 8MB 就断
• 监控时别只盯 connected_clients，要加告警看 rejected_connections 和 expired_keys 是否突增
• 业务侧如果必须长连慢消费，宁可拆成多个轻量连接，也别靠调大 buffer 硬扛

真正卡住的地方，往往不在 Redis 自身，而在 client 怎么发、发多少、以及 OS 怎么传——调参前先抓包看 tcpdump -i lo port 6379，比瞎猜快得多。