revel不内置消息队列，需手动集成rabbitmq等中间件；其设计哲学强调轻量与无状态，mq属业务层职责，框架刻意留白以避免运维负担和耦合。
Revel 本身不内置消息队列支持，也没有 revel mq 这类命令或模块。要实现异步解耦，必须手动集成外部消息中间件（如 RabbitMQ、Kafka），并在控制器或服务层显式调用生产者/消费者逻辑——这不是框架能力，而是你代码的责任。
为什么 Revel 不提供原生 MQ 集成
Revel 的设计哲学是「无状态 + 轻量中间件」：它把 session 存 cookie、缓存交 memcached、静态资源甩给 Nginx。消息队列属于业务级异步设施，框架层刻意留白。强行封装会增加运维负担（比如连接池管理、重试策略、死信处理），反而让多数简单场景变重。
- Revel 的
Filter链是同步执行的，无法自动将请求“塞进队列后立刻返回” - 没有
BeforeConsume或AfterPublish这类钩子，所有消息生命周期控制都得自己写 - 热编译（
revel run）下频繁重启会导致未确认消息丢失，除非你用持久化 channel + ack 机制兜底
RabbitMQ 生产者怎么嵌进 Revel 控制器
别在 Controller 方法里直接连 RabbitMQ——连接对象不能跨 goroutine 复用，而 Revel 每个请求都在独立 goroutine 中运行。正确做法是初始化一个全局复用的 *amqp.Connection 和 *amqp.Channel，在 app/init.go 的 init() 函数中建立并缓存：
var rabbitConn *amqp.Connection
var rabbitChan *amqp.Channel
func init() {
revel.InterceptFunc(checkRabbitMQ, revel.BEFORE)
}
func checkRabbitMQ(c *revel.Controller) revel.Result {
if rabbitConn == nil {
var err error
rabbitConn, err = amqp.Dial("amqp://guest:guest@localhost:5672/")
if err != nil {
revel.ERROR.Printf("RabbitMQ connect failed: %v", err)
return c.RenderError("MQ unavailable")
}
rabbitChan, err = rabbitConn.Channel()
if err != nil {
revel.ERROR.Printf("RabbitMQ channel failed: %v", err)
return c.RenderError("MQ channel error")
}
}
return nil
}
然后在控制器里发消息时只用 rabbitChan.Publish()，不新建连接。注意：
- 务必设置
mandatory: true和immediate: false，避免消息被交换机静默丢弃 - 不要在
defer rabbitChan.Close()——这会关掉全局 channel，后续请求全挂 - 若用 Docker，确保应用容器和 RabbitMQ 容器在同一个 network，且
host填的是服务名（如rabbitmq），不是localhost
消费者不能跑在 Revel 进程里
Revel 是 HTTP 请求驱动的，没有常驻后台任务机制。RabbitMQ 消费者需要持续监听队列，一旦放进 Controller 就会随请求结束而终止。必须拆成独立进程：
- 新建
cmd/consumer/main.go，用amqp.Consume()长连接拉取消息 - 消费逻辑中调用你的业务函数（比如
models.ProcessOrder()），而非依赖 Revel 的c.Render等 Web 特性 - 用
supervisord或systemd托管该进程，配置自动重启和日志轮转 - 若需通知 Web 层（如更新订单状态后刷新页面），走 WebSocket 或轮询 API，别反向调 Revel 的 HTTP 接口
最容易被忽略的是错误隔离：RabbitMQ 消费失败时，不能让整个 Revel 应用 panic；而消费者进程崩溃时，也不能影响 HTTP 接口可用性。两者必须物理分离、错误自治、监控独立——这才是解耦的真实代价。
