Wenn Sie Anmeldedaten für Ihre API-Anfragen freigeben, wird die Leistung verbessert und übermäßiger Aufwand vermieden, 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 Multithread oder Multiprozess (oder verteilt) ist. Bei einer Anwendung, die in jedem Prozess sowohl Multiprozess als auch Multithread ist, sollten beide Strategien eingesetzt werden. Diese Strategien können auch für mehrere Google Ads-Konten angepasst werden.
Multithread
Jede Sitzung oder jeder Nutzer, die von einem Thread erstellt wird, sollte dasselbe Anmeldedatenobjekt verwenden. Aktualisierungen von Zugriffstoken müssen ebenfalls synchron erfolgen, um Race-Bedingungen zu vermeiden.
Unsere Clientbibliotheken sorgen dafür, dass die Anmeldedaten ein Thread-sicheres Objekt sind, das sich automatisch selbst aktualisiert, wenn sein Zugriffstoken abläuft. Jede unserer Clientbibliotheken hat ein Sitzungs- oder Nutzerobjekt mit Anmeldedaten, die während ihrer gesamten Lebensdauer wiederverwendet werden. Um Anmeldedaten zwischen Threads zu teilen, müssen Sie einfach jede Sitzung mit denselben Anmeldedaten erstellen. In der Java-Clientbibliothek würden Sie beispielsweise ein Credential-Singleton erstellen und in allen Sitzungen verwenden.
Multiprozess oder verteilt
Bei Multiprozess- oder verteilten Prozessen müssen Sie die Anmeldedaten dauerhaft speichern, bevor Sie sie freigeben können. Damit nicht mehrere Prozesse oder Server gleichzeitig versuchen, die Anmeldedaten zu aktualisieren, was zu einer übermäßigen Anzahl von Aktualisierungsanfragen führt, sollten Sie die Aktualisierung einem einzigen Prozess zuweisen.
Beispielsweise kann ein separater Job oder Dienst 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 bei einer API-Anfrage die Anmeldedaten aus dem Datenspeicher abrufen.
Aktualisierungsauftrag
Der Aktualisierungsauftrag sollte nicht warten, bis die aktuellen Anmeldedaten abgelaufen sind, bevor eine Aktualisierung initiiert wird. Das kann dazu führen, dass die Anwendung aufgrund fehlender gültiger Anmeldedaten blockiert wird. Wenn das Zugriffstoken eines Berechtigungsnachweises jedoch 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 das Zugriffstoken zuletzt aktualisiert wurde, und eine Aktualisierung zu erzwingen, wenn weniger als 5 Minuten bis zum Ablauf das Ablaufdatum erreicht ist.
Wenn Sie nicht wissen, wann ein Zugriffstoken zuletzt aktualisiert wurde, können Sie versuchen, es zu aktualisieren, sofern es bereits abgelaufen ist. Wenn das Zugriffstoken nicht kurz davor ist, zu laufen, gibt der Server dasselbe Zugriffstoken zurück, zusammen mit den Millisekunden, die bis zum Ablauf des Tokens verbleiben.
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. Lösungen umfassen Caching-Server wie Memcached oder Infinispan oder NoSQL-Datenspeicher wie MongoDB.
Der Datenspeicher sollte für schnelle Lesevorgänge optimiert sein, da es viel mehr Leseanfragen als Schreibvorgänge gibt. Anmeldedaten müssen außerdem sicher gespeichert werden.
Beim Speichern der Anmeldedaten sollten Sie die berechneten Werte für expiry_time (jetzt + expires_in) und 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 der Aktualisierungsjob oder Datenspeicher jedoch 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.
Anmeldedaten für mehrere Konten verwalten
Für ein Google Ads-Verwaltungskonto generierte Anmeldedaten können für den Zugriff auf alle untergeordneten Konten verwendet werden. Für Nutzer mit einem Verwaltungskonto reicht es daher in der Regel aus, Anmeldedaten für das Verwaltungskonto der obersten Ebene zu generieren, damit sie für alle untergeordneten Google Ads-Konten verwendet werden können.
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. Dies kann beispielsweise für jedes Google Ads-Kundenkonto, auf das Sie zugreifen, oder für jedes Verwaltungskonto der obersten Ebene in den unabhängigen Hierarchien sein, auf die Sie zugreifen.
Sie können die gleichen Strategien mit geringfügigen Änderungen auch für Multithread-Anwendungen oder Multiprozess-/verteilte Anwendungen anwenden. Bei Verwendung eines freigegebenen Datenspeichers müssen Anmeldedaten mit der Konto-ID customerId indexiert werden, damit sie mit dem richtigen Konto verknüpft werden.
Außerdem sollten durch den Aktualisierungsauftrag alle Anmeldedaten auf dem neuesten Stand gehalten werden. Wenn ein neues Konto verknüpft wird, muss möglicherweise der Aktualisierungsjob ausgelöst werden.
Bei Multithread-Anwendungen sollten Sie das Anmeldedatenobjekt nur zwischen Threads teilen, die in dem Konto aktiv sind, mit dem das Berechtigungsnachweisobjekt verknüpft ist.