In der Google Ads API wird die Ratenbegrenzung nach Abfragen pro Sekunde (QPS) sowohl für Kundennummern als auch für Google Cloud-Projekte unabhängig voneinander erzwungen. Zusätzlich zu den Anfragen pro Minute (die die Häufigkeit von API-Aufrufen messen) werden bei der Google Ads API auch Limits für Vorgänge pro Minute erzwungen (die die Gesamtzahl der API-Vorgänge über alle Anfragen hinweg messen). In der Google Ads API wird ein Token-Bucket-Algorithmus verwendet, um Anfragen zu messen und ein geeignetes Limit für Abfragen pro Sekunde festzulegen. Das genaue Limit variiert also je nach der aktuellen Serverlast.
Mit der Ratenbegrenzung soll verhindert werden, dass ein Nutzer den Dienst für andere Nutzer stört, indem er (absichtlich oder unabsichtlich) die Google Ads API-Server mit einer großen Anzahl von Anfragen überlastet.
Anfragen, die gegen die Ratenbegrenzung verstoßen, werden mit dem Fehler RESOURCE_TEMPORARILY_EXHAUSTED abgelehnt.
Sie können die Kontrolle über Ihre Anwendung übernehmen und Ratenbegrenzungen reduzieren, indem Sie sowohl die Anzahl der Anfragen aktiv reduzieren als auch die Abfragen pro Sekunde auf Clientseite drosseln.
Es gibt verschiedene Möglichkeiten, die Wahrscheinlichkeit zu verringern, dass das Ratenlimit überschritten wird. Wenn Sie sich mit den Konzepten von Enterprise Integration Patterns (EIP) wie Messaging, erneute Zustellung und Drosselung vertraut machen, können Sie eine robustere Client-Anwendung erstellen.
Die folgenden empfohlenen Vorgehensweisen sind nach Komplexität sortiert, wobei einfachere Strategien oben und robustere, aber komplexere Architekturen weiter unten aufgeführt sind:
- Exponentieller Backoff
- Gleichzeitige Aufgaben beschränken
- Batchanfragen
- Drosselung und Ratenbegrenzer
- Wiedergabeliste
Exponentielle Backoffs
Wenn Ihre Anwendung einen RESOURCE_TEMPORARILY_EXHAUSTED-Fehler empfängt, verwenden Sie eine exponentielle Backoff-Richtlinie mit zufälligem Jitter, bevor Sie die fehlgeschlagene Anfrage wiederholen. Beim exponentiellen Backoff wird die Wartezeit zwischen den Wiederholungsversuchen schrittweise erhöht (z. B. 2 Sekunden, dann 4 Sekunden, dann 8 Sekunden, plus eine kleine zufällige Verzögerung). Dadurch können sich die Serverlast und die Kontingent-Buckets erholen, während gleichzeitig synchronisierte Wiederholungsspitzen über Clientinstanzen hinweg verhindert werden.
Gleichzeitige Aufgaben beschränken
Eine der Hauptursachen für das Überschreiten von Ratenbegrenzungen ist, dass die Client-Anwendung eine übermäßige Anzahl paralleler Aufgaben generiert. Wir begrenzen zwar nicht die Anzahl der parallelen Anfragen, die eine Client-App haben kann, aber dies kann das Limit für Anfragen pro Sekunde auf Google Cloud-Projektebene überschreiten.
Es wird empfohlen, eine angemessene Obergrenze für die Gesamtzahl der gleichzeitigen Aufgaben festzulegen, die Anfragen stellen (über alle Prozesse und Maschinen hinweg), und diese nach oben anzupassen, um den Durchsatz zu optimieren, ohne die Ratenbegrenzung zu überschreiten.
Außerdem können Sie die Abfragen pro Sekunde clientseitig drosseln (siehe Drosselung und Ratenbegrenzung).
Batchanfragen
Erwägen Sie, mehrere Vorgänge in einer einzigen Anfrage zusammenzufassen. Dies gilt vor allem für Mutate-Aufrufe für verschiedene Dienste. Wenn Sie beispielsweise den Status für mehrere Instanzen von AdGroupAd aktualisieren, können Sie MutateAdGroupAds einmal aufrufen und mehrere operations übergeben, anstatt MutateAdGroupAds einmal für jede AdGroupAd aufzurufen. Weitere Beispiele finden Sie in unserem Leitfaden für Batchvorgänge.
Durch das Zusammenfassen von Anfragen wird die Gesamtzahl der API-Aufrufe reduziert und die Ratenbegrenzung für Anfragen pro Minute wird umgangen. Wenn Sie jedoch eine große Anzahl von Vorgängen für ein einzelnes Konto ausführen, kann dies die Ratenbegrenzung für Vorgänge pro Minute auslösen.
Drosselung und Ratenbegrenzung
Zusätzlich zur Begrenzung der Gesamtzahl der Threads in Ihrer Anwendung können Sie auch clientseitige Ratenbegrenzungen implementieren. So wird sichergestellt, dass alle Threads in Ihren Prozessen, Clustern oder beidem von einem bestimmten QPS-Limit auf der Clientseite gesteuert werden.
Sehen Sie sich den Guava RateLimiter an oder implementieren Sie Ihren eigenen Token-Bucket-Algorithmus für eine Clusterumgebung. Sie können Tokens beispielsweise in einem verteilten In-Memory-Datenspeicher mit niedriger Latenz wie Redis oder Memcached verwalten, in dem jeder Client ein Token abruft und verbraucht, bevor er eine Anfrage verarbeitet. Wenn die Tokens aufgebraucht sind, wartet der Client, bis der nächste Batch von Tokens aufgefüllt ist.
Wiedergabeliste
Eine Nachrichtenwarteschlange ist die Lösung für die Verteilung der Betriebslast und steuert gleichzeitig die Anfrage- und Verbraucherraten. Es gibt eine Reihe von Optionen für Nachrichtenwarteschlangen – einige Open Source, andere proprietär – und viele davon können mit verschiedenen Sprachen verwendet werden.
Wenn Sie Nachrichtenwarteschlangen verwenden, können mehrere Ersteller Nachrichten an die Warteschlange senden und mehrere Nutzer diese Nachrichten verarbeiten. Drosselungen können auf der Nutzerseite implementiert werden, indem die Anzahl der gleichzeitigen Nutzer begrenzt wird oder indem Ratenbegrenzungen oder Drosselungen für die Ersteller oder Nutzer implementiert werden.
Wenn ein Nachrichten-Consumer beispielsweise einen Fehler aufgrund einer Ratenbegrenzung erhält, kann er die Anfrage mit einer standardisierten Wiederholungsverzögerung (mit exponentiellem Backoff) an die Warteschlange zurückgeben und eine freigegebene Feedbackschleife für die Ratenbegrenzung aktualisieren, sodass alle Consumer ihre Verarbeitungsrate automatisch reduzieren, während sie sich vom Fehler erholen.