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

例如，我们希望将一些信息传递给第三方API。我们不能依赖此API何时会下降，即网络错误。因此，我们有两个选择：

记录此API中推送的请求的失败，并尝试将它们推送通过某个计划作业-问题是，如果这些请求中的某些请求由于API关闭而失败，我们也需要重新推送这些失败的请求，并且这将继续。 使用类似Rabbitmq死信机制的方法-您可以对失败的请求使用其重试机制，但这会增加维护，如果在多次死信重试后仍失败，该怎么办？ 我们应该如何处理这样的第三个API进程并再次推送失败的请求？

因此，RabbitMQ与a不是一回事，尽管它们可以相互关联

假设我理解正确，您正在描述的场景-您的描述非常抽象，这是一种相当常见的情况，可以通过以下事件序列来描述：

处理器从队列中获取消息 处理器尝试处理消息 处理器无法处理消息 ? 问题是在第4步做什么。在许多应用程序中，步骤4是删除消息。但是，RabbitMQ允许在这种情况下使用否定确认，这会告诉代理无法处理消息。反过来，代理可以将消息放回队列的前端。如果发生这种情况，没有任何方法可以阻止同一处理器再次拾取消息并尝试处理它，因此当故障条件是暂时的，即处理器出现问题，而不是消息本身出现问题时，应使用这种方法

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

刻字

现在，当您拒绝一条消息basic.nack时，您可以通过指定requeue=false来控制RabbitMQ是否死信消息。如果requeue为false，则如果未配置死信交换，则消息将被死信或丢弃

---

死信队列就是这样——它是一个消息消失的地方。一般来说，将普通处理器连接到此队列是没有意义的，因为根据定义，消息出现在那里的原因首先是它们无法被处理——永远无法处理。因此，如果您希望该条件是临时的，即服务器停机，请重新查询该消息并停止处理更多消息，直到该条件得到解决。另一方面，如果消息有问题，那就毫无疑问。

您的两个选项并不是相互排斥的，选项2真的没有任何意义。希望我的回答能澄清一些困惑。所以，您建议我们应该在这里使用rabbitmq重新查询机制，即在一切正常之前停止进程？但是，这不是开销吗？因为我们正在使用许多第三方API，对于所有这些API调用，我们将不得不创建单独的Consumer。我不知道处理器如何处理消息，对于每条消息，这与整个系统行为并不真的相关。其思想是，如果处理能力有问题，那么您将停止使用消息，并对任何无法处理的消息重新进行查询。如果处理器出现问题，继续尝试处理是没有意义的。我认为这里有一些混乱-我的问题不是我们是否应该继续重试或停止使用进程，而是我们应该直接从服务器上点击第三方API并将错误记录在某处，还是通过rabbitmq点击它来使用此requeue处理？你说的“通过rabbitmq点击”是什么意思？如果你说的是第三方API的状态是/只能在试图处理消息时进行评估，那么如果这是一个外部约束，就这样吧。但我觉得这很奇怪。通常，系统中的给定组件负责“自检”，以确保它能够实际完成其工作，包括检查任何依赖项。