本指南可讓您瞭解 Pub/Sub 可靠性功能的整體概況。本文涵蓋的主題包括：
- 為何選擇 Pub/Sub？
- 容錯移轉
- 微調發布商
- 微調訂閱者
- 使用快照和搜尋功能進行安全部署
為何選擇 Pub/Sub？
發布/訂閱是一種訊息架構，旨在將訊息供應者與訊息消費者分離。生產者不會將資料直接傳送給消費者，而是將資料發布至 Pub/Sub 服務 (例如 Pub/Sub)。服務會將這些訊息以非同步方式傳送給已訂閱的使用者。
結果是，服務會吸收所有複雜的細節，找出對資料有興趣的消費者。這項服務也會根據消費者的容量，管理他們接收資料的速率。分離後，資料產生者就能不受消費者行為影響，以低延遲時間大量寫入訊息。
Pub/Sub 可提供可高度擴充且可靠的訊息傳遞服務。雖然服務會自動處理大部分的情況，但您可以控制發布者和訂閱者的不同面向，這些面向可能會影響可用性和效能。本指南的其餘部分將詳細說明這些方面
容錯移轉
Pub/Sub 是全球服務：主題和訂閱項目並非與特定區域連結，且訊息會在 Pub/Sub 服務內部區域之間流動。使用全球端點 pubsub.googleapis.com 時，發布者和訂閱者會連線至 Pub/Sub 執行時所屬的最近網路區域。使用位置端點 (例如 us-central1-pubsub.googleapis.com) 時，發布者和訂閱者會連線至指定區域的 Pub/Sub。在 Google Cloud以外執行發布端或訂閱端時，建議使用位置端點，以確保訊息在預期區域之間流動一致。本節的其餘部分將說明如何建立主題和訂閱項目。此外，我們也會討論如何安排發布者和訂閱者，以便支援不同類型的備援和資料冗餘。
預設備援語意
假設只有一個主題和訂閱項目。發布者位於美國和澳洲的區域，訂閱者則位於歐洲和澳洲的 Google Cloud 區域。如果所有訂閱者都有足夠的容量來接收訊息，訊息流程如下所示：
其中 P 代表發布商，S 代表訂閱者。藍色六邊形代表 Pub/Sub 服務。圓柱代表郵件儲存的位置 (郵件一律會儲存在發布地區的多個區域)。Pub/Sub 會在有訂閱者可用時，優先在訊息發布所在的區域內傳送訊息。否則，系統會將訊息傳送至網路最近且有容量的區域。因此，如上圖所示，在美國發布的訊息會傳送給歐洲的訂閱者，而澳洲境內發布的訊息則會留在澳洲境內。
以下各節將討論不同失敗情況的處理方式。
歐洲的訂閱者無法使用
假設歐洲的訂閱者遭到拒絕，或經常當機，且無法維持與 Pub/Sub 的連線。在這種情況下，服務會開始向澳洲的訂閱者傳送訊息：
歐洲和澳洲的訂閱者無法使用
如果所有訂閱者都無法使用，Pub/Sub 會將訊息儲存至設定的訊息保留時間。
訂閱者重新連線後，系統就會傳送訊息，除非停機時間超過設定的訊息保留時間。根據預設，訂閱訊息的保留期限為 7 天。您也可以設定主題的訊息保留時間，最多可達 31 天。請勿選擇比預期或願意容許的最大停機時間更短的訊息保留時間。
Pub/Sub 在歐洲無法使用
雖然這種情況很少見，但您可能也需要處理 Pub/Sub 本身無法使用的情況。Pub/Sub 無法使用時，發布或訂閱要求會出現長時間的非預期錯誤，或是無法將已發布訊息傳送給訂閱者。舉例來說，如果 Pub/Sub 在歐洲地區發生故障，那麼這個情境就會與訂閱者發生故障時類似：
請注意，在這種情況下，即使使用全球端點，歐洲的訂閱者也不會切換至其他區域。Pub/Sub 不會自動進行備援。假設是訂閱者本身導致 Pub/Sub 發生非預期問題，導致無法使用。系統會將這類問題視為重大服務中斷事件。不過，中斷服務的影響範圍可能只限於訂閱者連線的區域。如果服務允許將這些訂閱項目轉移至其他區域，訂閱端也可能會導致該區域無法使用，導致服務發生連鎖故障。
澳洲的發布商無法使用
如果某個地區的發布端無法使用，已發布的訊息仍會傳送至最近的訂閱端：
最後，所有訊息都會被使用，並由訂閱者確認。傳送訊息時，Pub/Sub 會盡量縮短網路距離。因此，如果歐洲的訂閱者有足夠的容量來處理所有在美國發布的訊息，澳洲區域的訂閱者就可以停止接收訊息。
美國無法使用 Pub/Sub
Pub/Sub 會同步將訊息寫入區域內的多個區域。因此，區域停機並不足以阻止訊息傳送；整個區域都必須無法使用。如果發布者傳送訊息的區域無法使用 Pub/Sub，則在服務完全恢復之前，該區域的訊息可能無法傳送：
訊息最終仍會傳送 (假設訊息保留期限尚未過期)，但會延遲一段時間。請注意，與訂閱者一樣，美國的發布者在服務發生問題時，也不會轉移至其他地區。這項行為可避免因發布商或訂閱者發生錯誤，而導致跨區域的連鎖故障。
隔離
預設的備援語意會影響資料隔離，以及發布端、訂閱端或 Pub/Sub 本身無法使用時，可能對訊息流量造成的影響。您的用途可能需要不同程度的隔離。舉例來說，您可能需要在同一個區域內傳送所有郵件。
如果您不想進行隔離，則預設的備援語意說明就足夠了。您必須建立單一主題、單一訂閱項目，並在所有所選區域中放置發布商和訂閱者。如果訂閱者無法使用，或是 Pub/Sub 在訂閱者連線的區域發生故障，則無法將訊息傳送至其他區域的訂閱者。
如要實現區域隔離 (可確保資料不會離開區域)，請建立主題和訂閱項目，以便處理各區域的訊息。找出各區域中的發布者和訂閱者，並請他們分別發布及訂閱對應的區域主題和訂閱項目。您也必須使用區域端點，確保資料只在該區域內移動。如果單一區域發生發布端、訂閱端或 Pub/Sub 失敗，該區域就會停止傳送訊息。其他區域的主題和訂閱項目的訊息傳送作業不會受到影響。
最後，Pub/Sub 無法提供區域隔離功能，也就是保證資料會留在單一區域內。如果您需要個別區域獨立運作，請使用 Pub/Sub Lite。
客戶控管的容錯移轉和備援功能
在發生中斷服務的情況下，Pub/Sub 的預設備援意義可能無法完全保證訊息一律能從發布端傳送至訂閱端。中斷可能發生在多個不同位置，包括用戶端、發布者或訂閱者執行的服務、網路，甚至在 Pub/Sub 本身 (但很少發生)。如果您需要服務在發生這類中斷時具備復原能力，就必須自行實作備援機制。這些重複項目通常包括使用多個發布者和訂閱者用戶端的情況，其中每個用戶端都使用不同的位置端點。
您可能需要針對兩種不同的影響範圍設定復原能力：區域或區域。以下是各項設定的選項。
可用區彈性
Pub/Sub 內建跨區域複寫功能。您不需要採取任何特殊步驟，即可處理影響服務本身的單一區域服務中斷問題。不過，為了讓用戶端或網路具備服務中斷復原能力，建議您在區域內的多個區域中，為發布端和訂閱端提供足夠的容量。如果單一區域發生故障，其他區域中的用戶端就能接收流量並處理訊息。最佳做法是不同時發布這些用戶端的變更，這樣一來，如果發生錯誤，其他未受影響的區域仍可繼續處理訊息。
區域復原能力
為靈活應對區域性故障，請在發布端和訂閱端設定額外的備援機制。您可以在多個地區執行發布端和訂閱端，以便處理這些用戶端或網路發生中斷的可能性。
如要靈活應對區域中可能發生的 Pub/Sub 故障，您必須準備好容錯機制，以便處理這類中斷情形。您可以權衡端對端訊息傳送延遲時間和成本，選擇合適的做法。
如不考量成本，為了在事件中盡可能降低延遲，最佳做法就是一律在不同區域同時發布及訂閱。首先，請選擇要備援的區域數量。接下來，您可以為每個區域設定主題和訂閱項目 (但並非必要)。
每個發布商都會根據區域數量 (每個區域一個) 建立相同數量的發布商用戶端，並使用不同的位置端點，確保訊息會傳送至不同的區域。如果使用不同的主題，每個發布者用戶端都必須發布至相應的區域主題。對於每則訊息，發布者都會在每個用戶端上呼叫 publish。有了備援發布功能，如果單一發布作業失敗，就不需要重試發布作業。
同樣地，每個訂閱者都會建立相同數量的訂閱者用戶端 (每個區域一個)，並使用位置端點連線至其他區域。如果每個地區使用不同的訂閱項目，則每個訂閱者用戶端都必須使用對應的訂閱項目。請注意，發布商和訂閱者使用的地區不一定相同。訂閱者會收到三個訂閱項目的訊息，並加以處理。
這項設定有幾項重要功能和需求：
- 任何單一區域的服務中斷事件，都不會影響已發布訊息的處理作業，也不會影響在服務中斷期間發布的訊息。由於訊息已發布至多個區域，因此在某個區域發生故障時，其他區域仍可使用這些訊息。在服務中斷期間，發布呼叫會在受影響的區域失敗，但在其他區域成功。
- 只要訊息流經的任何區域可供使用，訊息處理延遲就不會受到影響。
- 訊息處理作業必須冪等。由於每則訊息都會傳送多次，因此訊息處理作業必須能處理重複的訊息。如果發生區域性中斷服務，部分重複訊息可能會比第一次傳送訊息的時間晚很多才送達。這些重複項目可能來自未發生服務中斷情形的其他區域。
使用這類備援機制執行時，可在任何停機情況下提供最高復原能力。對於依賴 Pub/Sub 且需要最高可用性的 Google 內部服務，建議採用這種設定。不過，這項設定會產生權衡，也就是傳送訊息的費用會乘以使用的區域數量。對於必須跨區域傳送的訊息，您還必須支付跨區域網路使用費。
另一種備援方法是，只有在要求失敗或訊息未如預期從發布者傳送至訂閱者時，才會改用備援機制。在這種情況下，您有一個主要區域，可透過位置端點將發布者和訂閱者導向該區域。如同先前所述，這兩者不必位於相同的區域。您也可以為發布者和訂閱者設定備用區域，在主要區域無法使用時使用。
發布商只會在成功傳送要求後，將內容發布至主要區域 (透過位置端點)。每當系統判定某個區域無法運作時，發布商就會改為開始在備用區域發布內容。判斷區域是否已關閉並發生故障的做法有兩種。您可以透過手動程序完成這項操作，並在發布端動態更新設定。如果發布要求的錯誤率相當高，發布商也可以自行更新設定。
訂閱者必須一律透過位置端點連線至主要區域。您可以決定訂閱者在下列任一觸發條件發生時，可以使用備用區域：
- 一律訂閱備用區域。在這種情況下，訂閱者會隨時維持與主要區域和備用區域的連線。發布者和訂閱者都可以使用相同的區域做為主要和備用區域。在這種情況下，只有在發布端發生故障時，訂閱端才會透過備援區域接收訊息。
- 手動偵測並透過設定將訂閱者切換至備用區域。如果您偵測到服務中斷，可以備援至備用區域，然後在服務中斷情形消除後，再移回主要區域。
- 在訂閱者發生錯誤時進行故障轉移。如果訂閱者要求傳回錯誤，您可以將此做為指標，表示您必須將服務移轉至備援區域。請注意，Pub/Sub 用戶端程式庫會在發生暫時性錯誤時，在內部重試串流拉取要求，因此您可能無法偵測到長時間出現的未預期錯誤。此外，即使在正常運作期間，串流提取錯誤率也應為 100%。
- 如果訂閱者在一段意外的長時間內未收到訊息，就會發生備援。假設訊息會持續發布，訂閱者就能隨時接收訊息。如果長時間未收到任何訊息，主要區域的 Pub/Sub 可能會發生訂閱端問題。這會透過轉移至備用區域來修正。
在四個選項中，第一個選項是最佳選擇。如果訂閱者連線沒有任何訊息流量，就不會產生任何費用。唯一的成本是訂閱者用戶端程式庫的額外執行個體足跡，但這項成本可以忽略不計。您也必須留意每個區域的開放串流提取連線數量配額。
第二種模式的優點是，由於訊息只會發布一次，因此 Pub/Sub 費用不會有乘數。不過，某些類型的服務中斷情況會產生權衡，在服務中斷開始前發布的訊息，可能要等到服務中斷問題解決後才能使用。儲存在無法使用的區域中的訊息，可能無法傳送給訂閱者，無論他們連線的位置為何。在停機期間發布至備用區域的訊息可能會可用。此外，發布商或訂閱者可能會遇到一段無法使用的期間，且錯誤率也會隨之增加。這取決於用來偵測停機情況的方法，以及備用區域的異動時間。
無論您選擇哪個選項，請注意這可能會如何與 Pub/Sub 的功能互動。有序傳送和僅傳送一次都會在區域內提供保證。舉例來說，如果您使用備援復原技術，系統只會保證在同一區域內發布的訊息會依序傳送。即使訊息先發布至主要區域，訂閱端仍可能會先收到發布至備用區域的訊息。
微調發布商
無論您選擇哪個備援選項，都需要在發布商端採取一些額外的調整步驟。調整發布商行為，確保在高負載下發揮最佳效能。訊息批次處理是一種可降低延遲並節省成本的方法，但不太涉及可靠性問題，因此本文不會討論這項做法。請改為著重於其他可用於調整可靠性的參數，包括重試設定和流程控管設定。
發布作業可能會因各種原因失敗，包括網路無法使用等暫時性問題，或需要使用者介入的權限變更等問題。Pub/Sub 用戶端程式庫會使用 重試設定中指定的參數，重試暫時性錯誤。這些設定可控制因暫時性原因而失敗的發布 RPC 重試時，指數輪詢的行為。雖然預設設定通常可在大多數情況下正常運作，但在某些情況下，您可能需要調整這些值。
您最有可能想要調整的兩個屬性是初始 RPC 逾時和總逾時。初始 RPC 逾時時間是指首次發布 RPC 完成所需的時間。如果任何 RPC 失敗或逾時，系統會嘗試使用較長的逾時時間，直到超過要求總數或總逾時時間為止。
如果發布端受到網路限制，或距離執行 Pub/Sub 的最近 Google Cloud 資料中心太遠，您可以調整初始逾時時間。網路限制可能是發布者執行所在機器的吞吐量限制，也可能是在同一部機器上執行的其他服務造成的網路密集效應。如果逾時時間設定得太短，初始 RPC 可能會屢次失敗，導致需要進行更多次嘗試 (逾時時間更長)，才能成功發布。重複嘗試的次數越多，發布延遲時間就會越長。在這種情況下，增加初始逾時時間可能會加快發布速度。
如果網路連線不穩定，提高總逾時時間和初始逾時時間可能會有所幫助。延長總超時時間可讓發布 RPC 有更多時間順利完成。如果發布 RPC 一再失敗，並出現超出期限的錯誤，請考慮調整這些值。
發布作業持續超出期限的錯誤，也可能表示需要調整發布者流量控制。這些設定可確保發布者能因應流量激增，避免因產生更多訊息而導致 Pub/Sub 超載。大量傳出要求可能會使發布端的 CPU、記憶體或網路容量超載。當發布作業超載時，系統無法在逾時前處理發布要求或回應。這會導致發布要求數量增加，最終達到總時限。發布者資料流控制會限制未收到發布要求回應時，可保留的訊息或位元組數量。以這種方式限制要求次數，可讓資源使用率保持在可控的程度，即使在尖峰期間也是如此。視發布商的運作方式而定，您可以允許發布功能封鎖後續要求，讓後續發布 RPC 等待容量。或者，您也可以在達到容量時，讓資料流控制傳回錯誤，以便將控制權推回服務的呼叫端。您可以設定發布商用戶端程式庫如何回應超出限制的行為。
微調訂閱者
您可能也需要調整訂閱項目，確保其運作正常。與發布商一樣，您可以調整訂閱者的流量控管設定，確保他們不會感到不堪負荷。訂閱者用戶端程式庫會使用串流提取功能，用戶端會開啟至伺服器的持續性串流，而伺服器會在訊息可用時傳送訊息。如果發布的訊息數量大幅增加，訂閱者可能會收到過多訊息而無法處理。在啟用流程控制後，客戶端同時處理的未確認訊息數量就會受到限制。這樣一來，系統就能減少同時處理的訊息數量，並在較長的時間內分散處理這些訊息。分散負載可讓訂閱者維持在任何影響訊息處理作業的資源限制範圍內，否則可能會產生連鎖效應，導致無法處理任何訊息。
如果您只預期處理資料量會出現尖峰，且最終會下降，那麼單獨使用流量控制就足夠了。如果流量因用量增加而持續增加，流量控制功能會保護訂閱者。不過，這可能會導致待處理的郵件持續累積，導致郵件無法在訊息保留期限過後傳送。在這種情況下，您可能也想設定自動調度資源功能，以便在未確認訊息數量增加時增加訂閱者。設定方式取決於您為訂閱者使用的運算平台。舉例來說，Compute Engine 的自動調度器可讓您根據未送達訊息數量等指標調整資源。同時使用自動調整大小和流量控管功能，可確保訂閱者能夠因應其他短時間內的訊息傳送量激增，以及需要更多運算能力的長期成長。請務必遵循使用 Pub/Sub 指標做為調整信號的最佳做法。
使用快照並尋求安全的部署方式
郵件遺失通常是重大事件。Pub/Sub 會為所有發布的訊息提供至少一次的傳送保證。不過，這些訊息的正確處理方式取決於訂閱者行為。如果訊息已成功確認，Pub/Sub 就不會重新傳送這些訊息。因此，如果您部署的新訂閱者程式碼引入錯誤，導致未正確處理訊息就確認訊息，就可能導致訂閱者導致訊息遺失。Pub/Sub 提供快照和搜尋功能，可確保您正確處理每則訊息，即使遇到訂閱者錯誤也一樣。
每個訂閱者部署的模式必須如下所示：
系統會等待一段時間，再判斷新訂閱者是否正常運作，這段時間的長短可能因用途而異。只有在系統判定訂閱者運作時，才能退出步驟流程，這時系統才能刪除快照。
使用快照和搜尋功能，並非要取代在非正式版環境中先執行軟體，然後逐步部署至正式版的最佳做法。可提供額外層級的保護，確保資料處理可靠。但相對的，尋找快照可能會導致重複傳送訂閱者已成功處理的訊息。不過，由於 Pub/Sub 預設採用至少一次的傳送語意，因此訂閱者已能應對訊息重新傳送。