Go语言TCP套接字每秒200万短消息发送性能瓶颈排查求助

老兄，你这个情况我之前做高并发消息系统时实打实踩过坑——理论吞吐量明明够得着，但实际跑起来差了几十倍，而且消息大小影响不大，大概率是代码里的阻塞点没找对，绝非TCP缓冲的锅。给你拆解几个核心排查方向，再对应上优化方案：

一、先揪出发送/接收端的阻塞元凶 #

1. 同步单goroutine发送的致命坑 #

如果你的代码是每条消息单独调用conn.Write()，还用单goroutine循环发送，那根本不可能跑起来。哪怕开了Nagle算法，单goroutine的调度开销+频繁的用户态到内核态切换，每秒撑死也就几万条，比如这种错误写法：

// 反面教材：单goroutine同步逐条发送
for i := 0; i < 2000000; i++ {
    _, err := conn.Write(msg)
    if err != nil {
        // 错误处理
    }
}

优化方案：

• 批量发送：攒够一批消息（比如100条或凑够1MB）打包成一个大字节切片再调用Write，大幅减少系统调用次数（注意别攒太满导致延迟超标）。
• 单goroutine专职发送：其他业务goroutine把消息塞到带缓冲的channel里，由一个专门的goroutine负责从channel取消息、批量发送（避免多goroutine并发写TCP连接的线程安全问题）。

2. 接收端拖慢整个链路 #

TCP是流式协议，如果接收端处理消息的速度跟不上发送端，内核接收缓冲区满了之后会触发滑动窗口缩小，发送端直接被阻塞。比如接收端用单goroutine同步读消息，还每条都做复杂计算，那发送端肯定发不动。

快速排查法：
临时把接收端改成「只收不处理」——读到字节直接扔掉，看吞吐量能不能上去。如果能，那百分百是接收端处理逻辑的问题。

优化方案：

• 用goroutine池处理消息：把读到的消息丢进带缓冲的channel，启动多个worker goroutine并行处理。
• 批量读取+用户态拆包：不要每次读一条消息，而是用conn.Read()读一大块字节到缓冲区，再在用户态自己做消息边界拆分（比如用固定长度前缀、特殊分隔符标记每条消息）。

二、Go网络栈的针对性配置优化 #

1. 放大TCP缓冲区 #

默认的TCP发送/接收缓冲区太小，撑不起高吞吐量。手动调大试试：

// 设置发送/接收缓冲区为64MB（根据实际机器内存调整）
err := conn.SetWriteBuffer(64 * 1024 * 1024)
if err != nil {
    // 错误处理
}
err = conn.SetReadBuffer(64 * 1024 * 1024)
if err != nil {
    // 错误处理
}

注意：这个值受系统内核参数限制，比如Linux下要先调整net.core.wmem_max和net.core.rmem_max，比如执行sysctl -w net.core.wmem_max=67108864。

2. 排查是否误开代理 #

有时候代码间接依赖了HTTP代理，会导致TCP连接被劫持，性能直接暴跌。确保你的TCP连接是用net.Dial或net.Listen直接建立的，没有经过任何代理。

三、消息序列化的隐性开销 #

你说消息大小影响不大，大概率不是序列化的锅，但还是要排查：如果每条消息都用encoding/json这种慢序列化方式，单goroutine下的序列化开销会直接拖垮发送速度。

优化方案：

• 用二进制序列化：比如encoding/binary手动打包，或者用flatbuffers、capnproto这种零拷贝序列化库。
• 预序列化：提前把所有消息序列化好，或者批量序列化，避免重复序列化的冗余开销。

四、系统层面的硬核排查 #

1. 调整Linux内核参数 #

这些参数对TCP高吞吐量影响极大：

• net.ipv4.tcp_tw_reuse = 1：复用TIME_WAIT状态的连接
• net.ipv4.tcp_max_syn_backlog = 10240：增大SYN队列长度，处理高并发连接
• net.core.somaxconn = 10240：增大监听队列最大长度
• net.ipv4.tcp_syncookies = 1：防止SYN洪水攻击（按需开启）

2. 用工具定位阻塞点 #

• 用pprof分析：启动程序时加-cpuprofile cpu.prof，跑一会儿后用go tool pprof cpu.prof查看CPU占用最高的函数，或者有没有阻塞的goroutine。
• 用netstat -tunap看TCP连接状态：如果SEND-Q持续堆积，说明发送端发了但内核没发出去；如果RECV-Q堆积，说明接收端没及时处理。

快速验证方案 #

先写个极简的测试程序排除业务逻辑干扰：

• 发送端：单goroutine批量打包消息，循环调用conn.Write()，统计每秒发送字节数。
• 接收端：单goroutine循环读大缓冲区，直接扔掉字节，统计每秒接收字节数。
  如果这个极简程序能接近100MB/s的吞吐量，那就是你的业务代码有阻塞点；如果还是不行，就盯着系统配置和Go网络栈查。

内容的提问来源于stack exchange，提问作者user3526468