直接往RabbitMQ塞请求不算削峰，因其仅转移压力未控制源头洪峰；RabbitMQ的basic.qos只限消费者预取量，对API层无感，队列堆积时API已崩溃；go-zero的rate.Limiter无缓冲、不削峰；真削峰需用按P99×QPS×容忍时长计算容量的buffered channel配合select+default非阻塞写。
为什么直接往 RabbitMQ 里塞请求不算削峰
它只是把压力从 API 层转移到了 MQ 层，没解决源头洪峰问题。RabbitMQ 的 basic.qos 只控制消费者端预取数量，对上游 HTTP 请求完全无感；队列堆积时，API 已经被压垮，连接超时、channel 关闭、内存溢出都可能发生。
常见错误现象：channel closed、connection reset by peer、RabbitMQ 管理界面显示 queue length 持续上涨但 consumer utilisation 接近 0。
- RabbitMQ 不提供 HTTP 接口级限速能力，无法感知 API 层瞬时脉冲
- go-zero 的
rate.Limiter是令牌桶，拒绝超出部分（返回 429），不缓存、不削峰 - 单纯依赖 MQ，等于放弃背压——上游不知道下游是否健康、是否积压、是否已断连
用 buffered channel 做首道蓄水池的关键操作
buffered channel 不是自动限流器，而是有界缓冲区。它的作用不是控速，而是控深：最多允许多少请求在系统里“排队待处理”。容量设错或使用方式不对，反而会放大雪崩风险。
必须满足三个条件才真正有效：
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
make(chan *Request, N)中的N要按公式算：P99 处理耗时 × 峰值 QPS × 可容忍积压时长（例如 50ms × 200 QPS × 2s ≈ 400） - 上游写入必须用
select+default，绝不能ch 直接阻塞 - 下游消费 goroutine 必须带
recover，且要主动检测 RabbitMQ 连接状态，连不上就暂停读、发告警
错误示例：ch —— channel 满后 goroutine 卡死，上游 HTTP handler 阻塞，连接堆积，最终触发负载均衡器超时踢出节点。
RabbitMQ 端必须调的几个配置点
MQ 不是甩手掌柜，几个关键配置不设好，“削峰”就变成“假削峰”甚至“埋雷”。
- 启用
publisher confirms：确保每条消息落盘成功，否则网络抖动会导致消息丢失，上游还误以为已成功 - 设置
queue.max-length和queue.overflow = drop-head：防止队列无限膨胀拖垮 broker 内存 - 消费者端开启
basic.qos（prefetch count 控制在 1~10），避免单个 consumer 积压过多未 ack 消息，导致吞吐下降
没开 publisher confirms 时，你看到的 AMQP: channel error 或 unexpected close 往往就是消息静默丢失的信号。
如何让背压信号从 MQ 传回接口层
真正的削峰需要闭环反馈：MQ 不可用、队列满、confirm 失败，这些状态必须能影响到接口层的接收决策。否则，上游还在狂塞，下游早已失联。
- 在 consumer goroutine 里监听 RabbitMQ 连接健康状态（如通过
connection.IsClosed()或心跳检测） - 一旦发现异常，立即关闭 channel 读取，并广播状态（比如写入一个
atomic.Bool标志位） - 接口 handler 在
select写入前先检查该标志，若 MQ 不可用，则直接降级（如记录日志 + 返回 503）
容易被忽略的是：buffered channel 容量再大，也扛不住持续断连下的盲写。没有这个闭环，所谓“削峰”只是把崩溃延迟了几秒而已。
