Spanner 佇列總覽

Spanner 佇列提供交易訊息功能，可協助您管理非同步工作。這項功能結合了 Spanner 的擴充性和可靠性，可讓您建構事件導向應用程式。Spanner 佇列使用提取模型來取用訊息，並公開 SQL 介面，供接收者要求及接收訊息。

選擇 Spanner 佇列或變更串流

下表比較結果可做為參考，協助您選擇合適的資料傳播和非同步處理機制。

Spanner 佇列

適用情境

  • 交易事件通知
  • 未來排定的工作執行時間
  • 訊息確認邏輯

主要特徵

  • 使用者定義的小型訊息酬載
  • 提取訊息的提取模型
  • 隨著 Spanner 執行個體運算資源調整

Spanner 變更串流

適用情境

  • 高處理量資料複製
  • 同步處理下游快取或索引
  • 記錄每項資料庫變更的稽核記錄

主要特徵

  • 擷取所有錄音片段 (最多 10 MB)
  • 使用分區權杖進行提取式串流
  • 包括心跳和檢查點

主要優點

Spanner 佇列具有下列幾項優點：

  • 整合：訊息已整合至資料庫。這樣一來，就不必佈建、管理及外洩資料至其他訊息基礎架構，可簡化應用程式架構並降低整體成本。
  • 交易：您可以在 Spanner 交易中，與其他資料庫寫入作業一起，以原子方式傳送及確認訊息。如果交易失敗，系統會回溯已加入佇列的訊息，且無法傳送這些訊息。
  • 耐久性：無法傳送的訊息會儲存在資料庫中。 Spanner 會持續嘗試傳送訊息，並在傳送失敗時延遲重試，直到訊息明確獲得確認或遭到刪除為止。
  • 可查詢：訊息與 Spanner 資料表採用相同的基本類型，並以資料列的形式儲存。您可以像查詢、聯結或篩選標準資料表一樣，
  • 可擴充：與 Spanner 表格採用相同的擴充性，訊息處理作業會隨著資料庫的其餘部分擴充。
  • 可靠：Spanner 佇列會沿用 Spanner 的所有高可用性基本類型，因此訊息傳送和處理作業具有容錯能力，且可因應區域或地區性故障。
  • 可排程：訊息可排定在日後傳送，讓您將工作執行時間延後至特定時間戳記。
  • 不可分割：訊息傳送 (INSERT 或修改作業 API) 和確認 (DELETE 或修改作業 API) 會在交易中以不可分割的形式執行，確保資料庫狀態一致。
  • 可延長：訊息租約可延長，結合未來傳送和手動租用機制，支援極長的處理時間。

用途

Spanner 佇列可用於自動化調度管理交易中的延後工作。常見例子包括：

  • 延後執行耗用大量運算資源的工作：相片分享網站可能需要在上傳新相片時執行密集圖像處理作業。寫入新相片中繼資料的交易可以同時寫入佇列訊息。佇列接收器稍後會接收訊息、執行處理作業，並以交易方式更新中繼資料。
  • 延後大型交易更新：在日曆應用程式中，如果單一交易邀請大量使用者參加會議，可能會導致鎖定衝突和尾端延遲。不過，建立日曆項目的交易可以為每位邀請對象新增佇列項目，讓接收者個別傳送邀請。
  • 排定日後執行的工作：如果軟體即服務 (SaaS) 公司提供 30 天免費試用期，可以佈建使用者的資源，並同時將預定在 30 天後傳送的訊息加入佇列。工作站隨後會收到訊息，並執行試用期到期邏輯。
  • 將工作延後至外部系統：使用者註冊後，應用程式可能需要等到資料庫註冊成功，才傳送歡迎電子郵件。註冊交易可將項目新增至佇列，讓工作人員稍後叫用外部電子郵件 API。
  • 調度管理多步驟管道：在訂單管理系統中，完成訂單需要多個步驟，每個步驟都可能失敗。將每個步驟表示為佇列訊息，系統就能檢查管道的狀態，並從失敗點繼續執行。

工作流程

Spanner 佇列的典型工作流程如下：

  • 建立佇列：使用 DDL 定義佇列，與資料表類似。其中必須包含 Payload 欄 (PostgreSQL 中的 payload) 和主鍵。
  • 傳送訊息：使用標準 DML (INSERT) 或修改作業 API，以交易方式將訊息加入佇列，並執行其他資料庫作業。
  • 接收訊息：使用 ExecuteStreamingSQL API 呼叫名為 RECEIVE_QUEUE_NAME() 的資料表值函式 (TVF)。這項函式會以長時間執行的查詢，將訊息串流傳送至用戶端。
  • 處理訊息：使用應用程式邏輯，處理從 TVF 收到的訊息。
  • 確認訊息：使用 DML (DELETE) 或變動 API (例如 ack) 從佇列中移除訊息。這通常是在處理完成後，於交易中進行。
  • 管理租約：管理訊息租約，確保 Spanner 佇列不會在租約逾時時重新傳送訊息。最常見的方法是使用 RENEWLEASE_QUEUE_NAME() TVF。

此外，請注意 Spanner 佇列的下列核心行為：

  • 至少傳送一次：大多數雲端佇列系統都採用這種方式，Spanner 也保證至少會傳送一次。延長租約可減少重新交付的次數。
  • 最多一次確認：由於確認訊息是透過交易進行，因此 Spanner ACID 語意可確保訊息只會確認一次。按照「僅須處理一次和最多確認一次」頁面的方法，正確實作最多確認一次。

限制

Spanner 佇列有下列限制：

  • 接收者上限：每個佇列最多可有 1,000 個使用相同引數的有效接收查詢
  • 同時接收 TVF 配額限制：每個專案每個區域的配額限制為 2000 個同時接收的 TVF。如要提高配額上限，請填寫「為 Cloud Spanner 專案申請提高配額」表單。
  • 手動分割：佇列不支援 AddSplits API。 工作負載分配完全取決於依負載進行分割。建議在表格中交錯顯示佇列，方便使用者在表格中新增分割點。
  • 地理區域分區法規遵循：執行 DROP PARTITION 作業後，地理區域分區佇列不符合資料落地規定。
  • 佇列數量限制：執行個體最多只能有 100 個佇列，且執行個體必須有 1 個以上的節點。如果是精細執行個體 (例如處理單元為 200 的執行個體)，上限會按比例縮減 (例如最多 20 個佇列)。
  • 捨棄並重新建立佇列：系統不完全支援捨棄並重新建立同名佇列。佇列的 RECEIVE TVF 可能需要一段時間才能「重設」，之後才能再次接收同名訊息。
  • PostgreSQL 資料欄命名：Spanner 會公開 deliver_time 和 DeliverTime 資料欄，顯示訊息的傳送時間。建議使用 deliver_time 欄，以符合標準 PostgreSQL 命名慣例，因為 DeliverTime 欄會在日後的版本中從資訊結構定義隱藏。
  • 具名結構定義：無法在具名結構定義中建立佇列。

後續步驟