使用佇列管理功能和 queue.yaml

本頁面說明使用 Cloud Tasks API 管理佇列和上傳 Cloud Tasks queue.yamlqueue.xml 檔案完成相同工作的差異,另外也會探討混用這兩種機制的一些陷阱,以及常見問題的處理方法。

簡介

Cloud Tasks API 針對 App Engine 工作佇列服務提供獨立於 App Engine 之外的介面。介面也提供佇列管理功能,包括透過主控台或 gcloud 指令進行這些作業。使用 Cloud Tasks API 建立的佇列可透過 App Engine SDK 加以存取,反之亦然。如要維護相容性,也可使用 App Engine SDK 使用的設定檔 queue.yaml 來建立並設定要透過 Cloud Tasks API 使用的佇列。不過,同時透過檔案與 Cloud Tasks API 進行設定,可能會產生非預期的結果。

queue.yaml 與 Cloud Tasks 佇列管理方法混合使用的陷阱

對於基礎服務來說,queue.yaml 檔案具有決定性。如果上傳的 queue.yaml 省略了專案中的現有佇列,無論這些佇列是如何建立的,都會遭到「停用」或暫停。因此如果您使用 Cloud Tasks API 呼叫 CreateQueueUpdateQueue,接著上傳會省略這些佇列的 queue.yaml 檔案,則會停用在 Cloud Tasks 呼叫中建立的佇列。

請考量下列情境:

  1. 呼叫 CreateQueue 建立名為「cloud-tasks-queue」的佇列。
  2. 上傳具有下列內容的 queue.yaml 檔案:

    queue:
    - name: queue-yaml-queue
    

這個專案中的佇列目前狀態為何?名為「cloud-tasks-queue」的佇列以及先前存在的任何其他佇列會處於 DISABLED 狀態,而名為「queue-yaml-queue」的佇列則為 RUNNING 狀態。

如果您是透過 Cloud Tasks API 建立佇列,這個行為可能會出乎您的預料。下方的操作說明提供了恢復已停用佇列的方法。

同樣地,如果在 Cloud Tasks API 中停用佇列,但佇列之後出現在上傳的 queue.yaml 檔案中,則會恢復該佇列。

如果使用 DeleteQueue 方法刪除佇列,但佇列之後出現在 queue.yaml 檔案中,則 queue.yaml 可能會上傳失敗,因為系統不允許在佇列刪除後的幾天內就再次使用相同的佇列名稱。

最佳做法

如果您是第一次使用 Cloud Tasks 或 App Engine,請單獨使用 Cloud Tasks API 管理佇列,避免同時使用 queue.yamlqueue.xml。Cloud Tasks 佇列管理方法可讓使用者在建立、更新及刪除佇列時有更多選擇。

不過,如果您目前使用 queue.yamlqueue.xml,並且考慮改用佇列管理方法,請務必先瞭解混用 queue.yaml 與 Cloud Tasks 佇列管理方法的陷阱

如要強制只使用一種設定方法,建議您使用群組與權限來控管佇列管理活動的存取權。如需操作說明,請參閱保護佇列設定

除錯

您可以檢查專案的管理員活動稽核記錄以擷取佇列設定變更的記錄,包括佇列的建立、更新及刪除:

    gcloud logging read \
      'protoPayload.methodName=
       (com.google.appengine.legacy.queue_created OR
        com.google.appengine.legacy.queue_updated OR
        google.cloud.tasks.v2.CloudTasks.CreateQueue OR
        google.cloud.tasks.v2.CloudTasks.UpdateQueue OR
        google.cloud.tasks.v2.CloudTasks.DeleteQueue)'

舉例來說,如果上傳 queue.yaml 而導致現有佇列停用,則會透過 com.google.appengine.legacy.queue_updated 方法在稽核記錄中顯示「Disabled queue '[QUEUE_NAME]'」訊息。

如何恢復由於上傳 queue.yaml 而遭停用的佇列

如果您混用 queue.yaml 和 Cloud Tasks 佇列管理方法,上傳 queue.yaml 檔案可能會意外停用透過 Cloud Tasks API 建立的佇列。

如要恢復佇列,您可以對佇列呼叫 ResumeQueue,或將其新增到 queue.yaml 並上傳檔案。請注意,如果您先前已在 queue.yaml 設定中針對佇列設定自訂處理 rate,則 ResumeQueue 會將佇列重設為預設的 rate。這會反映在對 ResumeQueue 的回應的 maxTasksDispatchedPerSecond 欄位。

Cloud Tasks 佇列管理方法的其他相關資訊

佇列設定與佇列啟動延遲

對佇列設定進行的變更可能需要幾分鐘時間才會生效。舉例來說,呼叫 CreateQueueUpdateQueue 後,可能要等待幾分鐘時間,您才可以在該佇列上成功呼叫 CreateTask

Cloud Tasks 與 default App Engine 佇列

App Engine SDK 和 Cloud Tasks API 會對名為「default」的 App Engine 佇列提供特別處置。

如果 default 佇列尚未存在,則下列情形會建立這個佇列:

  1. 當初次使用 App Engine SDK 將工作新增到 default 佇列時。
  2. 當上傳有指定 default 佇列的 queue.yaml 檔案時。
  3. 當呼叫 CreateQueueUpdateQueue 來建立 default 佇列時。

為了保留與 App Engine 的相容性,Cloud Tasks 會強制執行下列限制:

  1. 如果建立了名為「default」的佇列,該佇列必須是使用 App Engine 工作的佇列。
  2. default 佇列建立後,使用者無法將其刪除。

Cloud Tasks API 中,default 佇列還適用下列限制:

  1. Cloud Tasks API 不會自動建立 default 佇列或任何其他佇列。
  2. 如同任何其他佇列,如果在建立 default 佇列之前就對佇列呼叫 GetQueue,將會產生找不到佇列的錯誤。
  3. 同樣地,在 default 佇列建立完成前,該佇列也不會出現在 ListQueues 的輸出中。
  4. default 佇列的設定可透過 UpdateQueue 呼叫加以變更。

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Tasks 說明文件