一眼看出是队列积压还是消费延迟：若messages_ready持续上涨而messages_unacknowledged基本稳定，属真积压；若messages_ready稳定而messages_unacknowledged持续升高，则为消费延迟，本质是消费者卡在处理未ack。
怎么一眼看出是队列积压还是消费延迟
直接看 messages_ready 和 messages_unacknowledged 两个指标，别只盯着总消息数。Ready 是待消费的，Unacked 是已发给消费者但还没回 ACK 的。如果 Ready 持续上涨、Unacked 基本不动，才是真积压；如果 Ready 稳定、Unacked 越堆越高，说明消费者卡在处理环节没发 ACK，本质是消费延迟。
用这个命令快速验证：
rabbitmqctl list_queues name messages_ready messages_unacknowledged
常见误判场景：
- 消费者因数据库慢查询卡住，
Unacked持续涨，监控却显示“队列空” - RabbitMQ 启用了
prefetch_count=1，但消费者处理时间波动大，导致大量消息被预取后“挂起” - 消费者进程 OOM 被 kill，但 RabbitMQ 还没感知到连接断开，Unacked 消息长期滞留
goroutine 泄漏会让队列“假性积压”
很多服务把消息消费逻辑丢进 goroutine 处理，却不控制生命周期——结果 worker 数没变，但后台堆积了成百上千个卡在 或 select 的 goroutine，它们占着内存、抢着调度器，反而拖慢真实消费速度。
检查方法：
- 访问
/debug/pprof/goroutine?debug=2，搜chan receive、semacquire、netpoll，停留超 5 秒的都可疑 - 对比
runtime.NumGoroutine()和runtime.MemStats{}.StackInuse：如果前者 5000+、后者 200MB+，大概率有泄漏 - 用
pprof.Lookup("goroutine").WriteTo(w, 1)导出堆栈，过滤掉runtime.gopark占比过高的服务
典型泄漏代码：
go func() {
for range ch { // ch 永远不 close，goroutine 永不退出
process()
}
}()
worker pool 缓冲区设多大才不翻车
缓冲区不是越大越好，它是内存水位阀，不是性能加速器。设错会把问题从队列转移到内存或 GC 上。
推荐计算公式：buffer_size = QPS × avg_task_duration × 1.5
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
例如：QPS=300、平均处理 80ms → 缓冲设 36，上线后必须盯紧 len(jobs) 和 GC pause 时间。
踩坑点：
- 缓冲区过小（如
make(chan Task, 10)）：生产者频繁阻塞在jobs ，触发上游重试或本地切片缓存，内存从 goroutine 转移到主协程 - 缓冲区过大（如
make(chan Task, 5000)）：任务对象长期滞留在 channel 底层环形队列，GC 无法回收其引用的*http.Request等大对象 - 没配
context.WithTimeout：单个慢任务卡死整个 worker，后续任务全堵在 channel 里
为什么加机器不一定能缓解积压
盲目扩 consumer 实例，可能只是把问题从“单点积压”变成“全局泄漏”。尤其当每个实例都存在 goroutine 泄漏、channel 未关闭、context 未透传时，10 个实例 = 10 倍泄漏速度。
更关键的是，RabbitMQ 的 prefetch_count 默认是无限的。如果没显式设置，一个消费者可能预取几千条消息，结果自己处理不过来，其他消费者根本分不到活——看起来扩了 3 倍机器，实际只有 1 台在干活。
必须同步调整的配置：
- RabbitMQ 端：为每个 consumer 设置合理
prefetch_count（建议 10–50，视单条处理耗时定） - Go 代码端：每个 worker 必须用
ctx, cancel := context.WithTimeout(...)包裹job.Process()，处理完立刻cancel() - 监控项：除了队列长度，必须采集
unacked_per_consumer和goroutines_per_instance
真正有效的扩容，是先让单实例稳定在 Unacked ≈ prefetch_count × 0.7，再横向扩展。否则只是把火种撒向更多地方。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
