消息积压本质是消费速率断崖式塌陷，需先止血再根治：通过Messages Ready与Unacked对比快速定位消费者挂起或处理阻塞，结合prefetch count调优、goroutine管控及I/O瓶颈排查实现止损与防复发。
消息积压不是“要不要处理”的问题，而是“已经积压了，现在怎么止损+防复发”的问题。核心动作就两条：立刻缓解消费延迟，同时定位瓶颈点——90% 的积压都卡在消费者端的 I/O 或逻辑阻塞上，而不是 RabbitMQ 本身。
怎么快速判断是消费慢还是生产快？
别先改代码。打开 RabbitMQ Management UI，盯住三个数字：Messages Ready（排队待消费）、Unacked（已发给消费者但未确认）、Rate of Publish 和 Rate of Deliver（每秒发布/投递数）。如果 Messages Ready 持续上涨、Unacked 长期接近 0 或极低（比如始终 ≤ 1），说明消费者根本没在拉消息——大概率是消费者进程挂了、channel 关闭了、或 amqp.Consume 调用后没真正循环读取。
如果 Unacked 高（比如 > 100）且 Messages Ready 还在涨，才是真·消费慢：消息发出去了，但消费者 ACK 太慢或卡在处理里。
- 检查消费者日志里有没有 panic、数据库超时、HTTP 调用 hang 住
- 用
pprof抓 CPU profile，看是不是某个processMessage函数占满一个核 - 查 Go runtime 的 goroutine 数：
runtime.NumGoroutine()如果持续 > 5000，大概率是每个消息启一个 goroutine 没控制并发，导致调度雪崩
prefetch count 设多少才不拖垮消费？
prefetch count 是 AMQP 协议里控制“一次最多发几条消息给消费者”的关键参数。设太小（如 1），网络往返多、吞吐低；设太大（如 1000），消费者内存吃紧、单个 goroutine 卡住会拖慢整组 unacked 消息的确认。
真实经验值：从 10 起调，观察 Unacked 曲线和消费者 GC 压力。若处理耗时波动大（比如 10ms–2s），用 5–20 更稳；若全是轻量计算（50。千万别设成 0（无限制），RabbitMQ 会把所有 Ready 消息一股脑推过去，消费者直接 OOM。
- 设置方式：
channel.Qos(10, 0, false)—— 第一个参数就是 prefetch count - 必须在
channel.Consume之前调用，否则无效 - 它只对当前 channel 生效，多个 consumer 要各自设置
批量确认为什么不能随便开？
启用批量确认（autoAck = false + 手动 channel.Ack() 多条）确实能减少网络 round-trip，但代价是：一旦消费者崩溃，所有已交付未确认的消息都会重回队列，可能重复处理。这不是 bug，是设计取舍。
只有当你满足以下全部条件，才适合批量确认：
- 消息处理逻辑是幂等的（比如写 DB 用
UPSERT，而非INSERT） - 业务能容忍“最多一次”或“至少一次”，不要求“恰好一次”
- 单批大小控制在 10–100 条之间（再大，崩溃后重放成本太高）
- 确认前确保这批消息真的全部处理完了，别漏掉中间某条 panic 导致后续没确认
示例错误写法：for i, msg := range batch { process(msg); if i == len(batch)-1 { ch.Ack(msg.DeliveryTag, true) } } —— 这里用的是 multiple=true，但 delivery tag 必须严格递增且连续，否则会 ACK 错消息。
goroutine 泄漏比性能差更致命
很多积压问题表面是慢，根子是 goroutine 不回收。典型场景：用 go process(msg) 处理每条消息，但 process 里有 http.Get 或 db.Query 没设 timeout，请求卡住 → goroutine 永久阻塞 → 新消息进来又启新 goroutine → 内存涨、调度慢、最后 OOM。
必须做三件事：
- 所有外部调用加 context deadline：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) - 用
sync.Pool复用 heavy 对象（如*json.Decoder、bytes.Buffer），避免高频 GC - 在消费者启动时加 goroutine 监控：
go func() { for range time.Tick(30 * time.Second) { log.Printf("goroutines: %d", runtime.NumGoroutine()) } }()，数值持续上涨就是泄漏信号
最易被忽略的一点：RabbitMQ 的 amqp.Connection 和 amqp.Channel 不是线程安全的，多个 goroutine 并发调用 channel.Publish 或 channel.Ack 会导致 panic 或静默失败——必须用 channel 或 mutex 控制访问。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
