根本原因是Redis Pub/Sub缓冲区溢出：订阅者消费慢或未及时读取消息，导致消息堆积撑爆客户端socket缓冲区，触发TCP连接被操作系统终止，表现为Connection reset by peer或静默掉线。
为什么订阅者会被强制踢下线？
根本原因是 Redis Pub/Sub 的缓冲区溢出：当订阅者消费速度跟不上发布频率，或长时间不调用 Receive()（Go）/ get_message()（Python）时，Redis 会把消息暂存在客户端 socket 缓冲区。一旦超出内核 TCP 缓冲区上限（通常几 MB），连接会被服务端主动断开，返回 Connection reset by peer 或静默掉线。
- 不是 Redis 主动“踢人”，而是底层 TCP 连接因写满缓冲区被操作系统终止
- Java Lettuce 中表现为
RedisCommandTimeoutException或ChannelClosedException - Go
redis/v9中常伴随read: connection reset by peer或EOF错误 - redis-cli 使用
--raw时若终端卡住不动，大概率就是缓冲区已满、连接挂了
如何避免缓冲区溢出导致掉线？
核心是让客户端持续、及时地读取消息，不能让消息在管道里堆积。关键不在“加大缓冲区”，而在“别让它满”。
- 不要在
Receive()后做耗时同步操作（如 HTTP 请求、DB 写入），必须先收完再处理；否则下次Receive()前缓冲区就可能爆掉 - Go 中推荐用
pubsub.ReceiveContext(ctx)配合超时控制，避免无限阻塞；收到消息后立即交给 goroutine 异步处理 - Python redis-py 中，
pubsub.get_message(timeout=0.1)比listen()更可控——后者是纯阻塞，前者可设短超时+轮询，防止卡死 - Spring Boot 的
RedisMessageListenerContainer默认使用TopicSubscription，需检查subscriptionExecutor是否配置了足够线程数，否则消息积压在 listener queue 里也会间接拖慢接收
连接层怎么稳住不掉？
光靠应用层消费快还不够，网络和连接配置也得跟上。Redis 本身不保活，全靠客户端自己维持。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 启用 TCP keepalive：Go
redis.Options中设置ConnKeepAlive: 30 * time.Second；Python redis-py 用socket_keepalive=True, socket_keepalive_options={...} - 禁用 Nagle 算法（
TCP_NODELAY），减少小包合并延迟，让心跳和消息更快发出 - 不要复用同一个
*redis.PubSub实例跨多个 goroutine 调用Receive()—— 它不是并发安全的，竞争会导致丢消息或 panic - 连接池对 Pub/Sub 无效：Pub/Sub 必须独占连接，
redis/v9的Subscribe()会自动从连接池取新连接并标记为“专用”，别手动塞进池子
监控与兜底怎么做？
掉线无法完全杜绝，但要让它可发现、可恢复，而不是静默失联。
- 定期执行
PUBSUB NUMSUB channel_name查看活跃订阅数突降，配合日志判断是否批量掉线 - Go 客户端应在
Close()前检查pubsub.Channel()是否已关闭，避免重复 close 导致 panic - 上线时加心跳频道：每 30 秒
PUBLISH heartbeat "ping"，订阅端收到后更新本地 last_seen 时间，超时未收则触发重连逻辑 - 别依赖
redis-cli PUBSUB CHANNELS查实时状态——它只返回当前连接的频道，不反映已断开但服务端尚未清理的残留订阅（虽然实际影响不大）
真正难的不是“怎么连上”，而是“怎么一直在线且不丢消息”。缓冲区、线程模型、连接生命周期这三环任何一个松动，都会在高吞吐场景下暴露出来。
