Revel 框架不内置消息队列，需集成 RabbitMQ；仅用 goroutine 缺乏生命周期管理、持久化、重试与跨实例分发能力；正确做法是 Controller 仅发送消息，消费者独立部署并实现幂等处理。
Revel 框架本身不内置消息队列支持，必须手动集成；直接在 Controller 里起 goroutine 虽快，但会丢失生命周期管理、失败重试和可观测性——这不是异步，只是把阻塞藏得更深了。
为什么不能只用 goroutine + channel 做异步任务
很多人看到 Revel 的 NewAsyncTask 就以为能替代消息队列，其实它只解决“不卡主线程”这一个点：
- goroutine 一旦 panic 或未 recover，整个请求上下文就丢了，错误无法捕获到监控系统
- 进程重启时，正在执行的 goroutine 全部消失，任务直接丢失（无持久化）
- 没有重试机制：第三方 API 临时超时？网络抖动？全靠运气
- 无法跨实例分发：单机 goroutine 无法被其他 Revel 实例消费，水平扩展失效
-
Submit返回的results和errorschannel 是内存级通信，不支持延迟、优先级、死信等语义
推荐接入 RabbitMQ 的最小可行路径
用 RabbitMQ 作为 Broker，不是为了炫技，而是因为它能补上 goroutine 缺失的所有关键能力。接入只需三步，且全部可复用：
- 在
app/init.go中初始化连接池：amqp.Dial+channel.Confirm模式开启发布确认，避免消息静默丢失 - 封装统一的发送函数
mq.PublishEvent(exchange, routingKey, payload)，自动注入event_id和trace_id（从 Revel 的c.Request.Context()提取） - 消费者端独立部署（不和 Revel Web 进程混跑），用
channel.Qos(1, 0, false)控制预取，防止某条消息卡住整个队列
注意：不要把消费者写进 Revel 的 app/controllers 目录下——它不是 HTTP handler，不该走 Revel 的路由和拦截器链。
如何让 Revel Controller 安全触发 MQ 任务
核心原则：Controller 只负责“发出去”，不关心“谁来干”“干没干成”。典型模式如下：
func (c *OrderController) Submit() revel.Result {
order := &models.Order{...}
if err := models.Save(order); err != nil {
return c.RenderError(err)
}
// 关键：只发消息，不等结果
if err := mq.PublishEvent("order.exchange", "order.created", map[string]interface{}{
"event_id": uuid.New().String(),
"order_id": order.ID,
"user_id": order.UserID,
}); err != nil {
revel.ERROR.Printf("failed to publish order.created: %v", err)
// 此处不 return error！用户已下单成功，后台任务失败应告警而非回滚
}
return c.RenderJSON(map[string]string{"status": "accepted"})
}
- 永远用
PublishEvent而非裸调channel.Publish：前者封装了 JSON 序列化、content-type 设置、错误日志格式化 - 不要在 Controller 里做任何消费逻辑——哪怕只是“发完立刻查 MQ 是否收到”，这违反解耦原则
- 如果业务强依赖某一步结果（如风控拦截），应走同步 RPC 或回调通知，而不是塞进 MQ 等轮询
容易被忽略的幂等与重试边界
Revel 接入 MQ 后，最常翻车的地方不在发送端，而在消费端的幂等设计：
- RabbitMQ 的 at-least-once 投递语义意味着：同一条消息可能被投递 2 次甚至更多，
delivery.Tag不是唯一 ID，不能当幂等键用 - 正确做法：消费逻辑开头就检查
event_id是否已处理（查 DB 或 Redis），已存在则ack并跳过 - 不要依赖 Revel 的 session 或 cookie 做幂等判断——消费者是独立进程，无 HTTP 上下文
- 重试策略必须由消费者自己控制：比如用
x-dead-letter-exchange配置死信队列，3 次失败后转入人工干预队列，而不是让 Revel 主动重发
真正难的从来不是“怎么把消息发出去”，而是“怎么确保它只被认真执行一次”。这个责任不在 Revel，也不在 RabbitMQ，而在你写的那几行消费代码里。
