RabbitMQ ACK、NACK、Type、TTL、死信

Posted 2023-04-20

参考技术A

起因：在实际项目开发过程中，需要使用RabbitMQ来实现消息队列的功能，比如说我发布一个动态之后，需要在30分钟使用默认用户给他点几个赞，之前考虑使用redis的zset对他进行操作，之后决定使用RabbitMQ，专业的事情使用专业的工具来操作。

什么是TTL：Time To Live ，也就是生存时间

首先要看一下什么是死信：当一个消息 无法被消费 时就变成了死信

死信是怎么形成的：消息在没有被消费前就失效的就属于死信

一个系统中是没有无缘无故生成的消息，如果这个消息失效了没有了，是不是可能导致业务损失，如果这种消息我们需要记录或补偿，将这种消息失效的时候放到一个队列中，待我们人工补偿和消费，这个放死信的队列就是死信队列

希望我们的消息在失效的时候进入到死信队列中

我们的死信队列其实也是一个正常队列，只是赋予了他这个概念

死信队列的另一功能就是延迟消息

x-dead-letter-exchange ：这个参数就是指定死信队列的Exchange的名字，这个Exchange就是一个普通的Exchange，需要手工创建

x-dead-letter-routing-key ：这个参数就是指定死信队列的Routingkey，这个routingkey需要自己创建好队列和Exchange进行binding时填入

不要以为每天把功能完成了就行了，这种思想是要不得的，互勉~！

pubsub 流式处理 pull nack 与无确认行为

【中文标题】pubsub 流式处理 pull nack 与无确认行为

【英文标题】：pubsub streaming pull nack vs no acknowledge behaviour

【发布时间】：2019-12-01 17:33:45

【问题描述】：

nack() 有以下行为

nack() """拒绝确认给定的消息。 这将导致消息被重新传递给订阅。

现在在流式拉取中，我正在拉取taxiride streaming data 测试以下行为。

用 nack() 流式拉取继续接收之前被 nacked() 的消息

nack() 或 ack() 都不是 流式传输会读取最初的一堆消息并等待很长时间。我等了将近 15 分钟，但它没有拉出任何新消息。

现在我的问题是，在消息既不是 ack() 也不是 nack() 的流式拉取中，处理这些消息的预期行为和正确方法是什么？ 假设我想将每分钟积压的消息数作为处理要求吗？

【参考方案1】：

当消息既未确认也未确认时，Cloud Pub/Sub 客户端库会维护消息的租约，直至 maxAckExtensionPeriod。一旦该时间段过去，消息将被nack并重新传递。当您既不确认也不确认时，您没有收到更多消息的原因可能是因为您遇到了flowControlSettings 中指定的值，这限制了可能未完成且尚未确认或确认的消息的数量。

一般来说，既不确认也不确认消息是一种反模式。如果你成功处理了消息，你应该确认它。如果您无法处理它（例如发生某种类型的瞬态异常），那么您应该对其进行处理。尝试在不执行这些操作之一的情况下接收消息并不是计算积压中消息数量的有效方法。

【讨论】：

感谢 Kamal Aboul-Hosn 的解释。