GCP Pub/Sub：消息的生命周期
GCP Pub/Sub: Life of a Message
我正在尝试了解 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 et Subscriber Y。根据文档，当 Subscriber X 收到消息并向 Subscription A，Pub/Sub 将从存储中删除消息，而不考虑 Subscriber 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 只需要知道对于每个订阅，至少有一个订阅者已经确认了消息，它会从存储中删除消息。请问我说的对吗？
我还发现在文档中，我们有两个概念：Publishing Forwarder和Subscribing Forwarder。那么我可以问最后几个问题吗：
- 订阅、发布转发器和订阅转发器之间有什么关系？ （例如，订阅仅包含一个发布转发器和一个订阅转发器？）
- 发布转发器和订阅转发器之间的关系是一对一或一对多或多对-一对多还是多对多？
- 一个订阅者可以与多个订阅相关联吗？
- 一旦一个订阅者消费了一条消息（这里我说这条消息是不重复的，它没有副本，是唯一的），有没有可能这个订阅者 re-consumes/re-reads 正是这条消息？
如果我理解有误，请指出，非常感谢。
谢谢大家！！！
这里有很多东西要解压缩。最好不要将 subscription 视为附加到 subscribers 并且还要了解这两者是不同的。 订阅 是一个命名实体，它希望接收发布到主题的所有消息。 订阅者 是一个实际的客户端 运行 代表订阅接收和处理消息。一个主题可以有多个订阅。一个订阅可以有多个订阅者。如果一个订阅中有多个订阅者，那么假设没有重复投递并且订阅者确认收到的所有消息，发布到主题的每条消息都将被投递给订阅的一个订阅者。这称为 负载平衡 ：消息的处理分布在许多订阅者上。如果一个主题有多个订阅，每个订阅有一个订阅者，那么每个订阅者都会收到所有消息。这称为 扇出 ：每个订阅者都会收到发布的完整消息集。当然，可以将这两者结合起来，每个订阅有多个订阅者，在这种情况下，每个订阅都会将每条消息传递给一个订阅者。
转发器只是负责传递消息的服务器。发布转发器从发布者接收消息，订阅转发器向订阅者发送消息。从发布者到发布转发器、发布转发器到订阅转发器以及订阅转发器到订阅者的消息传递路径上的所有关系都可以是多对多关系。
订阅者与单个订阅相关联。但是，一个作业 运行 中可以有多个订阅者 运行，例如，可以在不同的订阅上多次实例化订阅者客户端库。
以上所有内容都假设了一个重要的警告：假设没有重复交付。一般情况下，云Pub/Sub至少保证一次发货。这意味着即使是一条被订阅者正确确认的消息也可以重新发送——要么发送给同一个订阅者，要么发送给不同的订阅者——在这种情况下，订阅者需要在后续发送时确认消息。一般来说，重复率应该非常低，对于在确认截止日期到期之前确认消息的行为良好的订阅者来说，重复率在 0.1% 范围内。
我正在尝试了解 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 et Subscriber Y。根据文档，当 Subscriber X 收到消息并向 Subscription A，Pub/Sub 将从存储中删除消息，而不考虑 Subscriber 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 只需要知道对于每个订阅，至少有一个订阅者已经确认了消息，它会从存储中删除消息。请问我说的对吗？
我还发现在文档中，我们有两个概念：Publishing Forwarder和Subscribing Forwarder。那么我可以问最后几个问题吗：
- 订阅、发布转发器和订阅转发器之间有什么关系？ （例如，订阅仅包含一个发布转发器和一个订阅转发器？）
- 发布转发器和订阅转发器之间的关系是一对一或一对多或多对-一对多还是多对多？
- 一个订阅者可以与多个订阅相关联吗？
- 一旦一个订阅者消费了一条消息（这里我说这条消息是不重复的，它没有副本，是唯一的），有没有可能这个订阅者 re-consumes/re-reads 正是这条消息？
如果我理解有误，请指出，非常感谢。
谢谢大家！！！
这里有很多东西要解压缩。最好不要将 subscription 视为附加到 subscribers 并且还要了解这两者是不同的。 订阅 是一个命名实体，它希望接收发布到主题的所有消息。 订阅者 是一个实际的客户端 运行 代表订阅接收和处理消息。一个主题可以有多个订阅。一个订阅可以有多个订阅者。如果一个订阅中有多个订阅者，那么假设没有重复投递并且订阅者确认收到的所有消息，发布到主题的每条消息都将被投递给订阅的一个订阅者。这称为 负载平衡 ：消息的处理分布在许多订阅者上。如果一个主题有多个订阅，每个订阅有一个订阅者，那么每个订阅者都会收到所有消息。这称为 扇出 ：每个订阅者都会收到发布的完整消息集。当然，可以将这两者结合起来，每个订阅有多个订阅者，在这种情况下，每个订阅都会将每条消息传递给一个订阅者。
转发器只是负责传递消息的服务器。发布转发器从发布者接收消息，订阅转发器向订阅者发送消息。从发布者到发布转发器、发布转发器到订阅转发器以及订阅转发器到订阅者的消息传递路径上的所有关系都可以是多对多关系。
订阅者与单个订阅相关联。但是，一个作业 运行 中可以有多个订阅者 运行，例如，可以在不同的订阅上多次实例化订阅者客户端库。
以上所有内容都假设了一个重要的警告：假设没有重复交付。一般情况下，云Pub/Sub至少保证一次发货。这意味着即使是一条被订阅者正确确认的消息也可以重新发送——要么发送给同一个订阅者，要么发送给不同的订阅者——在这种情况下，订阅者需要在后续发送时确认消息。一般来说，重复率应该非常低，对于在确认截止日期到期之前确认消息的行为良好的订阅者来说，重复率在 0.1% 范围内。