Udostępnianie danych logowania w żądaniach do interfejsu API zwiększa wydajność i pozwala uniknąć nadmiernego obciążenia, które może powodować błędy związane z limitem żądań. Z tego przewodnika dowiesz się, jak zoptymalizować zarządzanie danymi logowania OAuth2, aby Twoja aplikacja mogła skutecznie korzystać z interfejsu Google Ads API.
Strategia udostępniania danych logowania zależy od tego, czy aplikacja jest multithreaded czy wieloprocesowa (lub rozproszona). Aplikacja, która jest wieloprocesowa i wielowątkowa w ramach każdego procesu, powinna stosować obie strategie. Te strategie można też dostosować do wielu kont Google Ads.
Wielowątkowy
Każda sesja lub każdy użytkownik wyodrębniony przez wątek powinien używać tego samego obiektu danych logowania. Odświeżanie tokenów dostępu musi być też wykonywane synchronicznie, aby uniknąć sytuacji wyścigu.
Nasze biblioteki klienta zapewniają, że dane logowania są obiektem bezpiecznym wątkowo, który odświeża się synchronicznie po wygaśnięciu tokena dostępu. Każda z naszych bibliotek klienta ma obiekt sesji (lub użytkownika) z danymi logowania, które są ponownie wykorzystywane przez cały okres jej istnienia. Aby udostępnić dane logowania w wielu wątkach, wystarczy utworzyć każdą sesję przy użyciu tych samych danych logowania. Na przykład w bibliotece klienta Java utworzysz Credential singleton i udostępnisz go we wszystkich sesjach.
Wieloprocesowe lub rozproszone
W przypadku procesów wieloprocesowych lub rozproszonych musisz zapisać dane logowania, zanim będziesz je udostępniać. Aby mieć pewność, że wiele procesów lub serwerów nie będzie próbowało odświeżyć danych logowania w tym samym czasie, co spowoduje nadmierną liczbę żądań odświeżenia, przypisz odświeżanie do jednego procesu.
Na przykład osobne zadanie lub usługa może okresowo odświeżać dane logowania i proaktywnie przesyłać je do magazynu danych, który jest współdzielony przez pulę serwerów. Każdy serwer może następnie pobrać dane logowania z magazynu danych podczas wysyłania żądania do interfejsu API.
Odśwież zadanie
Zadanie odświeżania nie powinno czekać na wygaśnięcie bieżących danych logowania, zanim rozpocznie odświeżanie. Może to spowodować zawieszenie się aplikacji z powodu braku prawidłowych danych logowania. Jeśli jednak token dostępu do danych logowania wygaśnie podczas przetwarzania żądania interfejsu API, żądanie zostanie zrealizowane, a wyniki zostaną zwrócone.
Zalecamy śledzenie czasu ostatniego odświeżenia tokena dostępu i wymuszanie odświeżania, jeśli do wygaśnięcia pozostało mniej niż 5 minut.
Jeśli nie wiesz, kiedy token dostępu był ostatnio odświeżany, możesz spróbować go odświeżyć, zakładając, że już wygasł. Jeśli token dostępu nie jest bliski wygaśnięcia, serwer zwraca ten sam token dostępu wraz z liczbą milisekund pozostałych do jego wygaśnięcia.
Magazyn danych
Możesz użyć istniejącego magazynu danych lub wdrożyć magazyn przeznaczony specjalnie do udostępniania danych logowania między serwerami. Rozwiązania obejmują serwery pamięci podręcznej, takie jak Memcached lub Infinispan, lub bazy danych NoSQL, takie jak MongoDB.
Pamięć danych powinna być zoptymalizowana pod kątem szybkich operacji odczytu, ponieważ będzie znacznie więcej żądań odczytu niż zapisu. Dane logowania muszą być bezpiecznie przechowywane.
Podczas przechowywania danych logowania należy przechowywać obliczone wartości expiry_time (teraz + expires_in) i refresh_token wraz z wartością access_token. Wartość expiry_time jest obliczana jako czas access_token żądania odświeżenia
plus czas expires_in.
Pula serwerów
Każdy serwer lub proces w puli pobiera najnowsze dane logowania z magazynu danych przed wysłaniem żądania. Dopóki zadanie odświeżania działa prawidłowo, dane logowania będą ważne. Jeśli jednak zadanie odświeżania lub magazyn danych ulegnie awarii, należy mieć mechanizm rezerwowy.
Jeśli serwer lub proces nie może uzyskać danych logowania z magazynu danych lub jeśli dane logowania wygasły, serwer powinien odświeżyć własne dane logowania, aby umożliwić aplikacji dalsze korzystanie z interfejsu API do czasu rozwiązania problemu.
Zarządzanie danymi logowania na wielu kontach
Dane logowania wygenerowane dla konta menedżera Google Ads mogą być używane do uzyskiwania dostępu do wszystkich jego kont podrzędnych. Dlatego w przypadku użytkowników z jedną hierarchią kont menedżera zwykle wystarczy wygenerować dane logowania do konta menedżera najwyższego poziomu, aby można było ich używać na wszystkich kontach Google Ads znajdujących się poniżej.
Jeśli Twoja aplikacja musi mieć dostęp do kont Google Ads, które nie są ze sobą powiązane w żadnej hierarchii kont menedżera, musisz wygenerować i utrzymywać różne dane logowania dla różnych kont, np. dla każdego konta klienta Google Ads, do którego uzyskujesz dostęp, lub dla każdego konta menedżera najwyższego poziomu w niezależnych hierarchiach, do których uzyskujesz dostęp.
W przypadku aplikacji multithreaded lub wieloprocesowych / rozproszonych możesz stosować te same strategie, wprowadzając niewielkie modyfikacje. Jeśli używasz wspólnego magazynu danych, dane logowania muszą być indeksowane według identyfikatora kontacustomerId, aby mieć pewność, że są powiązane z odpowiednim kontem.
Dodatkowo zadanie odświeżania powinno odświeżać wszystkie dane logowania. Jeśli połączone zostanie nowe konto, może być konieczne uruchomienie zadania odświeżania.
W aplikacjach wielowątkowych obiekt danych logowania należy udostępniać tylko wątkom działającym na koncie, z którym jest powiązany.