Die gemeinsame Nutzung von Anmeldedaten für Ihre API-Anfragen verbessert die Leistung und vermeidet übermäßigen Aufwand, der zu Ratenbegrenzungsfehlern führen kann. In diesem Leitfaden wird erläutert, wie Sie die Verwaltung von OAuth2-Anmeldedaten optimieren, damit Ihre Anwendung effizient mit der Google Ads API interagieren kann.
Ihre Strategie für die Freigabe von Anmeldedaten hängt davon ab, ob Ihre Anwendung Multi-Threaded oder Multiprozess (oder verteilt) ist. Eine Anwendung, die in jedem Prozess sowohl Multiprozess- als auch Multithreading-Anwendungen ist, sollte beide Strategien einsetzen. Diese Strategien lassen sich auch für mehrere Google Ads-Konten anwenden.
Multithread
Jede Sitzung oder jeder Nutzer, die bzw. der von einem Thread gezeichnet wird, sollte dasselbe Anmeldedatenobjekt verwenden. Aktualisierungen von Zugriffstokens müssen ebenfalls synchron ausgeführt werden, um Race-Bedingungen zu vermeiden.
Unsere Clientbibliotheken stellen sicher, dass die Anmeldedaten ein threadsicheres Objekt sind, das sich selbst synchron aktualisiert, wenn sein Zugriffstoken abläuft. Jede unserer Clientbibliotheken hat ein Sitzungs- oder Nutzerobjekt mit Anmeldedaten, die während ihrer gesamten Lebensdauer wiederverwendet werden. Wenn Sie die Anmeldedaten für mehrere Threads freigeben möchten, erstellen Sie einfach jede Sitzung mit denselben Anmeldedaten. In der Java-Clientbibliothek würden Sie beispielsweise ein Credential-Singleton erstellen und für alle Sitzungen freigeben.
Multiprozess oder verteilt
Bei Multiprozess- oder verteilten Prozessen müssen Sie die Anmeldedaten speichern, bevor Sie sie freigeben können. Damit nicht mehrere Prozesse oder Server gleichzeitig versuchen, die Anmeldedaten zu aktualisieren, was zu übermäßig vielen Aktualisierungsanfragen führt, sollten Sie die Aktualisierung einem einzelnen Prozess zuweisen.
Ein separater Job oder Dienst kann beispielsweise dafür verantwortlich sein, die Anmeldedaten regelmäßig zu aktualisieren und sie proaktiv an einen Datenspeicher zu senden, der von einem Pool von Servern gemeinsam genutzt wird. Jeder Server kann dann die Anmeldedaten aus dem Datenspeicher abrufen, wenn er eine API-Anfrage stellt.
Aktualisierungsauftrag
Der Aktualisierungsjob sollte nicht warten, bis die aktuellen Anmeldedaten abgelaufen sind, bevor eine Aktualisierung gestartet wird. Dies kann dazu führen, dass die Anwendung aufgrund fehlender gültiger Anmeldedaten verzögert wird. Wenn das Zugriffstoken der Anmeldedaten abläuft, während die API-Anfrage verarbeitet wird, wird die Anfrage trotzdem abgeschlossen und die Ergebnisse werden zurückgegeben.
Wir empfehlen, den Zeitpunkt zu verfolgen, zu dem Ihr Zugriffstoken zuletzt aktualisiert wurde, und eine Aktualisierung zu erzwingen, wenn bis zum Ablauf weniger als 5 Minuten vergangen sind.
Wenn Sie nicht wissen, wann ein Zugriffstoken zuletzt aktualisiert wurde, können Sie versuchen, es zu aktualisieren, falls es bereits abgelaufen ist. Wenn das Zugriffstoken nicht kurz vor seiner Gültigkeit abgelaufen ist, gibt der Server dasselbe Zugriffstoken zusammen mit den verbleibenden Millisekunden zurück, bis das Token abläuft.
Datenspeicher
Sie können einen vorhandenen Datenspeicher nutzen oder einen Datenspeicher bereitstellen, der nur für das Teilen von Anmeldedaten zwischen Servern zuständig ist. Zu den Lösungen gehören Caching-Server wie Memcached oder Infinispan oder NoSQL-Datenspeicher wie MongoDB.
Der Datenspeicher sollte für schnelle Lesevorgänge optimiert sein, da es wesentlich mehr Leseanfragen als Schreibvorgänge gibt. Außerdem müssen Anmeldedaten sicher aufbewahrt werden.
Beim Speichern der Anmeldedaten sollten Sie den berechneten expiry_time (jetzt + expires_in) und den refresh_token zusammen mit access_token speichern. expiry_time wird als Zeitpunkt der access_token-Aktualisierungsanfrage plus expires_in-Zeit berechnet.
Serverpool
Jeder Server oder Prozess im Pool ruft die neuesten Anmeldedaten aus dem Datenspeicher ab, bevor er eine Anfrage stellt. Solange der Aktualisierungsjob ordnungsgemäß ausgeführt wird, sind die Anmeldedaten gültig. Wenn jedoch der Aktualisierungsjob oder der Datenspeicher fehlschlägt, sollten Sie einen Fallback-Mechanismus verwenden.
Wenn ein Server oder Prozess keine Anmeldedaten aus dem Datenspeicher abrufen kann oder die Anmeldedaten abgelaufen sind, sollte der Server seine eigenen Anmeldedaten aktualisieren, damit die Anwendung weiterhin mit der API arbeiten kann, bis das Problem behoben ist.
Verwaltung von Anmeldedaten für mehrere Konten
Anmeldedaten, die für ein Google Ads-Verwaltungskonto generiert wurden, können für den Zugriff auf alle untergeordneten Konten verwendet werden. Nutzer mit der Hierarchie eines einzelnen Verwaltungskontos müssen daher in der Regel Anmeldedaten für das Verwaltungskonto der obersten Ebene generieren, die für alle untergeordneten Google Ads-Konten verwendet werden.
Wenn Ihre Anwendung auf Google Ads-Konten zugreifen muss, die in keiner Verwaltungskontohierarchie miteinander in Beziehung stehen, sollten Sie unterschiedliche Anmeldedaten für verschiedene Konten generieren und verwalten, z. B. für jedes Google Ads-Kundenkonto oder jedes Verwaltungskonto der obersten Ebene in den unabhängigen Hierarchien, auf die Sie zugreifen.
Sie können die gleichen Strategien mit geringfügigen Änderungen für Multi-Threaded oder Multiprozess-/verteilte Anwendungen anwenden. Bei Verwendung eines freigegebenen Datenspeichers müssen Anmeldedaten mit der Konto-ID customerId indexiert werden, damit die Anmeldedaten mit dem richtigen Konto verknüpft sind.
Außerdem sollten beim Aktualisierungsjob alle Anmeldedaten aktualisiert werden. Wenn ein neues Konto verknüpft wird, muss möglicherweise der Aktualisierungsjob ausgelöst werden.
Schließlich sollten Sie das Anmeldedatenobjekt in Multithread-Anwendungen nur für Threads freigeben, die mit dem Konto ausgeführt werden, mit dem das Anmeldedatenobjekt verknüpft ist.