GCP pubsub 仅向失败的订阅者重放 DLQ 消息

Question

我们有一个使用 GCP pubsub 构建的系统，其中有一个主要的“事件”主题，该主题从多个来源接收不同的消息并将所有这些消息发布给许多不同的订阅者。订阅者仅对某些消息进行操作。

当订阅上的消息失败时，它会转到 DLQ pubsub - 我们为每个订阅者提供其中一个。

问题在于，在 GCP 中，您似乎无法向单个 pubsub 订阅者重播消息 - 您必须将其发送回主题。这会导致以下问题：同一条消息发送给多个订阅者，但只有 1 个订阅者失败。因此，如果您重播，您会收到两次发送给其中一个的信息。

设计此系统时，最初的开发人员假设它更像是 AWS 中多个 SQS 的 SNS，您可以将消息从 SQS DLQ 移回其失败的队列。不幸的是，这似乎不可能。

我在下面画了这个问题的图表。当订阅者 A 上的消息失败时，它最终会发送到 DLQ A 订阅者。我希望它遵循绿线 - 但似乎只有橙色线是可能的：

您如何在 GCP 中处理这种情况，以及任何修复系统架构的建议将受到欢迎。

Answer 1

有两种主要方法可以处理将消息从 DLQ 发送回单个订阅：

1. 为重播的消息创建一个附加主题，并让订阅者监听原始主题和重播主题上的消息。将消息重新发布到重播主题。在这种情况下，您可能希望每个订阅都有一个独立的重播主题。
2. 向每个订阅添加一个过滤器，以接受所有未重播的消息或以其为主题重播的所有消息。例如，对于重播的每条消息，您可以添加一个属性，将

   key

   设置为

   replay

   并将

   value

   设置为其目标订阅。每个订阅都会有一个过滤器来接收消息，其中

   replay

   不作为键存在，或者

   replay

   的值是订阅。通常发布的消息不会有

   replay

   属性，而您重播的消息则会将该属性设置为目标订阅。该目标订阅的订阅者将收到重播的消息，但其他消息将被过滤掉。

两者之间的权衡是复杂性和成本。在第一种情况下，您必须为每个订阅设置第二个主题，并拥有从中获取消息的代码。在第二种情况下，您不必设置该基础设施，但由于您为过滤掉的消息传递付费，因此您必须考虑成本，特别是当您必须重播大量消息或拥有大量消息时订阅量。