Spanner 佇列總覽

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

選擇 Spanner 佇列或變更串流

下列比較可做為選擇資料傳播和非同步處理機制的指引。

Spanner 佇列

適用情境

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

主要特性

  • 使用者定義的小型訊息酬載
  • 訊息消費的提取模式
  • 依據 Spanner 執行個體運算資源調度

Spanner 變更串流

適用情境

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

主要特性

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

主要優點

Spanner 佇列具有下列優勢：

  • 整合：訊息功能已整合至資料庫。這樣一來，您就不必佈建、管理及竊取資料至獨立的訊息基礎架構，進而簡化應用程式架構並降低整體成本。
  • 交易：您可以在 Spanner 交易中，與其他資料庫寫入作業一起傳送及確認訊息。如果交易失敗，排入佇列的訊息會復原，且無法傳送。
  • 持久：無法傳送的訊息會儲存在資料庫中。Spanner 會持續嘗試傳送訊息，並採用輪詢機制，直到訊息明確確認或刪除為止。
  • 可查詢：訊息是以與 Spanner 資料表相同的原始物件建構，並以資料列的形式儲存。您可以像查詢、彙整或篩選標準資料表一樣，對這些資料表執行相同操作。
  • 可擴充：訊息處理功能與 Spanner 資料表一樣可擴充，能與資料庫的其他部分一起擴充。
  • 可靠：Spanner 佇列繼承 Spanner 的所有高可用性原始物件，因此訊息傳送和處理作業具備容錯能力，可因應可用區或區域故障。
  • 可排程：訊息可排定在日後傳送，讓您將工作執行時間延後到未來的特定時間戳記。
  • 不可分割：訊息傳送 (INSERT 或異動 API) 和確認 (DELETE 或異動 API) 會在交易中不可分割地執行，確保與資料庫狀態一致。
  • 可擴充：結合未來傳送和手動租賃機制，即可延長訊息租賃時間，支援極長的處理時間。

用途

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

  • 延遲運算量大的工作：相片分享網站可能需要在上傳新相片時執行密集的圖片處理。寫入新相片中繼資料的交易可以同時寫入佇列訊息。佇列接收器稍後會擷取訊息、執行處理，並以交易方式更新中繼資料。
  • 延遲大型交易更新：在日曆應用程式中，在單一交易中邀請大型群組參加會議可能會導致鎖定衝突和尾端延遲。相反地，建立日曆項目的交易可以為每位邀請對象新增佇列項目，讓接收者個別傳送邀請。
  • 排定未來工作：提供 30 天免費試用期的軟體即服務 (SaaS) 公司可以佈建使用者資源，同時將排定在 30 天內傳送的訊息排入佇列。接著，worker 會收到訊息並執行試用期到期邏輯。
  • 將工作延遲至外部系統：使用者註冊後，應用程式可能只有在資料庫註冊成功時，才需要傳送歡迎電子郵件。註冊交易可將項目新增至佇列，讓工作站稍後叫用外部電子郵件 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 佇列有下列限制：

  • 接收器數量上限：每個佇列中，具有相同引數的作用中接收查詢數量上限為 1000 個
  • 並行接收 TVF 配額限制：每個專案在每個區域的並行接收 TVF 配額限制為 2,000 個。如要提高配額上限，請填寫要求提高 Cloud Spanner 專案配額表單。
  • 手動分割：佇列不支援 AddSplits API。工作負載分配完全依據負載分割。建議您在資料表中交錯佇列，以便使用者在資料表中新增分割點。
  • 地理區域分區法規遵循：執行 DROP PARTITION 作業後，地理區域分區佇列不符合資料落地法規。
  • 佇列數量限制：如果執行個體有 1 個以上節點，則佇列數量上限為 100 個。如果是精細執行個體，限制會按比例縮減 (例如，具有 200 個處理單元的執行個體，限制為 20 個佇列)。
  • PostgreSQL 資料欄命名：Spanner 會公開 deliver_time 和 DeliverTime 資料欄，用於訊息的傳送時間。建議您使用 deliver_time 資料欄，以符合 標準 PostgreSQL 命名慣例，因為 DeliverTime 資料欄會在日後 版本中從資訊結構定義中隱藏。
  • 具名結構定義：無法在具名結構定義中建立佇列。

後續步驟