本指南將協助您瞭解 Pub/Sub 的可靠性功能，並提供整體概覽。
Pub/Sub 的優點
發布/訂閱是一種訊息傳遞模式，旨在將訊息的產生者與訊息的消費者分離。產生者不會直接向消費者傳送資料要求，而是將資料發布至 Pub/Sub 等 Pub/Sub 服務。這項服務會以非同步方式，將這些訊息傳送給已訂閱的感興趣消費者。
因此，這項服務會吸收所有尋找對資料感興趣的消費者的複雜性。這項服務也會根據消費者的容量，管理消費者接收資料的速率。這種分離機制可讓資料產生者以低延遲時間大規模寫入訊息，不受消費者行為影響。
Pub/Sub 提供高度擴充、可靠的訊息傳遞服務。雖然這項服務會自動處理大部分作業，但您仍可控管發布者和訂閱者的不同層面，這些層面可能會影響可用性和效能。本指南其餘部分將詳細說明這些方面。
隔離
Pub/Sub 預設為全域服務：主題和訂閱項目本身不會與特定區域繫結，訊息會視需要在區域之間的 Pub/Sub 服務中流動。使用全域端點 pubsub.googleapis.com 時，發布者和訂閱者會連線至執行 Pub/Sub 的網路最近區域。使用區域端點 (例如 pubsub.us-central1.rep.googleapis.com) 或位置端點 (例如 us-central1-pubsub.googleapis.com) 時，發布者和訂閱者會連線至指定區域中的 Pub/Sub。在 Google Cloud外部執行發布者或訂閱者時，建議使用區域或位置端點，確保訊息在預期區域之間穩定傳輸。
區域隔離
如要盡量減少發布和訂閱作業在單一區域外依賴的基礎架構，並確保所有資料都與該區域隔離，請按照下列步驟操作：
為每個區域建立主題。
Pub/Sub 的命名空間是全域性的，您無法將主題和訂閱項目繫結至特定區域，但所有資源的中繼資料都會複製到該區域內的本機資料儲存庫。因此，建立資源後，即使其他區域發生問題，您仍可使用該資源的設定。請注意，如果發生服務中斷，主題或訂閱項目的設定更新可能不會立即生效。
避免使用全域端點。
請改用區域端點 (如有)，或位置端點 (如果沒有區域端點)。區域端點提供更完善的區域隔離功能，但目前並非所有區域都支援。
使用訊息儲存政策，並將
enforceInTransit設為True。如果強制執行傳輸中，資料就不會離開該區域，且所有連線至特定區域主題的用戶端，都會將訊息儲存政策設為該區域。
以這種方式設定主題，可確保所有發布和訂閱作業都只在該區域內寫入及讀取資料。如果單一區域中的發布端、訂閱端或 Pub/Sub 發生故障，該區域就會停止傳送訊息。其他區域的主題和訂閱項目訊息傳遞不受影響。
如果您也需要將主題和訂閱項目的管理作業和命名空間區域隔離，建議使用 Managed Service for Apache Kafka。
容錯移轉
如果您不需要區域隔離，可以利用 Pub/Sub 在多個區域之間有效傳遞訊息的能力，實現多區域容錯移轉功能。本節其餘部分將說明如何建立主題和訂閱項目，以及如何安排發布者和訂閱者，以支援不同類型的容錯移轉和資料備援。
預設容錯移轉語意
假設有一個主題和一個訂閱項目。發布者位於美國和澳洲地區，訂閱者則位於歐洲和澳洲的 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 且需要最高可用性的 Google 內部服務，建議採用這項設定。不過，這種設定的代價是訊息傳遞費用會乘以使用的區域數量。此外，如果訊息必須跨區域移動，則會產生跨區域網路用量的額外費用。
另一種備援方法是，只有在要求失敗或訊息未如預期從發布者傳送至訂閱者時，才進行容錯移轉。在這個情境中，您有一個主要區域，並透過位置端點將發布者和訂閱者導向該區域。和之前一樣，這些不一定要是相同區域。您也可以為發布者和訂閱者設定備用區域，在主要區域無法使用時派上用場。
如果要求傳送成功，發布者只會發布至主要區域 (透過位置端點)。只要系統判定區域故障，發布者就會改為發布至備用區域。判斷區域是否停機並進行容錯移轉的方法有兩種。這項作業可以手動完成，且發布商會動態更新設定。如果發布要求的錯誤率過高，發布者也可以自行更新設定。
訂閱者必須一律透過位置端點連線至主要區域。您可以決定訂閱者可使用備用區域，並搭配下列一或多個觸發條件：
- 一律訂閱備用區域。在這種情況下，訂閱者會隨時與主要區域和備用區域保持連線。發布者和訂閱者的主要和備用區域可以相同。如果是這種情況，則只有在發布端容錯移轉時，訂閱端才必須透過備份區域接收訊息。
- 透過設定手動偵測並將訂閱者切換至備用區域。如果偵測到服務中斷，可以容錯移轉至備用區域，並在服務中斷情形緩解後，移回主要區域。
- 在訂閱者發生錯誤時進行容錯移轉。如果訂閱者要求傳回錯誤，就表示您必須容錯移轉至備用區域。請注意，Pub/Sub 用戶端程式庫會在發生暫時性錯誤時，在內部重試串流提取要求，因此您可能無法偵測到長時間的非預期錯誤。此外，即使在正常運作期間，串流提取錯誤率也預期會達到 100%。
- 如果訂閱者長時間未收到訊息，請進行容錯移轉。假設訊息發布頻率穩定，訂閱者就能持續接收訊息。如果長時間未收到任何訊息，主要區域的 Pub/Sub 訂閱端可能發生問題。只要容錯移轉至備用區域，即可解決這個問題。
在這四個選項中，第一個選項最理想。如果沒有訊息流經訂閱者連線，則不會產生任何費用。唯一的成本是訂閱者用戶端程式庫額外執行個體的資源佔用量，這可以忽略不計。您也必須留意每個區域的 StreamingPull 開放連線數量配額。
第二種模型的優點是，由於訊息只會發布一次，因此 Pub/Sub 費用不會有乘數。不過，缺點是對於某些類型的服務中斷，在服務中斷前發布的訊息可能要等到服務中斷解決後才能使用。儲存在無法使用區域的訊息可能無法傳送給訂閱者，無論訂閱者連線至何處。在服務中斷期間發布至備用區域的訊息可能可供使用。此外，發布者或訂閱者的錯誤率可能會增加，導致服務暫時無法使用。這取決於偵測服務中斷的方法，以及容錯移轉至備用區域所需的時間。
無論選擇哪種選項，請留意這可能會與 Pub/Sub 的功能互動。依序傳送和僅傳送一次功能，都能保證在區域內完成傳送。舉例來說，如果使用容錯移轉備援技術，系統只會保證在同一區域發布的訊息會依序傳送。即使訊息先發布至主要區域，訂閱端仍可能先收到發布至備用區域的訊息，再收到發布至主要區域的訊息。
微調發布商
無論選擇哪種容錯移轉選項，您都需要在發布端執行一些額外的調整步驟。調整發布者行為，確保在高負載下達到最佳效能。批次處理訊息是降低延遲時間和成本的方法，但與可靠性無關，因此不在本文討論範圍內。請改為著重於其他有助於調整可靠性的參數，包括重試設定和流量控制設定。
發布作業可能因各種原因而失敗，包括網路無法使用等暫時性原因，或需要使用者介入處理的原因 (例如權限變更)。Pub/Sub 用戶端程式庫會使用重試設定中指定的參數，重試暫時性錯誤。這些設定可控管發布 RPC 因暫時性原因而失敗時，重試的指數輪詢行為。雖然預設設定通常適用於大多數情況，但有時您可能需要調整這些值。
您最可能需要調整的兩個屬性是初始 RPC 逾時和總逾時。初始 RPC 逾時是指第一個發布 RPC 完成所需的時間。如果任何 RPC 失敗或逾時，系統會嘗試另一個逾時時間較長的 RPC，直到超過要求總數或總逾時時間。
如果發布端受到網路限制，或距離執行 Pub/Sub 的最近 Google Cloud 資料中心很遠，則可調整初始逾時。網路限制可能是發布者執行所在機器的處理量限制，也可能是同一部機器上執行的其他服務需要大量網路資源。如果逾時時間設得太短，初始 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 預設採用至少傳送一次的語意，因此訂閱端已具備訊息重新傳送的彈性。