提取佇列適合需要分批處理工作以提升效率的情形。有個解決方法是妥善利用為提取工作附加「標記」的功能，如此工作站就可租用一組具有相同標記的工作。常見的例子是維護多個不同遊戲排行榜並有許多玩家與團隊時常上線遊戲的應用程式。每次出現創新高分時，應用程式可將具有分數與玩家資訊的提取工作放入佇列，並且使用遊戲 ID 作為工作標記。工作站會定期「啟動」，租用一組具有相同遊戲 ID 的工作，然後更新排行榜。您可以使用指定標記值直接租用工作，或讓服務決定要傳送哪些具類似標記的一組工作。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[[["\u003cp\u003eTask queues enable applications to perform tasks asynchronously outside of a user request, with worker services executing these tasks later.\u003c/p\u003e\n"],["\u003cp\u003eThere are two types of task queues: push queues, which deliver HTTP requests to App Engine worker services, and pull queues, which require worker services to lease tasks.\u003c/p\u003e\n"],["\u003cp\u003ePush queues are ideal for handling "slow" operations and scheduled tasks, while pull queues are useful for batching tasks together for efficient execution.\u003c/p\u003e\n"],["\u003cp\u003eTasks in push queues have deadlines, and vary depending on the scaling service type, while tasks in pull queues allow for customized deadlines.\u003c/p\u003e\n"],["\u003cp\u003eAll task queue tasks are performed asynchronously, and if a worker fails, the Task Queue service offers a retry mechanism.\u003c/p\u003e\n"]]],[],null,["# Task Queue Overview\n\nThis page describes what task queues are, and when and how to use them.\nTask queues let applications perform work, called *tasks* ,\nasynchronously outside of a user request. If an app needs to execute work\nin the background, it adds tasks to *task queues*. The tasks are executed later,\nby worker services.\n\nThe Task Queue service is designed for asynchronous work. It does not\nprovide strong guarantees around the timing of task delivery and is therefore\nunsuitable for interactive applications where a user is waiting for the result.\n| This API is supported for first-generation runtimes and can be used when [upgrading to corresponding second-generation runtimes](/appengine/docs/standard/\n| go\n| /services/access). If you are updating to the App Engine Go 1.12+ runtime, refer to the [migration guide](/appengine/migration-center/standard/migrate-to-second-gen/go-differences) to learn about your migration options for legacy bundled services.\n\nPush queues and pull queues\n---------------------------\n\nTask queues come in two flavors, *push* and *pull*. The manner in which the\nTask Queue service dispatches task requests to worker services is different for\nthe different queues.\n\n**Push queues** run tasks by delivering HTTP requests to App Engine worker services.\nThey dispatch these requests at a reliable, steady rate and guarantee\nreliable task execution. Because you can control the rate at which tasks are\nsent from the queue, you can control the workers' scaling behavior and hence\nyour costs.\n\nBecause tasks are executed as requests targeted at App Engine\nservices, they are subject to stringent deadlines. Tasks handled by automatic\nscaling services must finish in ten minutes. Tasks handled by basic and manual\nscaling services can run for up to 24 hours.\n\n**Pull queues** do not dispatch tasks at all. They depend on other worker\nservices to \"lease\" tasks from the queue on their own initiative. Pull queues\ngive you more power and flexibility over when and where tasks are processed, but\nthey also require you to do more process management. When a task is leased the\nleasing worker declares a deadline. By the time the deadline arrives the worker\nmust either complete the task and delete it or the Task Queue service will\nallow another worker to lease it.\n\n| **Tip:** In some cases [Google Cloud Pub/Sub](/pubsub/overview) is a good alternative to pull queues.\n\nAll task queue tasks are performed **asynchronously**. The application that creates\nthe task hands it off to the queue. The originating application is not notified\nwhether or not the task completes, or if it was successful.\n\nIf a worker fails to process a task, the Task Queue service provides the queue\nwith a retry mechanism, so the task can be retried a finite number of times.\n\nUse cases\n---------\n\n### Push queues\n\nOne typical push queue use case is a \"slow\" operation. Consider a social\nnetwork messaging system. Every time a user sends a message, the network needs\nto update the followers of the sender. This can be a very time-consuming\noperation. Using a push queue, the application can enqueue a task for each\nmessage as it arrives to be dispatched to a worker service for processing. When\nthe worker receives the task request, it can retrieve the sender's list of\nfollowers and update the DB for each one. The worker can be made even more\nefficient by enqueuing another pushtask for each database update.\n\nAnother use for push queues is scheduled tasks. Imagine an application that\nimplements an ad campaign. A group of tasks written to send out emails can be\nadded to a push queue with instructions to withhold the tasks until a specified\ntime in the future. When the due date arrives, the Task Queue service will\nbegin to issue requests to execute the tasks.\n\n### Pull queues\n\nPull queues work well when you need to batch tasks together for efficient\nexecution. One solution takes advantage of the ability to attach a *tag* to a\npull task. Workers can lease a group of tasks that have the same tag. A typical\nexample might be an app that maintains leaderboards for numerous different games, with\nmany players and groups constantly in play. Every time there is a new high\nscore, the app can enqueue a pull task with the score and the player, and use\nthe game ID as a task tag. A worker periodically \"wakes up\", leases a group of\ntasks with the same game ID, and updates the leaderboard. You can lease tasks\nexplicitly, using a specified tag value, or let the service decide which group\nof similarly tagged tasks to send.\n\nBatching with tags can be very powerful. Since tags can be dynamically\ngenerated while your app is running, a worker can handle new game IDs with no\nspecial effort.\n\n\nWhat's next\n-----------\n\n- Read about [push queues](/appengine/docs/legacy/standard/go111/taskqueue/push)\n- Read about [pull queues](/appengine/docs/legacy/standard/go111/taskqueue/pull)"]]
