GCP Pub/Sub：消息的生命周期

Question

我正在嘗試了解 GCP Pub/Sub，但我對 Pub/Sub中消息的生命周期有疑問。 事實上，我用這篇文章作為我的參考。 在這篇文章中，他們說：

一旦每個訂閱的至少一個訂閱者確認了該消息，Pub/Sub 就會從存儲中刪除該消息。

所以我的第一個問題是：例如，我有一個訂閱A，它連接到訂閱者X 和訂閱者Y。根據文檔，當訂閱者X 收到消息並向訂閱A 發送 ACK 時，Pub/Sub 將刪除從存儲中獲取消息，而不考慮訂閱者Y 是否收到該消息。 換句話說，Pub/Sub 不關心是否所有訂閱者都收到了消息，只有一個訂閱者收到消息，然后 Pub/Sub 會從存儲中刪除消息？ 請問我說的對嗎？

然后，在文章的下面部分，文章說：

一旦某個主題的所有訂閱都確認了一條消息，該消息就會從發布消息源和存儲中異步刪除。

我在這里感到有點困惑。 我的理解是，例如，我有一個有 N 個訂閱的主題，每個訂閱有 M 個訂閱者，Pub/Sub 只需要知道對於每個訂閱，至少有一個訂閱者已經確認了消息，它將刪除來自存儲的消息。 請問我說的對嗎？

我還發現在文檔中，我們有兩個概念： Publishing Forwarder和Subscribing Forwarder 。 所以我可以問一些最后的問題：

• 訂閱、發布轉發器和訂閱轉發器之間的關系是什么？ （例如，訂閱僅包含一個發布轉發器和一個訂閱轉發器？）
• Publishing Forwarder和Subscribing Forwarder的關系是一對一還是一對多還是多對一還是多對多？
• 請問一個訂閱者是否可以與多個訂閱相關聯？
• 一旦訂閱者消費了一條消息（這里我說這條消息沒有重復，它沒有副本，它是唯一的），這個訂閱者是否有可能重新消費/重新閱讀這條消息？

如果我誤解了什么，請為我指出，我真的很感激。

感謝你們 ！！！

Answer 1

相當多的解壓在這里。 最好不要將訂閱視為附加到訂閱者，並且要了解這兩件事是不同的。 訂閱是一個命名實體，它希望接收發布到某個主題的所有消息。 訂閱者是代表訂閱運行以接收和處理消息的實際客戶端。 一個主題可以有多個訂閱。 一個訂閱可以有多個訂閱者。 如果訂閱中有多個訂閱者，那么，假設沒有重復交付並且訂閱者確認收到的所有消息，則發布到主題的每條消息都將傳遞給訂閱的一個訂閱者。 這稱為負載平衡：消息的處理分散在許多訂閱者上。 如果一個主題有多個訂閱，每個訂閱都有一個訂閱者，那么每個訂閱者都會收到所有消息。 這稱為扇出：每個訂閱者都會收到已發布的完整消息集。 當然，可以將這兩者結合起來，每個訂閱有多個訂閱者，在這種情況下，每個訂閱的每條消息都將傳遞給一個訂閱者。

轉發器只是負責傳遞消息的服務器。 發布轉發器從發布者接收消息，訂閱轉發器將消息發送給訂閱者。 傳遞消息路徑上的所有關系，從發布者到發布轉發器、發布轉發器到訂閱轉發器以及訂閱轉發器到訂閱者，都可以是多對多關系。

訂閱者與單個訂閱相關聯。 然而，運行的作業可能有多個訂閱者在其中運行，例如，可以在不同訂閱上多次實例化訂閱者客戶端庫。

以上所有都假設了一個重要的警告：假設沒有重復的交付。 通常，Cloud Pub/Sub 保證至少一次交付。 這意味着即使是被訂閱者正確確認的消息也可以重新傳遞——無論是發送給同一個訂閱者還是不同的訂閱者——在這種情況下，訂閱者需要在隨后的傳遞中確認該消息。 一般來說，重復率應該非常低，對於在確認截止日期到期之前確認消息的行為良好的訂閱者來說，重復率應該在 0.1% 范圍內。