会，但仅在大量小包、高并发短连接或频繁单命令调用时；瓶颈在于系统调用与上下文切换，而非命令执行，应优先用 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，比瞎猜快得多。
