通过 RabbitMq 路由每个第三方 API 调用以使用其死信机制是否有意义？

Question

例如，我们想将我们的一些信息传递给第三方API。我们不能依赖此 API 何时会出现故障，即网络错误。所以，我们有两个选择：

1. 在此 API 中记录被推送请求的失败并尝试通过一些计划的作业推送它们 - 问题是如果其中一些请求由于 API 宕机而失败，我们需要也重新推送这些失败的请求，这将继续下去。
2. 使用 Rabbitmq 死信机制之类的东西——你可以使用它的重试机制来处理失败的请求，但这会增加维护工作，如果在多次死信重试后仍然失败怎么办？

这样的第三个API进程应该如何处理，将失败的请求重新推送？

Answer 1

所以，RabbitMQ dead-lettering is not the same thing as a negative acknowledgement，尽管它们可能是相关的。

您所描述的场景（假设我理解正确-您的描述非常抽象）是一种相当普遍的情况，可以用以下事件序列来描述：

1. 处理器从队列中获取消息
2. 处理器尝试处理消息
3. 处理器无法处理消息
4. ?

问题是在第 4 步做什么。在许多应用程序中，第 4 步是丢弃消息。但是，RabbitMQ 允许在这种情况下使用否定确认，告诉代理无法处理该消息。代理又可以将消息放回队列的头部。如果发生这种情况，没有什么可以阻止同一个处理器再次拾取消息并尝试处理它，因此当故障条件是暂时的（即处理器有问题，而不是消息本身有问题）时应该使用它。

您的应用程序处理逻辑需要决定何时从队列中提取消息并尝试处理它们是有意义的。例如，等待一段预先确定的时间可能是有意义的，或者轮询第 3 方 API 直到它恢复正常可能是明智的。你在这里做什么取决于你。

死字

现在，当您拒绝一条消息 (basic.nack) 时，您可以通过指定 requeue=false 来控制 RabbitMQ 是否对消息进行死信处理。如果 requeue 为 false，则消息将是死信的（或丢弃，如果没有配置死信交换）。

死信队列就是消息死去的地方。作为一般规则，将您的普通处理器连接到此队列永远没有意义，因为根据定义，消息首先存在的原因是它们永远无法处理。因此，如果您希望条件是暂时的（即服务器停机），请重新排队消息并停止处理更多消息，直到条件得到解决。另一方面，如果消息有问题，则一定要将其置为死信。