Wenn Sie Anmeldedaten für alle Ihre API-Anfragen verwenden, verbessern Sie die Leistung und vermeiden unnötigen Overhead, der zu Ratenbegrenzungen führen kann. In diesem Leitfaden wird erläutert, wie Sie die Verwaltung von OAuth2-Anmeldedaten optimieren, damit Ihre App effizient mit der Google Ads API interagieren kann.
Ihre Strategie für die gemeinsame Nutzung von Anmeldedaten hängt davon ab, ob Ihre App multithreaded oder Multiprocessing (oder verteilt) verwendet. Eine App, die sowohl Multiprocess- als auch Multithread-fähig ist, sollte beide Strategien nutzen. Diese Strategien lassen sich auch für mehrere Google Ads-Konten anpassen.
Multithread
Für jede Sitzung oder jeden Nutzer, der von einem Thread abgerufen wird, sollte dasselbe Anmeldedatenobjekt verwendet werden. Aktualisierungen von Zugriffstokens müssen ebenfalls synchron erfolgen, um Race-Bedingungen zu vermeiden.
Unsere Clientbibliotheken sorgen dafür, dass die Anmeldedaten ein threadsicheres Objekt sind, das sich synchron aktualisiert, wenn das Zugriffstoken abläuft. Jede unserer Clientbibliotheken hat ein Sitzungs- oder Nutzerobjekt mit Anmeldedaten, die während der 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 es für alle Sitzungen freigeben.
Multiprocess oder verteilt
Bei Prozessen mit mehreren 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äßigen Aktualisierungsanfragen führen würde, sollten Sie die Aktualisierung einem einzelnen Prozess zuweisen.
Beispielsweise kann ein separater Job oder Dienst dafür verantwortlich sein, die Anmeldedaten regelmäßig zu aktualisieren und proaktiv in einen Datenspeicher zu übertragen, der von einem Pool von Servern gemeinsam genutzt wird. Jeder Server kann die Anmeldedaten dann beim Senden einer API-Anfrage aus dem Datenspeicher abrufen.
Aktualisierungsauftrag
Der Aktualisierungsjob sollte nicht warten, bis die aktuellen Anmeldedaten ablaufen, bevor er eine Aktualisierung startet. Dies kann dazu führen, dass die App aufgrund fehlender gültiger Anmeldedaten nicht mehr reagiert. Wenn das Zugriffstoken einer Anmeldedaten abläuft, während die API-Anfrage verarbeitet wird, wird die Anfrage jedoch trotzdem abgeschlossen und es werden Ergebnisse zurückgegeben.
Wir empfehlen, die Zeit im Blick zu behalten, zu der Ihr Zugriffstoken zuletzt aktualisiert wurde, und eine Aktualisierung zu erzwingen, wenn weniger als 5 Minuten bis zum Ablauf verbleiben.
Wenn Sie nicht wissen, wann ein Zugriffstoken zuletzt aktualisiert wurde, können Sie versuchen, es zu aktualisieren, da es möglicherweise bereits abgelaufen ist. Wenn das Zugriffstoken nicht kurz vor dem Ablauf steht, gibt der Server dasselbe Zugriffstoken zusammen mit der Anzahl der Millisekunden zurück, 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 geben wird. Außerdem müssen Anmeldedaten sicher gespeichert werden.
Wenn Sie die Anmeldedaten speichern, sollten Sie die berechneten expiry_time (jetzt + expires_in) und refresh_token zusammen mit dem access_token speichern. Die expiry_time wird als Zeitpunkt der access_token-Aktualisierungsanfrage plus die expires_in-Zeit berechnet.
Serverpool
Jeder Server oder Prozess im Pool ruft die neuesten Anmeldedaten aus dem Datenspeicher ab, bevor er eine Anfrage sendet. Solange der Aktualisierungsjob ordnungsgemäß ausgeführt wird, ist die Anmeldedaten gültig. Wenn der Aktualisierungsjob oder der Datenspeicher jedoch fehlschlägt, sollten Sie einen Fallback-Mechanismus haben.
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 App weiterhin mit der API arbeiten kann, bis das Problem behoben ist.
Anmeldedatenverwaltung für mehrere Konten
Mit Anmeldedaten, die für ein Google Ads-Verwaltungskonto generiert wurden, kann auf alle untergeordneten Konten zugegriffen werden. Für Nutzer mit einer einzelnen Verwaltungskontohierarchie reicht es daher in der Regel aus, Anmeldedaten für das Verwaltungskonto der obersten Ebene zu generieren, die für alle darunter liegenden Google Ads-Konten verwendet werden können.
Wenn Ihre App auf Google Ads-Konten zugreifen muss, die in keiner Verwaltungskontohierarchie miteinander verknüpft sind, sollten Sie für die verschiedenen Konten unterschiedliche Anmeldedaten generieren und verwalten, z. B. für jedes Google Ads-Kundenkonto, auf das Sie zugreifen, oder für jedes Verwaltungskonto der obersten Ebene in den unabhängigen Hierarchien, auf die Sie zugreifen.
Sie können dieselben Strategien für multithreaded oder Apps mit mehreren Prozessen / verteilten Apps mit geringfügigen Änderungen anwenden. Wenn Sie einen freigegebenen Datenspeicher verwenden, müssen Anmeldedaten nach der Konto-ID customerId indexiert werden, damit sie dem richtigen Konto zugeordnet werden.
Außerdem sollten alle Anmeldedaten durch den Aktualisierungsjob aktualisiert werden. Wenn ein neues Konto verknüpft wird, muss der Aktualisierungsjob möglicherweise ausgelöst werden.
In Multithread-Apps sollten Sie das Anmeldedatenobjekt nur für Threads freigeben, die für das Konto ausgeführt werden, mit dem das Anmeldedatenobjekt verknüpft ist.