so_reuseport是go处理大规模socket连接的核心机制，通过内核按四元组哈希分发新连接至多个监听进程，结合gomaxprocs调优、cpu亲和绑定及独立sync.pool隔离，实现连接、cpu、softirq与fd的多维资源分摊，避免单点瓶颈。
Go 处理大规模 Socket 连接时，资源隔离不是靠“切分内存”或“虚拟化进程”，而是通过操作系统级机制 + Go 运行时协同，把连接、CPU、内核软中断、文件描述符等关键资源分摊到不同执行单元，避免单点争抢和雪崩。核心在于让每个连接不互相拖累，也不挤占系统全局资源。
SO_REUSEPORT 多监听器分流连接
当连接数超过 5000，单个 listen socket 的 accept 队列会成为瓶颈：所有新连接都排队等待一个内核锁，CPU 花在争抢上，而不是干活。启用 SO_REUSEPORT 后，多个 Go 进程（或多个 runtime.P）可同时 bind 同一端口，内核按四元组（源IP+端口+目标IP+端口）哈希分发连接，天然实现连接负载均衡。
- 必须用 net.ListenConfig{Control: …} 手动设置 socket 选项，
http.ListenAndServe不支持 - 每个进程启动前调用
syscall.SetsockoptInt(fd, syscall.SOL_SOCKET, syscall.SO_REUSEPORT, 1) - 搭配
runtime.GOMAXPROCS(runtime.NumCPU())，确保每个 listener 绑定到独立 OS 线程 - Docker/K8s 中需显式配置
hostNetwork: true或hostPort，否则网络命名空间隔离会导致复用失效
连接级资源绑定与 CPU 亲和
连接不是均匀分布的，尤其在长连接场景下，某些连接可能持续活跃、消耗大量 recv buffer，导致对应 CPU 核上的 NET_RX softirq 持续高负载。将特定连接绑定到固定 CPU，能提升缓存局部性，降低跨核中断迁移开销。
- 用
taskset -c N ./server启动进程，限制其只在指定 CPU 核运行 - 配合 SO_ATTACH_REUSEPORT，让不同连接哈希到不同 CPU，使 softirq 分散执行
- 避免 goroutine 在 handler 中阻塞读写——若 socket 缓冲区积压，softirq 会被反复触发，不管 CPU 是否绑定
文件描述符与内存池的隔离管理
百万连接意味着百万级 fd 和配套内存结构（如 bufio.Reader）。若全部混用全局池，容易因 GC 扫描范围过大或竞争加剧而抖动。应按连接生命周期或业务类型做轻量级隔离。
- 为不同连接类型（如心跳连接、数据通道、管理连接）创建独立的 sync.Pool，避免大对象污染小对象池
- Accept 后立即调用
conn.SetReadBuffer(64 * 1024)和conn.SetWriteBuffer(64 * 1024)，防止内核动态扩容引发延迟毛刺 - 禁用 HTTP/2（除非必须），因其 stream 状态管理在短连接或低频连接场景下显著增加 GC 压力和 goroutine 数量
- 超时控制统一设在
http.Server实例上（ReadTimeout/WriteTimeout/IdleTimeout），而非 handler 内 context 控制——后者无法中断底层 read/write 系统调用
进程级隔离替代协程级硬隔离
Go 协程本身不提供资源边界（如内存上限、fd 上限），强行在单进程内做“软隔离”效果有限。更有效的方式是用多进程承载连接，由外部协调（如主从模式或 IPC 分发）。
- 主进程仅负责 accept，通过 UNIX socket 将已建立连接的 fd 传递给工作子进程（使用
SCM_RIGHTS） - 各子进程持有专属连接集，独立配置超时、buffer、pool，故障不影响其他进程
- 适合低 RPS、高保活的场景（如 IoT 心跳网关），实测可将单机连接容量提升 3–5 倍
- 避免用 goroutine 泄漏型逻辑（如未关闭 resp.Body、无 timeout 的 http.Client.Do），这类问题在多进程下仍会逐个击穿
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
