Golang异步任务处理使用消息队列实现解耦-Golang-PHP中文网

真解耦必须走持久化消息队列；http handler只序列化消息并写入带缓冲channel，由独立goroutine调publishtorabbitmq统一重试、重建连接、失败落库。

golang异步任务处理使用消息队列实现解耦

goroutine 直接发 HTTP 或调函数不是异步任务解耦，只是把同步操作藏进后台——下游一挂，协程堆积，消息静默丢失。真解耦必须走持久化消息队列。

为什么不能在 HTTP handler 里直接 `ch.Publish()`

HTTP 响应一旦写出（w.WriteHeader 或 w.Write），底层连接可能被复用或关闭。此时再调 ch.Publish()，轻则 panic，重则消息无声丢弃，且无日志可查。

handler 只做两件事：序列化消息体、写入带缓冲的 chan []byte（如 make(chan []byte, 1000)）
用独立 goroutine 持续消费该 channel，并在封装函数 publishToRabbitMQ() 中统一处理重试、连接重建、失败落库
绝对禁止在 Gin/Echo 中间件或 handler 内直接调 amqp.Connection.Channel() 或 ch.Publish()

`amqp.Dial` 连接必须带超时和心跳

每次 amqp.Dial 都新建 TCP 连接，高并发下很快耗尽本地端口，报 connect: cannot assign requested address；DNS 解析失败时还默认无限阻塞。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

用 sync.Once 初始化全局 *amqp.Connection
URL 中必须含 connect_timeout=5 和 heartbeat=30
监听 conn.NotifyClose，触发后清空旧连接，用指数退避（1s → 2s → 4s）重建
Channel 按需创建、用完即 ch.Close()；泄漏会导致 RabbitMQ 报 channel error: too many channels

发消息不设 `DeliveryMode: amqp.Persistent` 就等于没发

DeliveryMode: amqp.Transient 意味着消息只存在内存，Broker 重启或断电全丢——这不是异步，是“假装发了”。

声明队列时必须传 durable: true，否则 DeliveryMode: amqp.Persistent 无效
amqp.Publishing 中必须设 DeliveryMode: amqp.Persistent 和 mandatory: true
mandatory: true 让路由失败（如 exchange 不存在、binding 缺失）时立即返回 error，而不是静默丢弃

消费者不手动 `defer msg.Ack(false)` 就是埋雷

RabbitMQ 的 consumer 不是“收到就干”，而是“收到→干活→显式 Ack→再收下一条”。很多人把 msg.Ack(false) 写在业务逻辑中间，一旦前面 panic、return 或数据库报错，Ack 就被跳过——消息被 RabbitMQ 一直 hold 住，最终积压、触发流控、拖垮整个 channel。