Beego无内置削峰能力，限流中间件LimitFilter因单机内存计数、无分布式协同、固定窗口及忽略处理时长而易失效；RabbitMQ需manual ACK、合理prefetch与队列熔断；Controller须校验前置、禁直写DB、返回明确状态；Redis+Lua限流需原生命令调用。
Beego 框架本身不内置削峰能力，所有削峰必须靠外部组件或手动编码实现；直接在 Controller 里加 time.Sleep 或简单计数器，线上必崩。
为什么 Beego 的限流中间件容易失效
Beego 提供的 LimitFilter 是基于内存计数的单机限流，不支持分布式场景。大促时流量打到多个 Beego 实例，每个实例独立计数，实际通过率会远超预期阈值。
常见错误现象：LimitFilter 配置了每秒 1000 请求，但压测发现集群总吞吐达 4000 QPS 仍无拒绝 —— 因为 4 台机器各自只拦自己那 1000。
- 它不共享状态，无法与 Redis、etcd 等后端协同
- 不支持滑动窗口，仅支持固定窗口，易被脉冲流量穿透
- 未考虑请求处理时长，对慢接口无保护（比如一个请求耗时 2s，
LimitFilter仍按 1s 计数） - 若用
beego.InsertFilter注册，但没设beego.FILTER_BEFORE_ROUTER，可能被路由匹配绕过
RabbitMQ + manual ACK 是 Beego 削峰最稳路径
Beego 作为 HTTP 入口，只负责快速接收并投递消息，把真正耗时的下单、扣库存逻辑移出主线程。关键不是“用不用 MQ”，而是“怎么用才不堆峰”。
必须满足三个硬条件，否则 RabbitMQ 反而变成故障放大器：
-
acknowledge-mode必须设为manual，Spring Boot 默认 auto，Beego 集成 RabbitMQ 时也常忽略这点 —— 若不显式调用channel.Ack()，Broker 会持续推送，消费者内存爆满 -
prefetchCount要和 Beego worker 的实际处理能力对齐：比如你 DB 连接池是 10，每个消息需占 1 连接，则prefetchCount ≤ 10；设成 50 就必然排队阻塞 - 队列声明时必须加
x-max-length（如 10000）和x-overflow: reject-publish-dlq，否则洪峰一来磁盘写满，RabbitMQ 直接挂掉
示例关键配置（Beego 启动时初始化）：
ch.Qos(10, 0, false) // prefetchCount = 10，全局生效
_, err := ch.QueueDeclare("seckill_queue", true, false, false, false, amqp.Table{
"x-max-length": 10000,
"x-overflow": "reject-publish-dlq",
})
Beego Controller 层必须做的三件事
不能把削峰逻辑丢给下游就不管了。Beego 接口响应快慢，直接影响前端重试行为 —— 响应越慢，用户越容易狂点，雪球越滚越大。
- 所有秒杀/抽奖类接口，返回体必须带明确状态码和提示，例如
{"code":202,"msg":"已入队，结果稍后通知"}，禁止返回 500 或空响应 - 必须校验请求来源合法性（如 JWT 中的
promo_id、user_id），且校验要前置到Prepare方法中，避免非法请求进业务逻辑 - 接口内禁止任何数据库直写或远程同步调用；所有耗时操作统一走
amqp.Publish()投递，且投递失败要降级为本地内存队列（兜底，防 MQ 不可用）
典型错误写法：o := orm.NewOrm(); o.Read(&order) 出现在秒杀接口里 —— 这等于把削峰前功尽弃。
Redis + Lua 是 Beego 最轻量的分布式限流补位方案
当 RabbitMQ 不可用，或某些非核心接口（如活动页曝光统计）需要快速限流时，可临时启用 Redis 限流。但注意：Beego 自带的 cache 包不支持原子 Lua 脚本，必须手写 redis.Conn.Do() 调用。
核心 Lua 脚本（存为 rate_limit.lua）：
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local current = tonumber(redis.call('GET', key) or "0")
if current + 1 > limit then
return 0
else
redis.call("INCR", key)
redis.call("EXPIRE", key, window)
return 1
end
Beego 中调用要点：
- Key 必须带业务维度，如
"rate:promo:" + strconv.Itoa(promoId)，不能只用固定字符串 - 窗口时间别设太短（如 1s），大促时 Redis RT 波动大，1s 窗口易误杀；建议用 10s 或 60s
- 脚本返回 0 时，必须立即
this.Abort("429")，不能继续往下走 - 别依赖 Beego 的
cache.BM，它不保证 Lua 原子性，要用原生redis.Conn
真正难的从来不是“怎么配”，而是压测时发现：DB 连接池撑不住 800 QPS，但 RabbitMQ prefetch 设 8 就吞吐不足 —— 这时候得回头调小 Beego 的 MaxProcs 和 Listen.Graceful，让资源分配更紧致。
