Redis publish 本身不堵塞，超时主因是网络延迟、订阅端消费慢或Redis主线程被fork/慢查询等阻塞；客户端socket_timeout无法控制主线程执行耗时，需监控latest_fork_usec、slowlog及CPU使用率，并避免将Pub/Sub用于高可靠场景。
publish 命令本身不堵塞，但网络或 Redis 主线程卡住会让它“看起来”超时
Redis 的 publish 是一个 O(1) 纯内存操作，只要 Redis 主线程能响应，它就立刻返回。所谓“堵塞”，99% 不是 publish 自身慢，而是它发出去之后，消息卡在了网络链路、订阅端消费不及时、或者 Redis 自身被其他任务拖住——比如正在 fork 子进程做 AOF 重写，或 CPU 被慢查询占满。
常见错误现象：publish 调用耗时突然从毫秒级飙到几百毫秒甚至秒级；客户端日志里出现连接超时或 write timeout；订阅端收不到消息，但 publish 返回值却是 1（表示成功推送到频道）。
- 检查 Redis 是否正经历 fork：执行
info stats，看latest_fork_usec是否 > 500000（500ms），超过 1s 就非常危险 - 确认没有大 key 或慢命令在并发执行：
slowlog get 5和redis-cli --bigkeys必跑 - 观察 CPU：用
top -p $(pgrep redis)看单核是否长期 >95%，Redis 单线程扛不住持续高负载
Python redis-py 客户端的 timeout 设置误区
很多人以为给 redis.Redis(..., socket_timeout=2) 就能控制 publish 超时，其实不对。socket_timeout 只管网络读写阶段，而 publish 的真正耗时发生在 Redis 主线程排队和执行——这个过程不受客户端 timeout 控制。
真正起作用的是 socket_connect_timeout（建连）和 socket_keepalive（保活），但它们不解决主线程阻塞问题。
-
publish调用后卡住，大概率是 Redis 在处理前面堆积的命令，不是网络断了 - 若想感知“发布失败”，得靠监控：比如用
redis-cli --stat观察每秒 command 处理数是否骤降 - 生产环境建议加一层轻量兜底：记录每次
publish的耗时，连续 3 次 >200ms 就触发告警，而不是等超时抛异常
订阅端积压导致发布“变慢”的假象
Redis 发布订阅是纯广播机制，不关心订阅者是否在线、是否来得及消费。但如果订阅端处理太慢（比如 Python 里 p.listen() 循环里做了同步 HTTP 请求），它的 socket 接收缓冲区就会堆积，最终触发 TCP 流控——这时 Redis 写 socket 会被内核阻塞，表现为后续所有命令（包括 publish）延迟升高。
这不是 Redis 的 bug，是 TCP 协议层的正常反馈。
- 用
netstat -s | grep "retransmitted"查重传包，高重传说明下游网络或消费端有问题 - 订阅端必须非阻塞处理：收到消息后立即丢进线程池/队列，不要在
listen()循环里做 I/O - 避免用单个订阅连接监听多个高频频道，不同业务频道尽量拆成独立连接，防止单点拖垮
别把 Redis Pub/Sub 当 MQ 用，尤其对可靠性有要求时
Redis 的发布订阅没有消息确认、无持久化、不保证顺序、断连即丢消息。当网络抖动或订阅端重启，中间发布的消息就彻底消失——这时候你再调优 publish 超时也没意义。
如果你需要“至少一次投递”或“消息堆积能力”，publish/subscribe 从设计上就不该是首选。
- 替代方案：用
LPUSH + BRPOP模拟队列，消息可落盘、可 ack、可重试 - 更重场景直接上专业 MQ（Kafka/RocketMQ），Pub/Sub 只适合内部通知、实时广播类低可靠需求
- 一个典型坑：用 Pub/Sub 实现订单状态推送，结果促销高峰时消费者崩了 2 秒，几百单状态丢失，查日志发现
publish全成功——其实是设计误用
真正难的从来不是怎么让 publish 更快，而是想清楚：这条消息丢了能不能接受？下游有没有能力跟上节奏？这两个问题没答案，调参和加 timeout 都是白忙。
