golang长连怎么用
Go中实现长连接需区分HTTP长轮询、WebSocket和TCP。HTTP长轮询需调整Nginx超时并使用context控制;WebSocket需禁用默认心跳、降低缓冲区;TCP需分别设置读写超时、处理粘包并使用指数退避重连。连接管理使用sync.RWMutex和atomic.Bool防止并发panic。
说个常识啊,Go 里头搞“长连接”,可不是调个参数就能万事大吉的。你得先想清楚,你到底用的是哪一类的长连接:是 HTTP 长轮询、WebSocket,还是裸 TCP?这三个玩意儿的底层逻辑差别很大,配置混着用,那基本等于白忙活一场。
HTTP 长轮询:别在 Transport 的 MaxIdleConnsPerHost 上白费力气
我见过不少朋友,一上手就去调 http.Transport.MaxIdleConnsPerHost 或者 IdleConnTimeout,结果发现客户端还在频繁重连。为啥?因为长轮询根本不靠复用连接活着,它玩的就是“单个请求挂住,服务端不返回”。
- 服务端这边,你得显式调用
w.WriteHeader(http.StatusOK)再加上w.(http.Flusher).Flush()。不然客户端收不到响应头,就会一直卡在 CONNECTING 状态动弹不得。 - Nginx 默认的
proxy_read_timeout只有 60 秒,超时就直接把连接给掐断了。所以,必须把这个值调大,比如设置为 300 秒。 - 客户端的情况更典型:不能用
http.Client.Timeout来控制整体耗时,因为响应头一发出去,这个超时就不管用了。正确的做法是用context.WithTimeout来构造 request,然后在读 body 之前,先检查一下ctx.Err()。 - 还有,
json.NewDecoder(resp.Body).Decode()这个操作本身是不感知 context 的。一旦服务端不把数据写完,它就会一直等下去。要么用io.ReadFull,要么自己手动分段读,顺便检查 ctx,这才是稳妥的办法。
WebSocket:别让每个连接都背上一个定时器
如果你用的是 gorilla/websocket,它的默认心跳和定时器在百万连接数下会是一个大坑——runtime.timer 会直接把 CPU 吃光。
- 首要操作是禁用默认心跳:
conn.SetPongHandler(nil)。然后自己用time.Ticker来批量轮询那些活跃的连接状态。 - 把
ReadBufferSize和WriteBufferSize降到 1024 和 512,够用,还能省下不少内存。 - 内网环境如果可信,
Upgrader.CheckOrigin直接返回true就完事了,省掉一次字符串比较的开销。 - 连接 ID 也别用
string当 map key 了,换成uint64,能有效避免哈希和 GC 的压力。
TCP 长连接:超时控制得分开看,读和写是两码事
只设一个 SetKeepAlive(true) 基本没啥用,NAT 或者中间设备照样会把你的连接断掉。真正要关注的,是业务层面能感知到的“活跃”状态。
- 服务端得对每个
net.Conn都调用conn.SetReadDeadline和conn.SetWriteDeadline。时间设置上,要稍微大于心跳间隔(比如心跳 30 秒,deadline 设成 45 秒)。 - 客户端发心跳的时候,别只靠一个
conn.Write就完事了。你得启动一个独立的 goroutine 去读响应,一旦报错立刻重连。 - 重连策略必须用指数退避(1秒 → 2秒 → 4秒……),上限建议设在 30 秒,避免高并发场景下出现雪崩。
- 粘包问题也必须处理。推荐使用定长头方案:前 4 个字节存 body 长度,读取的时候用
io.ReadFull保证拿到的是完整的一帧数据。
连接管理:map 并发写导致的 panic,是高频翻车现场
很多新手直接拿 *net.Conn 往 map[string]*net.Conn 里存,跑起来必 panic,错误信息就是那句经典的 “concurrent map read and map write”。
- 正确的做法是用
map[uint64]*ConnMeta加上sync.RWMutex。在读多写少的场景下,性能损失很小。 ConnMeta结构体里,得嵌一个sync.Once和atomic.Bool,防止多个 goroutine 同时去 close 同一个连接,搞出死锁或者重复关闭来。- 千万注意:不要在
conn.Read()的那个 goroutine 里直接delete(m, id),要通过发信号的方式,交给一个统一的清理协程去处理。 - 定期扫描连接池(比如每 30 秒一次),把那些
LastPingTime.Add(2 * heartbeatInterval).Before(time.Now())的连接清理掉。
老实说,这里头最容易忽视的问题是错误归因。很多人一看连接断了,第一反应不是去查 conn.Read 返回的 io.EOF 或者 net.OpError,而是跑去调 Transport 的参数。方向完全搞反了,只会越调越糟糕。


































