Udostępnianie danych logowania między żądaniami do interfejsu API zwiększa wydajność i pozwala uniknąć nadmiernego narzutu, który może skutkować błędami ograniczania liczby żądań. Z tego przewodnika dowiesz się, jak zoptymalizować zarządzanie danymi logowania OAuth2, aby aplikacja mogła efektywnie korzystać z interfejsu Google Ads API.
Strategia udostępniania danych logowania zależy od tego, czy aplikacja jest wielowątkowa czy wieloprocesowa (lub rozproszona). Aplikacja, która jest zarówno wieloprocesowa, jak i wielowątkowa w ramach każdego procesu, powinna stosować obie strategie. Te strategie można też dostosować do wielu kont Google Ads.
Wielowątkowa
Każda sesja lub użytkownik rysowany przez wątek powinien używać tego samego obiektu danych logowania. Aby uniknąć wyścigu, należy odświeżać tokeny dostępu synchronicznie.
Nasze biblioteki klienta dbają o to, aby dane logowania były bezpiecznym wątkiem obiektem, 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órych używa od początku. Aby udostępnić dane logowania w wątkach, utwórz każdą sesję przy użyciu tych samych danych logowania. Na przykład w bibliotece klienta w języku Java można utworzyć pojedynczy token Credential i udostępnić go we wszystkich sesjach.
Wieloprocesowe lub rozproszone
W przypadku procesów wieloprocesowych lub rozproszonych musisz zachować dane logowania przed ich udostępnieniem. Aby mieć pewność, że wiele procesów lub serwerów nie próbuje jednocześnie odświeżać danych logowania, powodując nadmierną liczbę żądań odświeżania, przypisz odświeżanie do jednego procesu.
Na przykład osobne zadanie lub usługa może być odpowiedzialne za okresowe odświeżanie danych logowania i aktywne przekazywanie ich do magazynu danych współdzielonego przez pulę serwerów. Każdy serwer może następnie pobrać dane logowania z magazynu danych podczas tworzenia żądania do interfejsu API.
Odśwież zadanie
Przed zainicjowaniem odświeżania zadanie odświeżania nie powinno czekać na wygaśnięcie bieżących danych logowania. Może to spowodować wstrzymanie aplikacji z powodu braku ważnych danych logowania. Jeśli jednak token dostępu danych logowania wygaśnie w trakcie przetwarzania żądania do interfejsu API, żądanie zostanie ukończone, a jego wyniki zostaną zwrócone.
Zalecamy śledzenie czasu, w którym token dostępu był ostatnio odświeżany, i wymuszanie go, jeśli do wygaśnięcia jest mniej niż 5 minut.
Jeśli nie wiesz, kiedy token dostępu został ostatnio odświeżony, możesz spróbować go odświeżyć, zakładając, że już wygasł. Jeśli token dostępu nie jest bliski utraty ważności, serwer zwraca ten sam token dostępu wraz z milisekundami pozostałym do jego wygaśnięcia.
magazyn danych
Możesz wykorzystać istniejący magazyn danych lub wdrożyć własną bazę do udostępniania danych logowania między serwerami. Rozwiązania obejmują serwery pamięci podręcznej, takie jak Memcached lub Infinispan, oraz magazyny danych NoSQL, takie jak MongoDB.
Magazyn danych powinien być zoptymalizowany pod kątem szybkich operacji odczytu, ponieważ żądań odczytu będzie znacznie więcej niż zapisów. Dane logowania muszą być bezpieczne.
Podczas przechowywania danych logowania należy przechowywać obliczone expiry_time (teraz + expires_in) i refresh_token razem z access_token. Wartość expiry_time jest obliczana jako czas żądania odświeżenia access_token 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. Jeśli zadanie odświeżania jest uruchomione prawidłowo, dane logowania będą ważne. Jeśli jednak zadanie odświeżania lub magazyn danych nie powiedzie się, należy mieć mechanizm zastępczy.
Jeśli serwer lub proces nie może pobrać danych logowania z magazynu danych albo dane logowania straciły ważność, serwer powinien odświeżyć własne dane uwierzytelniające, aby umożliwić aplikacji kontynuowanie pracy z interfejsem API do czasu rozwiązania problemu.
Zarządzanie danymi logowania na wielu kontach
Dane logowania wygenerowane dla konta menedżera Google Ads pozwalają uzyskać dostęp do wszystkich jego kont podrzędnych. Dlatego w przypadku użytkowników z jedną hierarchią konta menedżera zazwyczaj wystarczy wygenerować dane logowania do konta menedżera najwyższego poziomu, które będą używane na potrzeby wszystkich kont Google Ads podrzędnych.
Jeśli Twoja aplikacja potrzebuje dostępu do kont Google Ads, które nie są ze sobą powiązane w żadnej hierarchii konta menedżera, musisz wygenerować i obsługiwać różne dane logowania dla poszczególnych kont, np. dla każdego konta klienta Google Ads, do którego masz dostęp, lub każdego konta menedżera najwyższego poziomu w niezależnych hierarchii, do których masz dostęp.
Te same strategie możesz stosować w przypadku aplikacji wielowątkowych lub wieloprocesowych bądź rozproszonych, ale z niewielkimi zmianami. Gdy korzystasz z udostępnianego magazynu danych, dane logowania muszą być indeksowane według identyfikatora konta customerId, aby mieć pewność, że dane logowania są powiązane z właściwym kontem.
Oprócz tego zadanie odświeżania powinno utrzymywać wszystkie dane logowania. Jeśli połączysz nowe konto, może być konieczne aktywowanie zadania odświeżania.
Wreszcie w aplikacjach wielowątkowych należy udostępniać obiekt danych logowania tylko między wątkami działającymi na koncie, z którym jest powiązany obiekt danych logowania.