直接用net/http处理消息发布会卡在1k QPS，因默认handler同步阻塞，下游慢（如Kafka抖动、磁盘IO延迟）导致goroutine堆积、内存暴涨甚至OOM；根本原因不是并发不足，而是缺乏流量整形与异步解耦——需分离接收层（HTTP校验+入队）、缓冲层（合理容量channel+背压控制）、消费层（worker pool），实现稳吞吐而非单纯高吞吐。
为什么直接用 net/http 处理消息发布会卡在 1k QPS？
因为默认 HTTP handler 是同步阻塞的，每个请求都在 goroutine 里串行执行写入逻辑（比如落库、发 Kafka），一旦下游慢（如 Kafka 网络抖动或磁盘 IO 延迟），goroutine 就卡住，堆积越来越多，内存暴涨甚至 OOM。Go 调度器扛不住持续积压的 goroutine，不是并发不够，而是没做流量整形和异步解耦。
- 别在 handler 里直接调用
kafka.Producer.SendMessage或db.Exec - HTTP 入口只做校验 + 入队，把耗时操作全扔进后台 worker
- 用带缓冲的 channel 当队列比用第三方 MQ 更轻量，但缓冲区大小必须设合理（比如
make(chan *Message, 10000)） - 缓冲满时要快速失败，返回
HTTP 429 Too Many Requests，而不是让客户端重试加重压力
怎么设计一个不丢消息又可控的发布 pipeline？
核心是三层分离：接收层（HTTP）、缓冲层（channel + backpressure）、消费层（worker pool）。关键不是“高吞吐”，而是“稳吞吐”——在峰值下不雪崩、不丢数据、延迟可预期。
- 接收层用
http.MaxBytesReader限制单次请求体不超过 1MB，防恶意大 payload 撑爆内存 - 缓冲 channel 容量设为预估峰值 QPS × 平均处理延时（例如 5000 QPS × 2s = 10000），超限时立即
http.Error(w, "", http.StatusTooManyRequests) - worker 数量别盲目设成
runtime.NumCPU()，实测 8–16 个足够；太多反而因锁竞争和调度开销降低吞吐 - 每条消息带
id和timestamp，worker 处理失败时写入本地failed_messages.jsonl文件，供后续补偿
sync.WaitGroup 和 context.WithTimeout 在 shutdown 时为什么总出问题？
常见错误是 HTTP server 关闭后，worker 还在往已关闭的 channel 发消息，触发 panic；或者 context 超时太短，正在 flush 的消息被粗暴中断，导致丢失。
- shutdown 流程必须按序：先关 HTTP server → 等待所有新请求拒绝 → close channel → 等待 worker 从 channel 读完剩余消息 → 最后等 worker 退出
- worker loop 要用
select { case msg := ，不能只靠 <code>ctx.Err() != nil判断 - 给 worker 的 context timeout 设为 30s 起步，确保 Kafka batch flush、DB commit 有足够时间，别用 5s 这种拍脑袋值
- channel close 后，worker 读到零值就该退出，别再尝试 send
Kafka producer 配置哪些参数真正影响吞吐？
不是调大 MaxMessageBytes 就能吞得更多，瓶颈常在 TCP 层和批处理策略。默认配置下，单 producer 实例轻松卡在 5k–10k msg/s，调优后可到 50k+。
立即学习“go语言免费学习笔记（深入）”；
-
BatchSize设为 16384（16KB），太小导致频繁发包，太大增加延迟 -
BatchTimeout设为 10ms，平衡吞吐与实时性；设 100ms 会明显增 P99 延迟 -
RequiredAcks用kafka.RequireOne，别用All——后者要等 ISR 全部确认，网络抖动时延迟飙升 - 启用
CompressionType: sarama.CompressionSnappy，CPU 换带宽，实测压缩后 Kafka 网络负载降 60%，吞吐反升
真正难的是压测时模拟真实乱序、重试、断连场景，光跑 hello world 式 producer 看不出问题。buffer 溢出、Kafka leader 切换、DNS 泛洪这些，都得在线上灰度验证过才算数。
