0

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

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

我们应该如何处理这样的第三个 API 进程并再次推送失败的请求？

4

1 回答 1

1

因此，RabbitMQ死信与否定确认不是一回事，尽管它们可以相关。

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

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

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

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

死字

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

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

于 2017-11-29T05:25:39.760 回答