Auf dieser Seite wird beschrieben, wie Sie Push-Warteschlangencode von Aufgabenwarteschlangen zu Cloud Tasks migrieren können. Cloud Tasks ist jetzt die bevorzugte Methode für die Arbeit mit App Engine-Push-Warteschlangen.
Mit Cloud Tasks greifen Sie auf denselben Dienst zu wie mit der Task Queues RPC API. Das bedeutet, dass Sie Ihre bestehenden Push-Warteschlangen und Push-Aufgaben nicht neu erstellen müssen. Sie müssen jedoch Code migrieren, der Push-Warteschlangen oder Push-Aufgaben erstellt oder damit interagiert, um die Cloud Tasks API zu verwenden.
Sie können Push-Warteschlangen und Push-Aufgaben mit der Cloud Tasks REST API, der Cloud Tasks RPC API, der Cloud Tasks-Clientbibliothek, dem Google Cloud CLI und der Google Cloud Console erstellen und damit interagieren. Auf dieser Seite finden Sie Beispiele mit der gcloud CLI und der Cloud Tasks-Clientbibliothek.
In Cloud Tasks arbeiten alle Warteschlangen als Push-Warteschlangen. Im Rest dieses Anleitung und in der Cloud Tasks-Dokumentation entspricht der Begriff Warteschlange dem Begriff Push-Warteschlange. Ebenso entspricht der Begriff Aufgabe dem Begriff Push-Aufgabe.
In Cloud Tasks nicht verfügbare Funktionen
Die folgenden Features sind in Cloud Tasks nicht verfügbar:
- Warteschlange für Aufgaben in Datenspeichertransaktionen
- Bibliothek für zurückgestellte Aufgaben anstelle eines Worker-Dienstes verwenden
- Mit Aufgaben in Anwendungen mit mehreren Mandanten arbeiten
- Mit dem lokalen Entwicklungsserver simulieren
- Aufgaben asynchron hinzufügen
Preise und Kontingente
Die Migration von Push-Warteschlangen zu Cloud Tasks kann sich auf die Preise und Kontingente für Ihre Anwendung auswirken.
Preise
Für Cloud Tasks gelten eigene Preise. Wie bei Aufgabenwarteschlangen kann das Senden von Anfragen an Ihre App Engine-Anwendung mit einer Aufgabe dazu führen, dass die Anwendung Kosten verursacht.
Kontingente
Die Kontingente für Cloud Tasks unterscheiden sich von den Kontingenten für Aufgabenwarteschlangen. Wie bei Aufgabenwarteschlangen kann das Senden von Anfragen von Cloud Tasks an die App Engine-Anwendung Auswirkungen auf Ihre Anfragekontingente für App Engine haben.
Vor der Migration
Richten Sie die Python-Entwicklungsumgebung ein, falls Sie dies noch nicht getan haben, um eine mit Google Cloud kompatible Python-Version zu verwenden, und installieren Sie Testtools, um isoliertes Python zu erstellen. Umgebungen.In folgenden Abschnitten werden die Einrichtungsschritte erläutert, bevor Sie Ihre Push-Warteschlangen zu Cloud Tasks migrieren.
Pull-Warteschlangen migrieren
Migrieren Sie Pull-Warteschlangen, bevor Sie der Anleitung zum Migrieren von Push-Warteschlangen folgen. Die Migration von Pull-Warteschlangen nach der Migration von Push-Warteschlangen wird nicht empfohlen, da die erforderliche Verwendung der Datei queue.yaml
wahrscheinlich ein unerwartetes Verhalten bei Cloud Tasks verursacht.
Warteschlangenkonfiguration schützen
Wenn Sie mit der Migration zu Cloud Tasks beginnen, kann das Ändern der Datei queue.yaml
zu unerwartetem Verhalten führen und wird nicht empfohlen. So können Sie Ihre Warteschlangenkonfiguration vor Änderungen durch die Datei queue.yaml
schützen:
Konfigurieren Sie die gcloud CLI, um die
queue.yaml
-Datei in zukünftigen Bereitstellungen auszulassen.Fügen Sie die Datei
queue.yaml
zu einer Datei.gcloudignore
hinzu. Um zu prüfen, ob Sie bereits eine Datei.gcloudignore
haben, können Sie den folgenden Befehl in Ihrem Terminal aus dem Verzeichnis der obersten Ebene Ihrer Anwendung ausführen. Dieser Befehl gibt den Dateinamen aus, wenn die Datei vorhanden ist.ls -a | grep .gcloudignore
Weitere Informationen zu
.gcloudignore
-Dateien finden Sie in der.gcloudignore
-Referenz.Schränken Sie die Berechtigungen für die Datei
queue.yaml
ein.Wenden Sie die Best Practices an, die in der Anleitung zum Sichern der Warteschlangenkonfiguration beschrieben sind.
Weitere Informationen zu Cloud Tasks und der Datei
queue.yaml
(optional)Wenn Sie die Warteschlangenkonfiguration mit der Cloud Tasks API verwalten, überschreibt die Bereitstellung einer Datei
queue.yaml
die von Cloud Tasks festgelegte Konfiguration, was zu unerwartetem Verhalten führen kann. Lesen Sie Warteschlangenverwaltung im Vergleich zu queue.yaml, um weitere Informationen zu erhalten.
Cloud Tasks API aktivieren
Um die Cloud Tasks API zu aktivieren, klicken Sie bei der Cloud Tasks API in der API-Bibliothek auf Aktivieren. Wenn anstelle der Schaltfläche Aktivieren die Schaltfläche Verwalten angezeigt wird, haben Sie die Cloud Tasks API bereits für Ihr Projekt aktiviert und müssen dies nicht noch einmal tun.
Anwendung bei der Cloud Tasks API authentifizieren
Sie müssen Ihre Anwendung für die Cloud Tasks API authentifizieren. In diesem Abschnitt wird die Authentifizierung für zwei verschiedene Anwendungsfälle erläutert.
Wenn Sie Ihre Anwendung lokal entwickeln oder testen möchten, empfehlen wir die Verwendung eines Dienstkontos. Anleitungen zum Einrichten eines Dienstkontos und zum Verknüpfen des Dienstkontos mit Ihrer Anwendung finden Sie unter Dienstkonto-Anmeldedaten manuell abrufen und bereitstellen.
Zur Bereitstellung Ihrer Anwendung in App Engine müssen Sie keine neue Authentifizierung bereitstellen. Die Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) leiten die Authentifizierungsdetails für App Engine-Anwendungen ab.
gcloud CLI herunterladen
Laden Sie die gcloud CLI herunter und installieren Sie sie, um die gcloud CLI mit der Cloud Tasks API zu verwenden, falls Sie sie noch nicht installiert haben. Führen Sie folgenden Befehl über Ihr Terminal aus, wenn Sie die gcloud CLI bereits installiert haben.
gcloud components update
Cloud-Clientbibliotheken importieren
So verwenden Sie die Cloud Tasks-Clientbibliothek mit Ihrer App Engine-Anwendung:
Aktualisieren Sie die Datei
app.yaml
. Folgen Sie der Anleitung für Ihre Python-Version:Python 2
Fügen Sie für Python 2-Anwendungen die neuesten Versionen der Bibliotheken
grpcio
undsetuptools
hinzu.Hier sehen Sie eine
app.yaml
-Beispieldatei:runtime: python27 threadsafe: yes api_version: 1 libraries: - name: grpcio version: latest - name: setuptools version: latest
Python 3
Geben Sie für Python 3-Anwendungen das
runtime
-Element in Ihrerapp.yaml
-Datei mit einer unterstützten Python 3-Version an. Beispiele:runtime: python310 # or another support version
Die Python 3-Laufzeit installiert Bibliotheken automatisch. Sie müssen also keine integrierten Bibliotheken aus der vorherigen Python 2-Laufzeit angeben. Wenn Ihre Python 3-Anwendung bei der Migration andere gebündelte Legacy-Dienste verwendet, können Sie weiter die erforderlichen integrierten Bibliotheken angeben. Andernfalls können Sie die unnötigen Zeilen in der
app.yaml
-Datei löschen.Aktualisieren Sie die Datei
requirements.txt
. Folgen Sie der Anleitung für Ihre Python-Version:Python 2
Fügen Sie die Cloud-Clientbibliotheken für Cloud Tasks der Liste der Abhängigkeiten in der
requirements.txt
-Datei hinzu.google-cloud-tasks
Führen Sie dann
pip install -t lib -r requirements.txt
aus, um die Liste der verfügbaren Bibliotheken für Ihre Anwendung zu aktualisieren.Python 3
Fügen Sie die Cloud-Clientbibliotheken für Cloud Tasks der Liste der Abhängigkeiten in der
requirements.txt
-Datei hinzu.google-cloud-tasks
App Engine installiert diese Abhängigkeiten während der Anwendungsbereitstellung in der Python 3-Laufzeit automatisch. Löschen Sie daher den Ordner
lib
, falls vorhanden.Wenn Ihre Anwendung in Python 2-Anwendungen integrierte oder kopierte Bibliotheken verwendet, müssen Sie diese Pfade in der
appengine_config.py
-Datei angeben, die sich im selben Ordner wie dieapp.yaml
-Datei befindet:import pkg_resources from google.appengine.ext import vendor # Set PATH to your libraries folder. PATH = 'lib' # Add libraries installed in the PATH folder. vendor.add(PATH) # Add libraries to pkg_resources working set to find the distribution. pkg_resources.working_set.add_entry(PATH)
Die Datei
appengine_config.py
geht davon aus, dass sich der Ordnerlib
im aktuellen Arbeitsverzeichnis befindet. Das aktuelle Arbeitsverzeichnis kann jedoch, wie bei Einheitentests, abweichen. Sie können Fehler vermeiden und den vollständigen Pfad zum Ordnerlib
wie dargestellt explizit eingeben:import os path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')
Importieren Sie die Cloud Tasks-Clientbibliothek in alle Dateien, die Push-Warteschlangen aus der Task Queues API verwenden:
from google.cloud import tasks
Nach Abschluss der vollständigen Migration Ihres gesamten Codes, der Push-Warteschlangen erstellt oder mit Cloud Tasks interagiert, entfernen Sie die Anweisungen zum Importieren der Task Queues API, z. B.
from google.appengine.api import taskqueue
.
Warteschlangen erstellen und verwalten
In diesem Abschnitt wird beschrieben, wie Sie Warteschlangen mit der Cloud Tasks API erstellen und verwalten.
Mit Cloud Tasks erstellen Sie keine queue.yaml
-Datei und verwalten keine Warteschlangen. Stattdessen verwenden Sie die Cloud Tasks API. Die Verwendung einer Datei queue.yaml
und der Cloud Tasks API wird nicht empfohlen, kann jedoch je nach Anwendung ein unvermeidlicher Teil der Migration von Aufgabenwarteschlangen zu Cloud Tasks sein. Weitere Informationen zu Best Practices finden Sie unter Warteschlangenverwaltung im Vergleich zu queue.yaml verwenden.
Warteschlangen erstellen
Lesen Sie diesen Abschnitt, wenn Ihre Anwendung Warteschlangen programmatisch erstellt oder wenn Sie zusätzliche Warteschlangen über die Befehlszeile erstellen möchten.
In Cloud Tasks haben Warteschlangennamen das Format projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID
. Der Teil LOCATION_ID
des Warteschlangennamens entspricht einer Google Cloud -Region. Der Teil QUEUE_ID
des Warteschlangennamens entspricht dem Feld name
der Cloud Tasks-Warteschlange. Der Warteschlangenname wird bei der Erstellung der Warteschlange basierend auf Grundlage des angegebenen Projekt, der Region und QUEUE_ID
generiert.
Im Allgemeinen muss der Standort der Warteschlange mit der Region Ihrer Anwendung übereinstimmen. Die beiden Ausnahmen von dieser Regel gelten für Anwendungen mit der Region europe-west
und Anwendungen mit der Region us-central
. In Cloud Tasks werden diese Regionen europe-west1
bzw. us-central1
genannt.
Sie können während der Erstellung der Warteschlange eine optionale Warteschlangenkonfiguration angeben. Alternativ können Sie die Warteschlange aktualisieren, nachdem sie erstellt wurde.
Sie müssen vorhandene Warteschlangen nicht neu erstellen. Migrieren Sie stattdessen den Code, der mit Ihren vorhandenen Warteschlangen interagiert, indem Sie die relevanten Teile dieser Anleitung lesen.
Warteschlangennamen wiederverwenden
Sie müssen nach dem Löschen einer Warteschlange sieben Tage warten, um eine Warteschlange mit derselben Warteschlangen-ID im selben Projekt und am selben Ort (d. h. derselben Region) zu erstellen.
Im folgenden Beispiel werden zwei Warteschlangen mit Cloud Tasks erstellt. Die erste Warteschlange hat die Warteschlangen-ID queue-blue
und ist so konfiguriert, dass alle Aufgaben mit einer Rate von 5/s
an die Version v2
des Dienstes task-module
gesendet werden. Die zweite Warteschlange hat die Warteschlangen-ID queue-red
und sendet Aufgaben mit einer Rate von 1/s
. Beide werden im Projekt mit der Projekt-ID my-project-id
am Standort us-central1
erstellt.
Dies ist die Cloud Tasks-Entsprechung zum Erstellen von Warteschlangen in Aufgabenwarteschlangen.
gcloud
Die gcloud CLI leitet das Projekt und den Speicherort von der Konfiguration der gcloud CLI ab.
gcloud tasks queues create queue-blue \ --max-dispatches-per-second=5 \ --routing-override=service:task-module,version:v2
gcloud tasks queues create queue-red \ --max-dispatches-per-second=1
Clientbibliothek
Weitere Informationen finden Sie in der Cloud Tasks-Referenz Cloud Tasks-Warteschlange erstellen.
Verarbeitungsrate der Warteschlange festlegen
In der folgenden Tabelle sind die Felder aufgeführt, die sich bei Aufgabenwarteschlangen und Cloud Tasks unterscheiden.
Feld in Aufgabenwarteschlangen | Feld in Cloud Tasks | Beschreibung |
---|---|---|
rate |
max_dispatches_per_second |
Die maximale Rate, mit der Aufgaben aus der Warteschlange weitergeleitet werden |
max_concurrent_requests |
max_concurrent_dispatches |
Die maximale Anzahl gleichzeitiger Aufgaben, die aus der Warteschlange weitergeleitet werden können |
bucket_size |
max_burst_size |
Cloud Tasks berechnet ein get-only-Attribut
Bei App Engine-Warteschlangen, die mit einer Datei |
total_storage_limit |
In Cloud Tasks verworfen | Cloud Tasks unterstützt nicht das Festlegen eines benutzerdefinierten Speicherlimits |
Sie können die Verarbeitungsrate der Warteschlange beim Erstellen der Warteschlange festlegen oder sie anschließend aktualisieren. Im folgenden Beispiel wird Cloud Tasks verwendet, um die Verarbeitungsrate für eine Warteschlange mit dem Namen queue-blue
festzulegen, die bereits erstellt wurde. Wenn queue-blue
mit einer Datei queue.yaml
erstellt oder konfiguriert wurde, wird im folgenden Beispiel max_burst_size
entsprechend dem max_dispatches_per_second
-Wert von 20
zurückgesetzt. Dies ist die Cloud Tasks-Entsprechung zum Festlegen der Verarbeitungsrate für die Warteschlange in Aufgabenwarteschlangen.
gcloud
gcloud tasks queues update queue-blue \ --max-dispatches-per-second=20 \ --max-concurrent-dispatches=10
Clientbibliothek
Weitere Informationen finden Sie unter Ratenbegrenzungen definieren.
Warteschlangen deaktivieren und fortsetzen
Cloud Tasks verwendet den Begriff pause auf die gleiche Weise wie Aufgabenwarteschlangen den Begriff disable. Durch das Pausieren einer Warteschlange wird die Ausführung der Aufgaben in der Warteschlange angehalten, bis die Warteschlange fortgesetzt wird. Sie können jedoch weiterhin Aufgaben zu einer Warteschlange hinzufügen, die pausiert wurde. Cloud Tasks verwendet den Begriff resume auf dieselbe Weise wie Aufgabenwarteschlangen.
Im folgenden Beispiel wird eine Warteschlange mit der Warteschlangen-ID
queue1
pausiert. Dies ist die Cloud Tasks-Entsprechung zum Deaktivieren von Warteschlangen in Aufgabenwarteschlangen.
gcloud
gcloud tasks queues pause queue1
Clientbibliothek
Weitere Informationen finden Sie in der Cloud Tasks-Referenz Warteschlangen pausieren.
Warteschlangen löschen
Nachdem Sie eine Warteschlange gelöscht haben, müssen Sie sieben Tage warten, bevor Sie eine Warteschlange mit demselben Namen erstellen können. Sie könnten auch alle Aufgaben aus einer Warteschlange löschen und die Warteschlange neu konfigurieren, wenn Sie nicht sieben Tage warten können.
Im folgenden Beispiel wird die Warteschlange mit der Warteschlangen-ID
queue1
gelöscht. Dies ist die Cloud Tasks-Entsprechung zum Löschen von Warteschlangen in Aufgabenwarteschlangen.
gcloud
gcloud tasks queues delete queue1
Clientbibliothek
Weitere Informationen finden Sie in der Cloud Tasks-Referenz Warteschlangen löschen.
Aufgaben erstellen und verwalten
In diesem Abschnitt wird beschrieben, wie Sie Aufgaben mit der Cloud Tasks API erstellen und verwalten.
Aufgaben erstellen
In der folgenden Tabelle sind die Felder aufgeführt, die sich bei Aufgabenwarteschlangen und Cloud Tasks unterscheiden.
Feld in Aufgabenwarteschlangen | Feld in Cloud Tasks | Beschreibung |
---|---|---|
NEU in Cloud Tasks | app_engine_http_request |
Erstellt eine Anfrage, die auf einen App Engine-Dienst abzielt. Diese Aufgaben werden als App Engine-Aufgaben bezeichnet. |
method |
http_method |
Gibt die Anfragemethode an, z. B. POST . |
url |
relative_uri |
Gibt den Aufgaben-Handler an. Beachten Sie den Unterschied im letzten Buchstaben: i für uniform resource identifier statt l für uniform resource locator |
target |
app_engine_routing |
Optional. Gibt die App Engine service , version und instance für eine App Engine-Aufgabe an. Wenn nicht festgelegt, werden der Standarddienst, die Standardversion und die Standardinstanz verwendet. |
Im folgenden Beispiel wird eine Aufgabe erstellt, die mit dem Handler /update_counter
an einen App Engine-Dienst namens worker
weitergeleitet wird. Dies ist die Cloud Tasks-Entsprechung zum Erstellen von Aufgaben in Aufgabenwarteschlangen.
gcloud
gcloud tasks create-app-engine-task --queue=default \ --method=POST --relative-uri=/update_counter --routing=service:worker \ --body-content=10
Clientbibliothek
Weitere Informationen finden Sie in der Cloud Tasks-Referenz App Engine-Aufgaben erstellen.
Zieldienst und Routing angeben
Die Angabe des App Engine-Zieldienstes, der Version und der Instanz für App Engine-Aufgaben ist optional. App Engine-Aufgaben werden standardmäßig an den Dienst, die Version und die Instanz weitergeleitet, die beim Ausführen der Aufgabe die Standardeinstellung sind.
Legen Sie das Attribut app_engine_routing
der Aufgabe während der Aufgabenerstellung fest, um einen anderen App Engine-Dienst, eine andere Version oder eine andere App Engine-Instanz für Ihre Aufgabe anzugeben.
Um alle Aufgaben in einer bestimmten Warteschlange an denselben App Engine-Dienst, dieselbe Version und dieselbe Instanz weiterzuleiten, können Sie das Attribut app_engine_routing_override
in der Warteschlange festlegen.
Weitere Informationen finden Sie in der Cloud Tasks-Referenz Routing konfigurieren.
Daten an den Handler übergeben
Wie bei Aufgabenwarteschlangen können Sie mit Cloud Tasks Daten auf zwei Arten an den Handler übergeben. Sie können Daten entweder als Abfrageparameter im relativen URI oder im Anfragetext mit den HTTP-Methoden POST oder PUT übergeben.
Cloud Tasks verwendet den Begriff Text auf die gleiche Weise wie Aufgabenwarteschlangen Nutzlast. In Cloud Tasks ist der Standardtextinhaltstyp „octet-stream” statt „Nur Text”. Sie können den Inhaltstyp „Text“ im Header angeben, um ihn festzulegen.
Im folgenden Beispiel wird ein Schlüssel auf zwei verschiedene Arten an den Handler
/update_counter
übergeben. Dies ist die Cloud Tasks-Entsprechung zur Übergabe von Daten an den Handler in Aufgabenwarteschlangen.
Konsole
gcloud tasks create-app-engine-task --queue=default --method=GET \ --relative-uri= /update_counter ?key=blue --routing=service:worker
gcloud tasks create-app-engine-task --queue=default --method=POST \ --relative-uri= /update_counter --routing=service:worker \ --body-content="{'key': 'blue'}"
Clientbibliothek
Aufgaben benennen
Die Angabe des Aufgabennamens ist optional. Wenn Sie den Aufgabennamen nicht angeben, wird er von Cloud Tasks durch Generieren einer Aufgaben-ID und Ableiten des Projekts und des Standorts (d. h. Region) basierend auf der Warteschlange erstellt, die Sie bei der Aufgabenerstellung angegeben haben.
Aufgabennamen haben das Format projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID/tasks/TASK_ID
. Der Teil TASK_ID
des Aufgabennamens entspricht dem Feld name
der Aufgabenwarteschlange.
Aufgabennamen wiederverwenden
Sie müssen warten, bevor Sie den Namen einer Aufgabe wiederverwenden können. Wie lange Sie warten müssen, hängt davon ab, ob die Warteschlange, die die Aufgabe weiterleitet, in Cloud Tasks oder in Aufgabenwarteschlangen erstellt wurde.
Bei Aufgaben in Warteschlangen, die mithilfe von Aufgabenwarteschlangen erstellt wurden (einschließlich der Standardwarteschlange), müssen Sie etwa 9 Tage warten, nachdem die ursprüngliche Aufgabe gelöscht oder ausgeführt wurde. Bei Aufgaben in Warteschlangen, die mit Cloud Tasks erstellt wurden, müssen Sie etwa eine Stunde warten, nachdem die ursprüngliche Aufgabe gelöscht oder ausgeführt wurde.
Im folgenden Beispiel wird eine Aufgabe mit dem Wert TASK_ID
auf first-try
erstellt und der Standardwarteschlange hinzugefügt. Dies ist das die Cloud Tasks-Entsprechung zum Benennen von Aufgaben in Aufgabenwarteschlangen.
gcloud
Die gcloud CLI erstellt den Aufgabennamen, wozu sie Projekt und Standort aus der Konfiguration ableitet.
gcloud tasks create-app-engine-task first-try --queue=default \ --method=GET --relative-uri= /url/path
Clientbibliothek
Bei der Clientbibliothek müssen Sie den vollständigen Aufgabennamen für TASK_ID
angeben. Das Projekt und der Speicherort müssen mit dem Projekt und dem Speicherort der Warteschlange übereinstimmen, der die Aufgabe hinzugefügt wird.
Fehlgeschlagene Aufgaben wiederholen
Sie können die Konfiguration der Aufgabenwiederholung für Warteschlangen während der Erstellung der Warteschlange oder durch Aktualisieren der Warteschlange festlegen. In der folgenden Tabelle sind das Feld „Aufgabenwarteschlangen“ und das entsprechende Cloud Tasks-Feld aufgeführt.
Feld in Aufgabenwarteschlangen | Feld in Cloud Tasks |
---|---|
task_retry_limit |
max_attempts |
task_age_limit |
max_retry_duration |
min_backoff_seconds |
min_backoff |
max_backoff_seconds |
max_backoff |
max_doublings |
max_doublings |
Aufgabenspezifische Wiederholungsparameter
Aufgabenspezifische Wiederholungsparameter, die in Aufgabenwarteschlangen konfiguriert wurden, funktionieren in Cloud Tasks. Sie können sie jedoch nicht bearbeiten oder für neue Aufgaben festlegen. Um die Wiederholungsparameter für eine Aufgabe mit aufgabenspezifischen Wiederholungsparametern zu ändern, erstellen Sie die Aufgabe mit einer Cloud Tasks-Warteschlange mit den gewünschten Wiederholungsparametern neu.
Im folgenden Beispiel werden verschiedene Wiederholungsszenarien demonstriert:
- In
fooqueue
werden Aufgaben bis zu siebenmal und bis zu zwei Tage nach dem ersten Ausführungsversuch wiederholt. Nachdem beide Limits überschritten wurden, gilt die Ausführung als endgültig gescheitert. - In
barqueue
versucht App Engine, die Ausführung von Aufgaben zu wiederholen, wobei das Intervall zwischen den einzelnen Versuchen linear erhöht wird, bis das maximale Backoff erreicht ist. Die Versuche werden dann unbegrenzt im maximalen Intervall fortgesetzt. Die Intervalle zwischen den Anfragen betragen somit 10 s, 20 s, 30 s, ..., 190 s, 200 s, 200 s usw. - In
bazqueue
beginnt das Wiederholungsintervall bei 10 s, verdoppelt sich dreimal und steigt dann linear bis zum maximalen Intervall an, mit dem auf unbestimmte Zeit wiederholt wird. Die Intervalle zwischen den Anfragen betragen somit 10 s, 20 s, 40 s, 80 s, 160 s, 240 s, 300 s, 300 s usw.
Dies ist die Cloud Tasks-Entsprechung zum Wiederholen von Aufgaben in Aufgabenwarteschlangen.
gcloud
Wenn Sie Optionen festlegen, die eine Anzahl von Sekunden angeben, müssen Sie s
nach der Ganzzahl einfügen (z. B. 200s
, nicht 200
).
gcloud tasks queues create fooqueue \ --max-attempts=7 \ --max-retry-duration=172800s #2*60*60*24 seconds in 2 days
gcloud tasks queues create barqueue \ --min-backoff=10s \ --max-backoff=200s \ --max-doublings=0
gcloud tasks queues create bazqueue \ --min-backoff=10s \ --max-backoff=300s \ --max-doublings=3
Clientbibliothek
Weitere Informationen finden Sie in der Cloud Tasks-Referenz Wiederholungsparameter festlegen.
Aufgaben aus einer Warteschlange löschen
Nachdem Sie eine Aufgabe gelöscht haben, müssen Sie 9 Tage warten, bevor Sie eine Aufgabe mit demselben Namen erstellen, wenn sich die Aufgabe in einer Warteschlange befand, die mit einer Datei queue.yaml
erstellt wurde. Wenn sich die Aufgabe in einer Warteschlange befand, die mit Cloud Tasks erstellt wurde, müssen Sie 1 Stunde warten.
Im folgenden Beispiel wird die Aufgabe mit der Aufgaben-ID foo
aus der Warteschlange mit der Warteschlangen-ID queue1
gelöscht. Dies ist die Cloud Tasks-Entsprechung zum Löschen von Aufgaben in Aufgabenwarteschlangen.
gcloud
Aufgabenprojekt und Standort werden aus dem Standardprojekt der gcloud CLI abgeleitet.
gcloud tasks delete foo --queue=queue1
Clientbibliothek
Weitere Informationen finden Sie in der Cloud Tasks-Referenz Aufgabe aus einer Warteschlange löschen.
Aufgaben dauerhaft löschen
Im folgenden Beispiel werden alle Aufgaben aus der Warteschlange mit der Warteschlangen-ID
queue1
dauerhaft gelöscht. Dies ist die Cloud Tasks-Entsprechung für das dauerhafte Löschen von Aufgaben in Aufgabenwarteschlangen.
gcloud
Das Warteschlangenprojekt und der Standort werden aus dem Standardprojekt der gcloud CLI abgeleitet.
gcloud tasks queues purge queue1
Clientbibliothek
Weitere Informationen finden Sie in der Cloud Tasks-Referenz Alle Aufgaben aus einer Warteschlange dauerhaft löschen.
Nächste Schritte
- Dokumentation zu Cloud Tasks
- Cloud Tasks-Clientbibliothek
- Cloud Tasks-REST-Referenz – Übersicht
- Cloud Tasks-RPC-Referenz – Übersicht
- Eine Anleitung finden Sie im Codelab zur Migration von App Engine-Aufgaben-Push-Warteschlangen zu Cloud Tasks.