将所有消息从deadletter队列移回主订阅队列

Question

我的服务使用来自Azure Service Bus订阅的邮件。我的服务的依赖关系暂时停止了一段时间，这导致很多消息最终都出现在死信队列（DLQ）中。现在该服务已备份，我想重新处理来自DLQ的所有消息。如何将所有来自DLQ的消息重新提交/重新提交回主队列。

限制：

• 它有数以千计的消息，因此手动处理它们是不可行的。
• 该主题约有十个订阅。我不想将消息重新提交给主题，因为所有订阅都会收到消息，从而导致双重处理。
• 我不想直接针对DLQ运行服务，因为某些消息被破坏并导致永久性错误，即它们会再次进入DLQ，这将导致无限循环。此外，损坏的消息会被放回队列的前面，有效地使破坏后的健康消息挨饿。

Answer 1

重播DLQ消息的唯一选择是从DLQ接收它们，创建具有相同内容的新消息并再次将其发送到主题。它们将在订阅队列结束时结束。

您无法直接向订阅发送消息。有一个技巧是向消息添加元数据属性，然后调整除一个订阅之外的所有属性以过滤掉这些消息。由您来决定它是否会在您的方案中提供帮助。

至于工具，我们总是使用自定义代码执行此操作，因为我们总是需要完成一些额外的工作，例如记录每个重播的消息以进行进一步分析。

Answer 2

托马斯，您可能已经找到答案了，因为这已经有一段时间了。可以将DLQ（或您现有的任何现有队列）视为另一个收集变量，例如在PC应用程序中，但驻留在云中。就像工具包中的PC应用程序或内存中的收集变量一样，您可以通过多种方式使用它。当然，这两种类型的集合变量之间存在限制和差异，但是通过了解这些限制和差异，这就是设计DLQ只是另一个集合变量的解决方案。

解决方案之一是拥有同一个应用程序的另一个实例，但指向可见性超时时间较长的DLQ，例如6或12甚至24小时，具体取决于您的SLA。很长一段时间，因为您不想重复太多。

如果DLQ包含损坏的不可恢复的作业，则应修复应用程序，以在发生未知异常时根据错误消息将其删除。部署此修补程序后，此类破碎的不可恢复的作业将被您的应用删除，并且永远不会首先发送到DLQ。 DLQ中已包含的内容将被固定应用删除。

Answer 3

快速的答案是您不能将消息直接移回预订的主队列。这是设计使然，Microsoft如何实现其主题和订阅。

选项1
可以选择使用Azure Service Bus主题筛选器https://docs.microsoft.com/en-us/azure/service-bus-messaging/topic-filters并以仅允许在目标订阅中接收它们的方式定义/标记消息。

选项2
另一个选择是更改当前的实现。您将设置“传递队列”（常规服务总线队列），并配置每个相应的订阅以将其消息自动转发到这些传递队列。然后，您的消息处理逻辑将侦听这些“传递队列”而不是订阅。然后，任何失败都将导致这些关联的“传递队列”上出现DLQ消息，然后可以在主题/订阅之外进行处理。

Answer 4

我意识到这是在原始帖子之后的一段时间，但是如果其他任何人迷失了这个问题，Service Bus Explorer中都会有一个非常方便的解决方案（我发现在ASB开发中它非常方便）。

连接到服务总线并找到所需的名称空间后，找到包含死信的所需topic和subscription。从那里Right Click和Receive Deadletter Queue Messages，然后单击确定。

从此处，突出显示要发送回主队列的邮件，然后点击Resubmit Selected Messages in Batch Mode。