工作佇列函式利用 Google Cloud Tasks敬上 幫助您的應用程式執行耗時、會耗用大量資源或頻寬受限 也可以在主要應用程式流程之外,以非同步方式處理工作
舉例來說,假設您想為一組大型的映像檔建立備份 檔案。為了成為 負責該 API 的使用者,您必須遵守其頻率限制。此外, 這類長時間執行的工作可能會因逾時和 記憶體用量限制
如要降低這種複雜性,您可以撰寫設定基本工作的工作佇列函式
工作選項 (例如 scheduleTime
和 dispatchDeadline
),然後操控
函式退出 Cloud Tasks 中的佇列。Cloud Tasks
環境經過特別設計,可確保有效的壅塞控管機制,以及
針對這些作業重試政策。
Cloud Functions for Firebase v3.20.1 以上版本的 Firebase SDK 並使用 Firebase Admin SDK v10.2.0 以上版本支援工作佇列函式。
使用 Firebase 的工作佇列函式可能會產生下列費用: 正在處理Cloud Tasks,詳情請見 Cloud Tasks 定價 瞭解詳情
建立工作佇列函式
如要使用工作佇列函式,請按照以下工作流程操作:
- 使用 Cloud Functions 適用的 Firebase SDK 編寫工作佇列函式。
- 透過 HTTP 要求觸發函式來測試函式。
- 使用 Firebase CLI 部署函式。部署工作時 佇列函式。CLI 將會建立 「Cloud Tasks」中的工作佇列 使用原始碼中指定的選項 (頻率限制與重試)。
- 將工作新增至新建的工作佇列,並傳送參數進行設定 執行排程這時只要編寫程式碼 方法是使用 Admin SDK,並將其部署至 Cloud Functions for Firebase。
寫入工作佇列函式
使用 onDispatch
開始編寫工作佇列函式。重要
編寫工作佇列函式的一部分,是設定每個佇列的重試和頻率。
限制設定本頁的程式碼範例是以
備份服務,將 NASA 的
天文今日相片:
設定工作佇列函式
工作佇列函式提供一組強大的組態設定 精確控制工作佇列的頻率限制與重試行為:
exports.backupApod = functions
.runWith( {secrets: ["NASA_API_KEY"]})
.tasks.taskQueue({
retryConfig: {
maxAttempts: 5,
minBackoffSeconds: 60,
},
rateLimits: {
maxConcurrentDispatches: 6,
},
}).onDispatch(async (data) => {
retryConfig.maxAttempts=5
:工作佇列中的每項工作會自動執行 最多重試 5 次。這有助於減少網路等暫時性錯誤 錯誤,或對相依外部服務的暫時性服務中斷。retryConfig.minBackoffSeconds=60
:每項工作至少重試 60 秒 並不會每次嘗試產生這會在每次嘗試之間提供較大的緩衝區 這樣我們就不會急速用完 5 次重試次數。rateLimits.maxConcurrentDispatch=6
:最多將 6 項工作分派給 時間。這有助於確保向基礎 功能,並協助減少有效執行個體和冷啟動的數量。
測試工作佇列函式
在大多數情況下,Cloud Functions 模擬器是測試工作的最佳方式 佇列函式。請參閱模擬器套件說明文件,瞭解如何 檢測您的應用程式以進行工作佇列函式模擬。
此外,工作佇列函式呈現為 Firebase Local Emulator Suite 中的 HTTP 函式。如要測試模擬工作函式,請傳送 HTTP POST 可能包含 JSON 資料酬載的要求:
# start the Firebase Emulators
firebase emulators:start
# trigger the emulated task queue function
curl \
-X POST # An HTTP POST request...
-H "content-type: application/json" \ # ... with a JSON body
http://localhost:$PORT/$PROJECT_ID/$REGION/$NAME \ # ... to function url
-d '{"data": { ... some data .... }}' # ... with JSON encoded data
部署工作佇列函式
使用 Firebase CLI 部署工作佇列函式:
$ firebase deploy --only functions:backupApod
首次部署工作佇列函式時,CLI 會建立 Cloud Tasks 中的工作佇列,含選項 (頻率限制和重試) 您在原始碼中指定的版本
如果您在部署函式時遇到權限錯誤,請確認 適當的身分與存取權管理角色 會指派給執行 Deployment 指令的使用者
將工作佇列函式排入佇列
工作佇列函式可透過信任在 Cloud Tasks 中排入佇列 Cloud Functions for Firebase使用 Firebase Admin SDK Node.js。如果您是第一次使用 Admin SDK,請參閱 首先,請將 Firebase 新增至伺服器。
在一般流程中,Admin SDK 會建立新的工作,並排入佇列 Cloud Tasks,並指定工作設定:
exports.enqueueBackupTasks = functions.https.onRequest(
async (_request, response) => {
const queue = getFunctions().taskQueue("backupApod");
const enqueues = [];
for (let i = 0; i <= 10; i += 1) {
// Enqueue each task with i*60 seconds delay. Our task queue function
// should process ~1 task/min.
const scheduleDelaySeconds = i * 60
enqueues.push(
queue.enqueue(
{ id: `task-${i}` },
{
scheduleDelaySeconds,
dispatchDeadlineSeconds: 60 * 5 // 5 minutes
},
),
);
}
await Promise.all(enqueues);
response.sendStatus(200);
});
scheduleDelaySeconds
:程式碼範例嘗試讓 為第 N 項工作把第 N 分鐘的延遲時間建立關聯這個 則會觸發大約每分鐘 1 項任務請注意,您也可以使用 如果想觸發 Cloud Tasks,請設為scheduleTime
在特定時間執行一項工作dispatchDeadlineSeconds
:時間長度上限 Cloud Tasks 會等待 待工作完成Cloud Tasks 將重試 才會執行 佇列設定,或是直到這個期限為止。在本範例中 佇列已設為重試工作最多 5 次,但工作 如果整個程序 (包括重試) 會自動取消 需要超過 5 分鐘
疑難排解
Cloud Tasks">開啟「Cloud Tasks」記錄功能
Cloud Tasks 的記錄包含實用的診斷資訊,例如 工作相關要求的狀態。根據預設 「Cloud Tasks」有大量記錄,因此已關閉 可能會在專案中產生錯誤建議您啟用偵錯記錄檔 而您在積極開發工作佇列函式並進行偵錯時。詳情請見 啟用中 記錄。
身分與存取權管理權限
將工作加入佇列時,或PERMISSION DENIED
Cloud Tasks 嘗試叫用您的工作佇列函式。請確認
專案具有下列 IAM 繫結:
這個身分用於將工作排入 Cloud Tasks 需求的佇列
cloudtasks.tasks.create
IAM 權限。在範例中,這是 App Engine 預設服務帳戶。
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member=serviceAccount:${PROJECT_ID}@appspot.gserviceaccount.com \
--role=roles/cloudtasks.enqueuer
您必須具備權限,才能將工作排入「Cloud Tasks」佇列。 才能使用與「Cloud Tasks」工作相關聯的服務帳戶。
在範例中,這是 App Engine 預設服務帳戶。
請參閱 Google Cloud IAM 說明文件 瞭解如何新增 App Engine 預設服務帳戶 做為 App Engine 預設服務帳戶的使用者。
用來觸發工作佇列函式所需的身分
cloudfunctions.functions.invoke
權限。在範例中,這是 App Engine 預設服務帳戶。
gcloud functions add-iam-policy-binding $FUNCTION_NAME \
--region=us-central1 \
--member=serviceAccount:${PROJECT_ID}@appspot.gserviceaccount.com \
--role=roles/cloudfunctions.invoker