buffered channel是Gin削峰的第一道防线，因其作为有界缓冲区可暂存瞬时洪峰、摊平流量节奏；需按P99耗时×峰值QPS×可容忍积压时长公式设容量，并配合select+default非阻塞写入及带recover的健壮消费者。
直接往 RabbitMQ 塞请求不是削峰，是转移压力；用 rate.Limiter 也不是削峰，是限流拒绝。真削峰必须在 API 入口做有界缓冲，且缓冲区容量、写入方式、消费逻辑三者缺一不可。
为什么 buffered channel 是 Gin 削峰的第一道防线
HTTP handler 是短生命周期的 goroutine，但业务处理（如调用下游服务、写 DB）可能耗时几十到几百毫秒。若不加缓冲，每秒 2000 次请求就会瞬间拉起 2000 个 goroutine，调度开销和内存占用会指数级上升——这不是高并发，是自爆。
buffered channel 的作用不是“让系统更快”，而是“让系统不死”：它把瞬时洪峰暂存在内存里，把突发流量摊平成可消化的节奏。
- 容量必须按公式算：
P99 处理耗时 × 峰值 QPS × 可容忍积压时长（例如 80ms × 1500 QPS × 1.5s ≈ 180） - 不能设成
make(chan *Request, 10000)这种拍脑袋数字，否则 OOM 风险翻倍 - channel 是内存结构，不是持久化队列，超时未消费的数据会丢失，所以它只适合“短时缓冲”，不是“长期堆积”
Gin 中间件里怎么安全写入 buffered channel
核心原则：绝不能阻塞 handler。一旦 channel 满，必须立刻丢弃或降级，不能让 HTTP 连接卡住。
错误写法：ch —— channel 满时 goroutine 挂起，连接堆积，负载均衡器超时踢出节点
正确写法：用 select + default 实现非阻塞写入
func PeakShavingMiddleware(ch chan<- *Request) gin.HandlerFunc {
return func(c *gin.Context) {
req := &Request{
Context: c.Copy(), // 注意：不能传原始 *gin.Context
Timestamp: time.Now(),
}
select {
case ch <- req:
c.Status(http.StatusOK)
default:
c.JSON(http.StatusTooManyRequests, gin.H{"error": "system busy"})
}
}
}-
c.Copy()必须调用，否则多个 goroutine 并发读写同一个*gin.Context会导致 panic -
default分支必须返回明确状态码（如429），前端才可触发重试退避 - 不要在
default里尝试 fallback 到 MQ 或 DB，那会放大延迟抖动
RabbitMQ 消费端必须补上的三个配置点
buffered channel 只管入口缓冲，MQ 才是真正的“谷”。但 RabbitMQ 默认配置下，它根本扛不住削峰后的持续写入压力。
- 启用
publisher confirms：否则网络抖动时消息静默丢失，上游还以为成功了 - 设置
queue.max-length = N且overflow = drop-head：防止 broker 内存被撑爆，比丢尾更合理（保证最新请求有机会被处理） - 消费者
basic.qos(prefetch=5)：避免单个 consumer 积压上百条未 ack 消息，导致吞吐骤降
特别注意：prefetch 不是越大越好。设成 100 后，一个慢 consumer 就会让整个队列“假死”，其他 consumer 看不到新消息。
goroutine 池消费时的 recover 和连接健康检查
buffered channel + RabbitMQ 只是管道，真正干活的是消费 goroutine。它们一旦 panic 或连不上 MQ，整个削峰链路就断了。
必须做到：
- 每个 worker goroutine 必须包一层
defer func() { if r := recover(); r != nil { log.Error(r) } }() - 消费前主动 ping RabbitMQ 连接，
conn.IsClosed()为 true 时暂停拉取消息并告警 - 不要依赖
amqp.Dial()的重连机制——它只重连 TCP，不恢复 channel 和 queue 声明
最易忽略的一点：worker 池的大小要和 RabbitMQ 的 prefetch 匹配。比如 prefetch=5，你开了 20 个 worker，实际只有 5 条消息在并发处理，剩下 15 个 worker 在空转抢锁。
