我正在尝试了解 GCP Pub/Sub，但对 Pub/Sub 中消息的生命周期有疑问。事实上，我用了this article作为我的引用。在这篇文章中，他们说:
Once at least one subscriber for each subscription has acknowledged the message, Pub/Sub deletes the message from storage.
所以我的第一个问题是:例如，我有一个订阅 A，它连接到订阅者 X 和订阅者> Y. 根据文档，当订阅者 X 收到消息并向订阅 A 发送 ACK 时，Pub/Sub 将从存储中删除该消息，而无需考虑订阅者 Y 是否收到消息。换句话说，Pub/Sub 并不关心所有订阅者是否都收到了消息，只有一个订阅者收到消息，Pub/Sub 就会从存储中删除该消息吗？请问我说得对吗？
然后，在文章的下面部分，文章说:
Once all subscriptions on a topic have acknowledged a message, the message is asynchronously deleted from the publish message source and from storage.
我在这里感到有点困惑。我的理解是，例如，我有一个有 N 个订阅的主题，每个订阅有 M 个订阅者，Pub/Sub 只需要知道对于每个订阅，至少有一个订阅者已确认该消息，它将删除该消息来自存储的消息。请问我说得对吗？
我还发现，在文档中，我们有两个概念:发布转发器和订阅转发器。我可以问最后几个问题吗:
- 订阅、发布转发器和订阅转发器之间有什么关系？ (例如，订阅仅包含一个发布转发器和一个订阅转发器？)
- 发布转发器和订阅转发器之间的关系是一对一、一对多、多对一或多对多，请问？
- 一个订阅者是否可以与多个订阅关联？
- 一旦订阅者消费了一条消息(这里我说这条消息是不重复的，它没有副本，它是唯一的)，这个订阅者有可能重新消费吗？ -消费/重新阅读这条消息？
如果我有什么理解错误的地方，请指出，我真的很感激。
谢谢大家!!!
最佳答案
这里有相当多的内容需要解压。最好不要将订阅视为附属于订阅者，并且要理解这两者是不同的。 订阅是一个命名实体，它希望接收发布到某个主题的所有消息。 订阅者是代表订阅运行来接收和处理消息的实际客户端。一个主题可以有多个订阅。一个订阅可以有多个订阅者。如果订阅中有多个订阅者，则假设没有重复传递并且订阅者确认收到的所有消息，则发布到主题的每条消息都将传递给该订阅的一个订阅者。这称为负载平衡:消息的处理分布在许多订阅者上。如果一个主题有多个订阅，每个订阅有一个订阅者，那么每个订阅者都会收到所有消息。这称为扇出:每个订阅者都会收到发布的完整消息集。当然，可以将这两者结合起来，每个订阅有多个订阅者，在这种情况下，每条消息将被传递给每个订阅的一个订阅者。
转发器只是负责传递消息的服务器。发布转发器从发布者接收消息，订阅转发器向订阅者发送消息。消息传递路径上的所有关系(从发布者到发布转发器、发布转发器到订阅转发器、订阅转发器到订阅者)都可以是多对多关系。
订阅者与单个订阅相关联。但是，正在运行的作业可以有多个订阅者在其中运行，例如，可以在不同的订阅上多次实例化订阅者客户端库。
以上所有内容都假设了一个重要的警告:假设没有重复的交付。一般来说，Cloud Pub/Sub 保证至少一次交付。这意味着，即使订阅者正确确认的消息也可能被重新传递(无论是发送给同一订阅者还是不同的订阅者)，在这种情况下，订阅者需要在后续传递时确认该消息。一般来说，对于在确认截止日期到期之前确认消息的行为良好的订阅者来说，重复率应该非常低，在 0.1% 的范围内。
关于google-cloud-platform - GCP 发布/订阅 : Life of a Message，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/66762282/