本指南將說明 Pub/Sub 可靠性功能，並提供整體概況。
為何要使用 Pub/Sub？
發布/訂閱訊息範例旨在將訊息產生者與訊息取用者分離。生產者不會直接將資料傳送給消費者，而是將資料發布至 Pub/Sub 等 Pub/Sub 服務。這項服務會以非同步方式將這些訊息傳送給已訂閱的感興趣消費者。
因此，這項服務會吸收所有尋找對資料感興趣的消費者時的複雜性。這項服務也會根據消費者的容量，管理消費者接收資料的速率。這種分離式設計可讓資料產生者以低延遲率大量寫入訊息，不受消費者行為影響。
Pub/Sub 提供高度可擴充的可靠訊息傳遞服務。雖然這項服務會自動處理大部分作業，但您可以控管發布者和訂閱者的不同層面，進而影響可用性和效能。本指南的其餘部分會詳細說明這些層面。
隔離
根據預設，Pub/Sub 是全域服務：主題和訂閱項目並非與特定區域相關聯，且訊息會在 Pub/Sub 服務中於區域間流動 (如有需要)。使用全球端點時，發布者和訂閱者會連線至 Pub/Sub 執行的網路最近區域。pubsub.googleapis.com使用區域端點 (例如 us-central1-pubsub.googleapis.com) 或位置端點 (例如 pubsub.us-central1.rep.googleapis.com) 時，發布者和訂閱者會連線至指定區域的 Pub/Sub。在 Cloud de Confiance以外的區域執行發布者或訂閱者時，最好使用區域或位置端點，確保訊息在預期區域之間穩定流動。
區域隔離
如要盡量減少發布和訂閱作業在單一區域外部所依附的基礎架構，並確保所有資料都只會留存在該區域，請按照下列步驟操作：
為每個區域建立主題。
雖然 Pub/Sub 的命名空間是全域性的，且您無法將主題和訂閱項目繫結至特定區域，但所有資源的中繼資料都會複製到區域內的本機資料儲存庫。因此，建立資源後，即使其他區域發生問題，資源設定仍可使用。請注意，如果發生服務中斷，主題或訂閱設定的更新可能不會立即傳播。
請避免使用全域端點。
使用訊息儲存政策，並將
enforceInTransit設為True。啟用「強制執行傳輸中」後，資料絕不會離開該區域，且連線至特定區域中主題的所有用戶端，都會將訊息儲存空間政策設為該區域。
以這種方式設定主題後，您就能確保所有發布和訂閱作業都會在區域內寫入及讀取資料。如果單一區域發生發布端、訂閱端或 Pub/Sub 故障，該區域的訊息傳送作業就會停止。其他區域的主題和訂閱項目不受影響。
如果需要區域隔離主題和訂閱項目的管理作業和命名空間，請考慮使用 Managed Service for Apache Kafka。
容錯移轉
如果您不需要區域隔離，不妨善用 Pub/Sub 在多個區域有效傳送訊息的功能，以實現多區域容錯移轉功能。本節其餘內容將說明如何建立主題和訂閱項目，以及如何放置發布端和訂閱端，以支援不同類型的容錯移轉和資料備援。
預設容錯移轉語意
假設只有一個主題和訂閱項目。發布者位於美國和澳洲境內，訂閱者則位於歐洲和澳洲境內 Cloud de Confiance 。如果所有訂閱者都有足夠容量接收訊息，訊息流程如下：
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 且需要最高可用性的 Google 內部服務，建議採用這項設定。不過，這項設定的缺點是，訊息傳送費用會乘以使用的區域數量。如果訊息必須跨區域傳輸，還會產生額外的跨區域網路用量費用。
另一種做法是，只有在要求失敗或訊息未如預期從發布商傳送至訂閱者時，才進行容錯移轉。在這個情境中，您有一個主要區域，可透過位置端點將發布者和訂閱者導向該區域。與先前一樣，這些區域不必相同。這樣一來，發布者和訂閱者在主要區域無法使用時，也能使用備援區域。
發布商只會在要求傳送成功時，發布至主要區域 (透過位置端點)。如果系統判斷該區域發生故障，發布商就會改為發布至備援區域。判斷區域是否停機並進行容錯移轉的方式有兩種。這項作業可以透過手動程序完成，發布商的設定也會動態更新。如果發布要求中的錯誤率夠高，發布商也可以自行更新設定。
訂閱者一律須透過位置端點連線至主要區域。 您可以決定訂閱者是否能使用備用區域，並設定一或多個觸發條件，例如：
- 請務必訂閱備用區域。在這種情況下，訂閱者會隨時與主要區域和備援區域保持連線。發布者和訂閱者都可以使用相同的區域做為主要和備援區域。如果是這種情況，發布商容錯移轉後，訂閱者就只能透過備份區域接收訊息。
- 透過設定手動偵測訂閱者，並將他們切換至備援區域。如果偵測到服務中斷，可以容錯移轉至備用區域，然後在服務中斷情況解除後，再移回主要區域。
- 訂閱者發生錯誤時進行容錯移轉。如果訂閱者要求傳回錯誤，表示您必須容錯移轉至備援區域。請注意，Pub/Sub 用戶端程式庫會在發生暫時性錯誤時，於內部重試串流提取要求，因此您可能無法偵測到長時間的非預期錯誤。此外，即使在正常運作期間，串流提取錯誤率也預計會達到 100%。
- 如果訂閱者在一段時間內未收到訊息，請執行容錯移轉。假設訊息發布作業持續進行，訂閱者就能持續收到訊息。如果訂閱端長時間未收到任何訊息，可能是主要區域的 Pub/Sub 發生訂閱端問題。這項問題可透過容錯移轉至備援區域來修正。
在四個選項中，第一個是理想選擇。如果沒有訊息流動，訂閱端連線就不會產生任何費用。唯一需要付費的是訂閱者用戶端程式庫額外執行個體的足跡，這筆費用可能微不足道。此外，您也必須留意每個區域的串流提取開放連線數量配額。
第二個模型的優點是 Pub/Sub 費用不會有乘數，因為訊息只會發布一次。但缺點是，如果發生特定類型的服務中斷，可能要等到問題解決後，才能存取中斷前發布的訊息。如果訊息儲存在無法使用的區域，無論訂閱者連線到哪個區域，都可能無法收到訊息。在服務中斷期間發布至備援區域的訊息可能仍可使用。此外，發布者或訂閱者可能會遇到一段時間的服務中斷，導致錯誤率提高。這取決於偵測中斷的方法，以及容錯移轉至備援區域的時間。
無論選擇哪個選項，請注意這可能會如何與 Pub/Sub 的功能互動。依序傳送和僅傳送一次功能，都能在區域內提供保證。舉例來說，如果您使用容錯移轉備援技術，系統只會保證在同一區域發布的訊息會依序傳送。即使訊息是先發布至主要區域，訂閱端也可能會先收到發布至備援區域的訊息。
微調發布商
無論選擇哪種容錯移轉選項，都必須在發布商中執行一些額外的調整步驟。調整發布商行為可確保在高負載下發揮最佳效能。批次處理訊息可降低成本，但會造成延遲，因此不屬於可靠性問題，本文不會介紹。請改為著重於其他有助於調整可靠性的參數，包括重試設定和流量控制設定。
發布作業可能會因各種原因而失敗，包括網路無法連線等暫時性問題，或是需要使用者介入處理的問題，例如權限變更。Pub/Sub 用戶端程式庫會使用重試設定中指定的參數，重試暫時性錯誤。這些設定可控管因暫時性原因而失敗的發布 RPC 重試作業，其指數輪詢行為。雖然預設設定通常適用於大多數情況，但有時您可能需要調整這些值。
您最可能想調整的兩個屬性是初始遠端程序呼叫 (RPC) 逾時和總逾時。初始 RPC 逾時是指第一個發布 RPC 完成的時間長度。如果任何 RPC 失敗或逾時，系統會嘗試使用較長的逾時時間，直到超過要求總數或逾時總時間為止。
如果發布者受到網路限制，或距離執行 Pub/Sub 的最近 Cloud de Confiance by S3NS 資料中心很遠，可以調整初始逾時。網路限制可能是發布端執行的電腦處理量限制，也可能是同一部電腦上執行的其他服務耗用大量網路資源所致。如果逾時時間設定過短，初始 RPC 可能會重複失敗，導致需要更多嘗試 (逾時時間較長) 才能成功發布。如果需要重複重試，發布延遲時間就會增加。在這種情況下，增加初始逾時時間可能會加快發布速度。
如果網路連線不穩，增加總逾時時間和初始逾時時間可能有幫助。增加總逾時時間可讓發布 RPC 有更多時間順利完成。如果發布 RPC 持續失敗並出現逾時錯誤，請考慮調整這些值。
如果發布作業持續發生逾時錯誤，可能表示需要調整發布者流量控制。您可以透過這些設定，確保發布商能因應傳入流量暴增的情況，因為這類情況會產生更多要傳送至 Pub/Sub 的訊息。如果傳送的請求大幅增加，發布商的 CPU、記憶體或網路容量可能會過載。發布作業負載過重時，系統無法在逾時前處理發布要求或回應。這會導致更多發布要求，最終達到總逾時時間。發布商流程控制項會限制可待處理的訊息或位元組數量，而這些訊息或位元組尚未收到發布要求的相關回應。以這種方式限制要求數量，即使在尖峰時段，資源用量也能維持在可管理的程度。視發布商的運作方式而定，您可以允許發布作業封鎖後續要求，讓後續發布 RPC 等待容量。或者，您也可以在達到容量上限時，讓流量控制傳回錯誤，將呼叫端推回服務。您可以設定發布商用戶端程式庫的回應方式，以處理超出限制的行為。
微調訂閱者
此外，可能也需要調整訂閱者，確保訂閱者能穩定運作。與發布商類似，您可以調整訂閱者的流量控制設定，確保他們不會收到過多訊息。訂閱端用戶端程式庫會使用串流提取，也就是用戶端開啟與伺服器的持續串流，而伺服器會在訊息可用時傳送訊息。如果發布的訊息大幅增加，訂閱者收到的訊息可能會超出處理能力。有了流量控制機制，用戶端一次未確認的待處理訊息數量就會受到限制。這樣可以減少同時處理的訊息數量，並延長處理時間。分散負載可讓訂閱端維持在資源限制內，避免影響訊息處理作業，否則可能會產生連鎖效應，導致無法處理任何訊息。
如果您預期資料處理量最終會回歸正常，單靠流量控制就已足夠。如果流量通常會隨著使用量增加而增加，流量控制功能可保護訂閱者。不過，這可能會導致待處理項目持續累積，且訊息在保留期限到期前無法傳送。在這種情況下，您可能也想設定自動調度資源機制，以便在未確認的訊息數量增加時，增加訂閱者人數。設定方式取決於訂閱者使用的運算平台。舉例來說，Compute Engine 的自動調整功能可讓您根據未傳送的訊息數量等指標進行調整。同時使用自動調整規模和流量控制功能，可確保訂閱端能因應其他短期訊息處理量暴增的情況，以及需要更多運算能力的長期成長。請務必遵循使用 Pub/Sub 指標做為擴充訊號的最佳做法。
請改用區域版本的待辦事項指標，而非全球版本
監控訂閱項目待處理工作、設定警報政策或自動調整訂閱者規模時，Pub/Sub 會提供每個待處理工作指標的兩個版本。請務必使用含有 by_region 後置字元的版本：
如要確保監控、快訊和自動調整功能不會受到單一區域中斷影響，請勿使用這些指標的全球版本 (subscription/num_undelivered_messages 和 subscription/oldest_unacked_message_age)。如要計算這些指標的全球版本，必須計算所有已知有訊息的區域的待處理事項，這表示單一區域的服務中斷會導致資料缺漏。相較之下，指標的 by_region 版本會根據每個區域計算及回報積壓工作。如果無法計算單一區域的待處理工作，指標仍會回報其他區域的值。
使用快照並尋求安全部署
郵件遺失通常是災難性事件，Pub/Sub 會確保所有發布的訊息至少傳送一次。不過，系統能否正確處理這些訊息，取決於訂閱者的行為。如果訊息已成功確認，Pub/Sub 就不會重新傳送。因此，如果您部署的新訂閱者程式碼中出現錯誤，導致系統在未正確處理訊息的情況下確認訊息，可能會造成訂閱者訊息遺失。Pub/Sub 提供快照和搜尋功能，即使訂閱端發生錯誤，也能確保您正確處理每則訊息。
每個訂閱者部署作業的模式都必須如下所示：
判斷新訂閱者是否正常運作前，需要等待的時間長度可能因用途而異。只有在訂閱者被視為正常運作時，才能退出步驟流程，此時即可刪除快照。
使用快照和搜尋功能，並非為了取代在非正式環境中首次執行軟體，以及逐步部署至正式環境的最佳做法。可提供額外保護，確保資料處理作業的可靠性。但缺點是，搜尋快照可能會導致系統重複傳送訂閱端已成功處理的訊息。不過，由於 Pub/Sub 預設採用「至少傳送一次」的傳送語意，訂閱端已可靈活應對訊息重新傳送。