[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-21。"],[],[],null,["# Understand Cloud Tasks\n\nThis page describes what Cloud Tasks tasks and queues are, and when\nand how to use them. Cloud Tasks lets you separate out pieces of work\nthat can be performed independently, outside of your main application flow, and\nsend them off to be processed, asynchronously, using *handlers* that you create.\nThese independent pieces of work are called *tasks*. For example, you need to\nupdate a database as part of processing a user request, but updates can be\ntime-consuming. Offloading that detail as a task lets you return from the\nrequest more quickly.\n| **Key Point:** Cloud Tasks is designed for asynchronous work. While Cloud Tasks guarantees delivery of the task itself, it doesn't provide strong guarantees around the timing of task delivery and is therefore unsuitable for interactive applications where a user is waiting for the result.\n\nThe offloaded task is added to a *queue* , which persists the task until it is\nsuccessfully executed or the number of\n[retries](/tasks/docs/configuring-queues#retry) is exhausted, after which it is\ndeleted. Based on your initial configuration, the queue can also act as a\ndispatch flow control. You create and configure the queue which is then managed\nby the Cloud Tasks service. Once tasks are added, the queue\ndispatches them and makes sure they are reliably processed by your workers.\nComplexities associated with that process, such as user-facing latency costs,\nserver crashes, resource consumption limitations, and retry management, are\nhandled by the service.\n\nCloud Tasks is designed to provide \"at least once\" delivery;\nthat is, if a task is successfully added, the queue will deliver it at least\nonce. In some rare circumstances, multiple task execution is possible, so your\ncode must ensure that there are no harmful side-effects of repeated execution.\nYour handlers should be\n[idempotent](https://wikipedia.org/wiki/idempotent).\n\nThe tasks themselves are made up of a unique name and configuration information\nand, optionally, any data from the initial request, called the payload,\nnecessary to process the request. As the payload is sent in the request body,\ntasks that include payloads must use POST or PUT as their HTTP method.\n\nTo access the Cloud Tasks service using Cloud Tasks API , you must\nhave a Google Cloud [project](/resource-manager/docs/creating-managing-projects).\n\n### Features\n\nUsing Cloud Tasks, you can dispatch asynchronous work items with the\nfollowing controls:\n\n- Schedule specific delivery times\n- Manage delivery rates\n- Configure retry behavior\n- Access and manage individual tasks in a queue\n- Enable task deduplication\n\n### General workflow\n\nThe general workflow is as follows:\n\n1. You create a worker to process the tasks.\n2. You create a queue.\n3. You create tasks programmatically and add them to the queue.\n4. The Cloud Tasks service returns an OK to the originating application. This indicates that the task has been successfully written to Cloud Tasks storage, making the create task request both highly available and durable.\n5. The tasks are passed to the worker.\n6. The worker processes the task.\n7. To complete the sequence, the worker returns a 2xx success status code to the Cloud Tasks service.\n\nOnce the task has been handed off to the queue, no data is made available to the\ninitial request.\n| **Note:** The Cloud Tasks API provides an App Engine-independent interface to the App Engine Task Queue service. Queues that are accessible using the App Engine SDK are accessible through the Cloud Tasks API, and queues that are accessible through the Cloud Tasks API are accessible using the App Engine SDK.\n\n### Use cases\n\nTypical use cases include the following:\n\n- Speeding user response times by delegating potentially slow background operations like database updates to a worker\n- Preserving requests in the context of unexpected production incidents\n- Helping smooth traffic spikes by removing non-user-facing tasks from the main user flow\n- Managing third-party API call rates\n\nCloud Tasks queues with HTTP targets\n------------------------------------\n\nIn the case of generic HTTP Targets, the Cloud Tasks service forwards\nthe task request to the worker, located at any generic HTTP endpoint, based on\nhow the task is configured. This endpoint could be on\n[Cloud Run functions](/functions/docs), [Cloud Run](/run/docs),\n[GKE](/kubernetes-engine/docs),\n[Compute Engine](/compute/docs), or even an on-premises web server, based\non how the task is configured. These queues dispatch requests at a reliable,\nconfigurable rate. They ensure reliable task execution; upon success, all\nworkers must send an HTTP response code (200-299) to the Cloud Tasks\nservice before the default timeout deadline of 10 minutes, with a maximum of 30\nminutes. If a different response is sent, or no response, the task is retried.\n\nThe target must manage scaling workers and cleaning up tasks once they are complete.\n\nIf your target requires authentication, you must set up two\n[service accounts](/docs/authentication/getting-started#creating_a_service_account),\none for your application, the client, and one for the queue itself. Both accounts\nmust have been granted the requisite permissions, and an identifier for the\nclient service account must be included in the task request. See\n[Create HTTP Target tasks](/tasks/docs/creating-http-target-tasks#sa) for more\ninformation.\n\nCloud Tasks queues with App Engine targets\n------------------------------------------\n\nCloud Tasks is compatible with the following App Engine\nenvironments:\n\n- App Engine standard environment second-generation runtimes\n- App Engine flexible environment\n\nUsers of App Engine first-generation runtimes who use the\n[Task Queue API](/appengine/docs/standard/services/taskqueue) can migrate to\nCloud Tasks. To learn how, see\n[Migrate off legacy bundled services](/appengine/migration-center/standard/services/migrating-services).\nUsers of App Engine first-generation runtimes who don't use the\nbundled task service can upgrade to second-generation runtimes to use\nCloud Tasks.\n\nIn the case of App Engine targets, the Cloud Tasks service\nalso forwards the task request to the handler, but this worker is located within\nApp Engine. So all queues that target App Engine handlers must\nhave an [App Engine app](/appengine/docs/standard/python/console#create).\nThe handlers must run in the [region](/appengine/docs/locations) where the\nApp Engine app runs. This region also serves as the\n\u003cvar translate=\"no\"\u003eLOCATION_ID\u003c/var\u003e parameter for your Cloud Tasks requests.\n\nThe tasks are routed based on how the task (or, less commonly, the queue itself)\nis configured. The queues dispatch requests at a reliable, configurable rate.\nThey guarantee reliable task execution - upon success, all workers must send an\nHTTP response code (200-299) to the Cloud Tasks service, in this\ninstance before a deadline based on the [instance scaling](/appengine/docs/flexible/python/an-overview-of-app-engine)\ntype of the service: 10 minutes for automatic scaling or up to 24 hours for\nmanual scaling. If a different response is sent, or no response, the task is\nretried.\n\nBecause the handlers are part of App Engine, the Cloud Tasks\nservice itself can do much of the process management for the task, scaling\nworkers up and down in relation to traffic and deleting tasks when they are\ncompleted.\n| **Note:** Two App Engine locations, called `europe-west` and `us-central` in App Engine commands, are called, respectively, `europe-west1` and `us-central1` in Cloud Tasks commands.\n\nSupported regions by target\n---------------------------\n\nIf your target is an **HTTP/S endpoint** , Cloud Tasks is available\nin all [supported Google Cloud regions](/tasks/docs/locations) for\nCloud Tasks.\n\nIf your target is an **App Engine application** located within your\ncurrent project:\n\n- A task targeting App Engine can only be created in the project's\n App Engine [region](/appengine/docs/locations).\n\n- A Google Cloud project can contain only one App Engine app,\n and the region where the App Engine app is located cannot be changed\n once the app is created.\n\n- App Engine is *regional* which means the infrastructure that runs\n your app is located in a specific region. If you want to distribute compute and\n queues across multiple regions, you should target an HTTP/S endpoint instead.\n\n- If you are not using App Engine as a target, you don't need to\n deploy an App Engine app, and you can disable any existing\n App Engine app.\n\nTask deduplication\n------------------\n\nTask deduplication is achieved by assigning a unique name to a task. If you\nattempt to create a task with a name that already exists in the queue, the\ncreation request will fail. This prevents the same task from being added more\nthan once.\n\nCloud Tasks remembers task names for up to 24 hours after the\ntask has been deleted from the queue. Attempting to re-create a task with the\nsame name during this time will also result in a failed request.\n\nIf you don't provide a name when creating a task, Cloud Tasks will\ngenerate a unique name for it, and deduplication is unnecessary.\n\nKey terms\n---------\n\nThe following terms describe key Cloud Tasks capabilities.\n\nObservability\n-------------\n\nYou can monitor and analyze Cloud Tasks activity and growth by\nusing monitoring, logging, and diagnostic tools provided by Google Cloud Observability. For\nmore information see [Observability in Cloud Tasks](/tasks/docs/monitor)."]]
