Rabbitmq 目的地系统长时间停机时的MassTransit用户故障处理

我已经阅读了关于错误处理和故障的MT文档，并编写了一些代码来发布故障，并编写了一个故障消费者，在与Polly进行了多次重试后，可以收听故障消息

我让一个队列使用者使用MassTranasit从RabbitMQ获取消息，并通过Http api发送到云系统。我已经处理了所有可能的异常，还将http调用包装在Polly retry中，以防出现暂时的网络错误。但这种方法的问题是，在重试次数用尽后，消息实际上被放弃了处理

如果目标系统停机10小时，假设（我们之前不知道这次停机，否则我将计划停止消费者服务），我们可以使用MassTransit采取什么最佳策略停止将消息从队列拉入消费者服务？是否有一种方法可以根据失败次数等停止接收消息

---

谢谢

您需要一个断路器，这是分布式系统中众所周知的模式。当远程系统在负载下挣扎时，断路器启动，向其发出更多请求可能会扼杀它。它还允许您在远程系统关闭时停止向远程系统发送消息

断路器是开箱即用的

我也不建议在消费者中使用Polly实现重试。MassTransit有一套全面的重试策略，它还允许MassTransit了解消费者中发生了多少故障，这在使用Polly时是不可用的。例如，断路器中间件不知道Polly包装调用中的故障，因此无法正确响应

如果远程系统长时间停机（如您所述，如数小时），任何尝试次数有限的重试策略最终都会失败。断路器将断开，但它会不时重置，并尝试再次向用电设备发送呼叫。否则，它永远不会知道远程系统何时恢复。因此，您可能需要从错误队列中恢复消息，或者添加中间件

因此，您可以通过以下方式配置接收管道：

---

重新交付->断路器->重试->消费者

您应该使用MassTransit的重试支持，而不是下面Alexey所述的“polly”，您应该有适当的监控来检测这些错误（从日志中），并停止服务，以避免在队列中循环每条消息，而只需将它们重新放入队列中（来自_错误）一旦服务可用。嗨，Chris，谢谢你的评论。你能在下面的Alexey回复中查看我关于使用Polly而不是MT重试的评论吗？这有意义吗？我支持Chris关于监控的观点。如果你提取远程系统客户端并使用健康检查观察其行为，你也可以进行服务ice不健康，从外部处理它。嗨，Alexey，谢谢你的回复。我有理由使用Polly而不是MT message retry，因为MT重试每次都会执行consumer中的整个代码，我知道只有我需要重试的代码是在最后一点向目标系统发出http调用，如果我得到e，则在其他任何地方都可以例外情况是重试无法解决。那么使用Polly有意义吗？或者您仍然有强烈的意见在这里使用MT retry吗？谢谢，关于重试，正如您提到的，我们在这里有两个选项。1.使用错误队列，稍后手动将其移回正常队列2.使用RabbitMQ延迟计划在ce之后重新提交确定时间。我喜欢此计划，但我不确定确切的计划消息的时间，因为目标系统中断不在我们手中。您认为哪一个更好？我明白了。您可以选择将绑定到HTTP调用的操作拆分到单独的使用者中，并从原始使用者向自己发送消息。在regar中ds重新交付，以及重试，您可以配置增量或指数重试，因此重试之间的超时将增加，只是要确保它不会变得不必要的长。如果您想坚持Polly，您也可以使用Polly自己的断路器。基本上，断路器是您需要的，您只需要找出哪个断路器您要应用它的级别。