如何在 Go 中使用 RabbitMQ 实现消息确认机制（Ack）？

如何在 Go 中使用 RabbitMQ 实现消息确认机制（Ack）？

Go 中 consumer 端必须设 autoAck=false 才能手动 Ack

这里有个关键细节：amqp.Consume 的 autoAck 参数默认是 true。这意味着什么？意味着 RabbitMQ 一旦把消息推送给消费者，就会立刻将其从队列中删除，完全不管消费者后续处理是成功还是失败。这种模式在生产环境中，无异于“裸奔”——万一消费逻辑发生 panic，或者进程意外崩溃，这条消息就彻底消失了。

所以，正确的做法非常明确：必须显式地将 autoAck 设为 false，然后根据业务处理结果，手动调用 channel.Ack() 或 channel.Nack() 来告知 RabbitMQ。来看一段标准代码：

msgs, err := channel.Consume(
    queueName,
    "",        // consumer tag
    false,     // autoAck = false ← 关键
    false,     // exclusive
    false,     // noLocal
    false,     // noWait
    nil,       // args
)
if err != nil {
    log.Fatal(err)
}
for msg := range msgs {
    // 处理业务逻辑
    if err := process(msg.Body); err != nil {
        // 失败时拒绝并重新入队
        msg.Nack(false, true) // requeue=true
        continue
    }
    // 成功则确认
    msg.Ack(false)
}

这里有几个要点需要展开说说：

• msg.Ack(false)：这个调用确认的是当前这一条消息。如果把参数设为 true，则表示批量确认所有小于等于当前 deliveryTag 的未确认消息，但这要求你的 deliveryTag 必须是严格递增的。
• msg.Nack(false, true)：拒绝当前消息，并且通过 requeue=true 让其重新回到队列。这个配置是防止消息丢失的最后一道防线。
• 另外，如果业务处理比较耗时，务必记得通过 channel.Qos() 设置 prefetchCount=1。这能避免 RabbitMQ 一次性推送过多消息到消费者端，导致消息堆积或重复分发的风险。

deliveryTag 是每个 channel 独立维护的 64 位整数

这是一个容易踩坑的地方。deliveryTag 并非全局唯一标识，它只在创建它的那个 TCP 连接和 channel 内部有效。换句话说，你不能跨 channel 使用它，更不能把它存到数据库里，指望在另一个进程或重启后还能用它来确认消息。一旦 channel 关闭或连接断开，所有未确认消息对应的 deliveryTag 就失效了，RabbitMQ 会自动将这些消息标记为未确认（unacked），并可能重新投递。

所以，常见的错误就是把 deliveryTag 当作全局唯一 ID 来记录日志或追踪状态，结果系统重启后发现状态完全对不上。正确的做法是依赖业务自身的幂等键，比如订单号、事件 ID 等，来实现消息去重，而不是依赖于 deliveryTag。

关于批量确认（multiple=true），还有两个硬性条件：一是这些消息的 deliveryTag 必须是连续的；二是你确认的是“所有小于等于某个值”的消息。RabbitMQ 不会去校验你是否真的收到了所有这些消息，顺序和完整性的保证完全依赖于你的业务逻辑。

生产端要用 channel.Confirm() 配合 NotifyPublish()

消费端的手动 Ack 解决了“消息是否被成功处理”的问题，但“消息是否成功发送到了 RabbitMQ”呢？如果网络发生抖动，或者交换器不存在、路由失败，basicPublish() 方法可能依然会静默地返回成功。

因此，生产端必须开启发布确认模式来补上这个缺口：

err := channel.Confirm(false) // 开启 confirm 模式
if err != nil {
    log.Fatal(err)
}
// 启动异步通知监听
confirms := channel.NotifyPublish(make(chan amqp.Confirmation, 1))
go func() {
    for conf := range confirms {
        if !conf.Ack {
            log.Printf("消息投递失败，deliveryTag=%d", conf.DeliveryTag)
            // 这里应重试或落库待补偿
        }
    }
}()
// 发送消息
err = channel.Publish("", queueName, false, false, amqp.Publishing{
    ContentType: "application/json",
    Body:        []byte(`{"id":123}`),
})
if err != nil {
    log.Fatal(err)
}

这里有几点需要注意：

• channel.Confirm(false) 中的 false 表示非等待（异步）模式。如果设为 true（阻塞模式），会严重拖慢发布吞吐量，通常不推荐。
• NotifyPublish 返回的是一个无缓冲的 channel，一定要记得另起一个 goroutine 去消费它，否则发布消息的调用会被阻塞住。
• 另外，Confirmation 结构体里的 DeliveryTag 和消费端的那个不是一回事。它是发布端独立生成的序列号，仅用于匹配某次发布操作是否成功落地到 broker。

不要用事务（txSelect），也不要混用 autoAck=true 和手动 Ack

首先聊聊事务模式。虽然 Go 的 streadway/amqp 包提供了 channel.Tx() 相关方法，但它的性能代价极高。这是一种完全阻塞的模式：每发送一条消息，都需要等待 broker 返回事务提交（txCommit）的响应，这会让系统的每秒查询率（QPS）下降超过 90%。因此，所有权威文档和生产实践都明确反对在性能敏感的场景中使用事务。

另一个高频陷阱是配置不一致：代码里明明写了 msg.Ack()，但在调用 Consume 时却传入了 autoAck=true。这种情况下，RabbitMQ 在推送消息后就会立即删除它，根本不会等待你的 Ack 调用。随后执行的 msg.Ack() 会引发 panic，报错信息通常是 "channel error: not ack'ed"。

那么，构建一条真正可靠的消息链路，正确的组合拳是什么？答案是两端分离控制：生产端依靠 Confirm() 加 NotifyPublish() 来确保发送成功；消费端则通过 autoAck=false 配合 Ack()/Nack() 来保证处理成功。在这两者之间，还需要加上持久化队列（durable=true）和持久化消息（deliveryMode=2）的配置。这套组合里少了任何一环，整个链路的可靠性就会出现缺口。