本指南可協助您瞭解 Pub/Sub 可靠性功能，並掌握整體情況。
為何要使用 Pub/Sub？
發布/訂閱訊息範例旨在將訊息供應商與訊息消費者分離。生產者不會直接將資料傳送給消費者，而是將資料發布至 Pub/Sub 等 Pub/Sub 服務。服務會以非同步方式將這些訊息傳送給已訂閱的感興趣消費者。
因此，這項服務會吸收所有尋找對資料感興趣的消費者時的複雜性。這項服務也會根據消費者的容量，管理消費者接收資料的速率。資料生產者可透過這項分離機制，以低延遲率大規模寫入訊息，不受消費者行為影響。
Pub/Sub 提供高度可擴充的可靠訊息傳遞服務。雖然這項服務會自動處理許多事項，但您可以控管發布者和訂閱者的不同層面，進而影響可用性和效能。本指南的其餘部分將詳細說明這些方面。
隔離
根據預設，Pub/Sub 是全域服務：主題和訂閱項目不會與特定區域綁定，訊息會在 Pub/Sub 服務中，視需要於不同區域之間流動。使用全域端點 pubsub.googleapis.com 時，發布者和訂閱者會連線至 Pub/Sub 執行的網路最近區域。使用區域端點 (例如 us-central1-pubsub.googleapis.com) 或位置端點 (例如 pubsub.us-central1.rep.googleapis.com) 時，發布者和訂閱者會連線至指定區域的 Pub/Sub。在 Google Cloud以外的區域執行發布者或訂閱者時，最好使用區域或位置端點，確保訊息在預期區域之間穩定流動。
區域隔離
如要盡量減少發布和訂閱作業在單一區域外部依賴的基礎架構，並確保所有資料都與該區域隔離，請按照下列步驟操作：
為每個區域建立主題。
雖然 Pub/Sub 的命名空間是全域的，且您無法將主題和訂閱項目繫結至特定區域，但所有資源的中繼資料都會複製到區域內的本機資料儲存庫。因此，建立資源後，即使其他區域發生問題，資源的設定仍可使用。請注意，如果發生服務中斷，主題或訂閱設定的更新可能不會立即傳播。
避免使用全域端點。
請改用地區端點 (如適用) 和位置端點 (如無法使用地區端點)。區域端點可提供更多區域隔離功能，但目前僅在部分區域推出。
使用訊息儲存空間政策，並將
enforceInTransit設為True。啟用「強制執行傳輸中」後，資料絕不會離開該區域，且連線至特定區域中主題的所有用戶端，都會將訊息儲存空間政策設為該區域。
這樣設定主題後，您就能確保所有發布和訂閱作業都會在區域內寫入及讀取資料。如果單一區域發生發布端、訂閱端或 Pub/Sub 故障，該區域的訊息傳送作業就會停止。其他地區的主題和訂閱項目不受影響，仍可正常傳送訊息。
如果您也需要區域隔離主題和訂閱項目的管理作業和命名空間，請考慮使用 Managed Service for Apache Kafka。
容錯移轉
如果您不需要區域隔離，可以利用 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 故障，您必須準備好容錯移轉機制，以因應這類中斷情形。可能的方法是在端對端訊息傳送延遲時間和成本之間取捨。
如果成本不是問題，為了盡量減少延遲，最佳策略是在不同區域同時發布及訂閱。首先，請選擇要提供備援的區域數量。 接著，您可以為每個區域設定主題和訂閱項目 (雖然並非必要)。
每個發布商會為每個區域建立一個發布商用戶端，並使用不同的位置端點，確保訊息會傳送至不同區域。如果使用個別主題，每個發布商用戶端都必須發布至對應的區域主題。發布者會針對每個訊息，在每個用戶端上呼叫發布。有了多餘的發布作業，即使其中一項失敗，也不需要重試發布。
同樣地，每個訂閱者會建立許多訂閱者用戶端 (每個區域一個)，並使用位置端點連線至不同區域。如果每個地區使用不同的訂閱項目，則每個訂閱者用戶端都必須使用對應的訂閱項目。請注意，發布者和訂閱者使用的區域不一定相同。訂閱者會透過這三個訂閱項目接收訊息並加以處理。
這項設定有幾項重要功能和需求：
- 單一區域中斷不會影響已發布的訊息，也不會影響中斷期間發布的訊息。由於訊息已發布至多個區域，因此即使某個區域發生故障，其他區域仍可使用。在服務中斷期間，發布呼叫會在受影響區域失敗， 但在其他區域會成功。
- 只要訊息流經的任何區域可用，訊息處理延遲時間就不會受到影響。
- 訊息處理作業必須是冪等。由於每則訊息都會多次傳送，訊息處理程序必須能處理重複訊息。如果發生區域性服務中斷，部分重複訊息的傳送時間可能會比第一次傳送訊息晚很多。這些重複項目可能來自未發生中斷的地區。
以這種備援方式執行作業，可提供最高復原力，因應任何類型的服務中斷。如果內部 Google 服務依賴 Pub/Sub，且需要最高可用性，建議採用這種設定。不過，這項設定的缺點是，訊息傳送費用會乘以使用的區域數量。如果訊息必須跨區域傳送，還會產生額外的跨區域網路使用費。
另一種做法是只在要求失敗或訊息未如預期從發布商傳送至訂閱者時，才進行容錯移轉。在這個情境中，您有一個主要區域，可透過位置端點將發布者和訂閱者導向該區域。與先前一樣，這些區域不必相同。這樣一來，當主要區域無法使用時，發布者和訂閱者也能使用備援區域。
發布商只會在要求傳送成功時，發布至主要區域 (透過位置端點)。如果系統判斷該區域發生故障，發布商就會改為發布至備援區域。判斷區域是否停機並進行容錯移轉的方式有兩種。這項作業可透過手動程序完成，且發布商的設定會動態更新。如果發布要求中的錯誤率夠高，發布商也可以自行更新設定。
訂閱者一律須透過位置端點連線至主要區域。 您可以決定訂閱者是否能使用備用區域，並設定一或多個觸發條件，包括：
- 請務必訂閱備援區域。在這種情況下，訂閱者會隨時與主要地區和備援地區保持連線。發布者和訂閱者的主要和備援區域可以相同。如果是這種情況，只有在發布商容錯移轉時，訂閱者才必須透過備份區域接收訊息。
- 透過設定手動偵測訂閱者，並將他們切換至備援區域。如果偵測到服務中斷，可以容錯移轉至備用區域，並在服務中斷情況解除後移回主要區域。
- 訂閱者發生錯誤時進行容錯移轉。如果訂閱者要求傳回錯誤，表示您必須容錯移轉至備援區域。請注意，Pub/Sub 用戶端程式庫會在發生暫時性錯誤時，於內部重試串流提取要求，因此您可能無法偵測到長時間的非預期錯誤。此外，即使在正常運作期間，串流提取錯誤率也應為 100%。
- 如果訂閱者在一段時間內未收到訊息，請進行容錯移轉。假設訊息發布作業持續進行，訂閱者就能持續接收訊息。如果長時間未收到任何訊息，可能是主要區域的 Pub/Sub 訂閱端發生問題。這項問題已修正，方法是容錯移轉至備援區域。
這四個選項中，第一個最為理想。如果訂閱者連線沒有任何訊息流動，就不會產生費用。唯一需要付費的是訂閱者用戶端程式庫額外執行個體的足跡，這筆費用可能微不足道。此外，您也必須留意每個區域的 StreamingPull 開放連線數量配額。
第二個模型的優點是 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 預設採用「至少一次」的傳送語意，訂閱者已可應付訊息重新傳送的情況。