Использование учётных данных в запросах API повышает производительность и позволяет избежать чрезмерных накладных расходов, которые могут привести к ошибкам, связанным с ограничением скорости. В этом руководстве объясняется, как оптимизировать управление учётными данными OAuth2, чтобы ваше приложение могло эффективно взаимодействовать с API Google Ads.
Ваша стратегия совместного использования учётных данных будет зависеть от того, является ли ваше приложение многопоточным или многопроцессным (или распределённым) . Приложение, которое является одновременно многопроцессным и многопоточным в каждом процессе, должно использовать обе стратегии. Эти стратегии также можно адаптировать для нескольких аккаунтов Google Ads .
Многопоточный
Каждый сеанс или пользователь, созданный потоком, должен использовать один и тот же объект учётных данных. Обновление токенов доступа также должно выполняться синхронно, чтобы избежать состояния гонки.
Наши клиентские библиотеки гарантируют, что учётные данные представляют собой потокобезопасный объект, который синхронно обновляется по истечении срока действия токена доступа. В каждой из наших клиентских библиотек есть объект сеанса (или пользователя) с учётными данными, которые используются повторно на протяжении всего срока их существования. Чтобы использовать учётные данные в разных потоках, достаточно создать каждый сеанс с одними и теми же учётными данными. Например, в клиентской библиотеке Java можно создать синглтон Credential и использовать его во всех сеансах.
Многопроцессный или распределенный
Для многопроцессных или распределённых процессов необходимо сохранить учётные данные, прежде чем ими можно будет поделиться. Чтобы гарантировать, что несколько процессов или серверов не будут пытаться обновить учётные данные одновременно, что приведёт к избыточному количеству запросов на обновление, обновление следует назначить одному процессу.
Например, отдельное задание или служба могут отвечать за периодическое обновление учётных данных и их проактивную отправку в хранилище данных, используемое пулом серверов. Каждый сервер затем может извлечь учётные данные из хранилища данных при выполнении API-запроса.
Обновить работу
Задание обновления не должно ожидать истечения срока действия текущих учётных данных, прежде чем инициировать обновление. Это может привести к зависанию приложения из-за отсутствия действительных учётных данных. Однако, если срок действия токена доступа учётных данных истечёт во время обработки запроса API, запрос всё равно будет выполнен, и будут возвращены результаты.
Мы рекомендуем отслеживать время последнего обновления вашего токена доступа и принудительно обновлять его, если до истечения срока его действия осталось менее 5 минут.
Если вы не знаете, когда токен доступа обновлялся в последний раз, вы можете попытаться обновить его, предположив, что срок его действия уже истёк. Если срок действия токена доступа ещё не близок к истечению, сервер возвращает тот же токен доступа вместе с оставшимся количеством миллисекунд до истечения срока действия токена.
Хранилище данных
Вы можете использовать существующее хранилище данных или развернуть специализированное хранилище для обмена учётными данными между серверами. Решения включают в себя серверы кэширования, такие как Memcached или Infinispan , или хранилища данных NoSQL, такие как MongoDB .
Хранилище данных должно быть оптимизировано для быстрого чтения, поскольку запросов на чтение будет гораздо больше, чем запросов на запись. Кроме того, учётные данные должны храниться безопасно .
При сохранении учётных данных необходимо хранить вычисленное expiry_time (now + expires_in ) и refresh_token вместе с access_token . expiry_time рассчитывается как сумма времени запроса на обновление access_token и expires_in .
Пул серверов
Каждый сервер или процесс в пуле извлекает последние учётные данные из хранилища данных перед отправкой запроса. Пока задание обновления выполняется корректно, учётные данные будут действительны. Однако в случае сбоя задания обновления или сбоя хранилища данных необходимо предусмотреть резервный механизм.
Если сервер или процесс не может получить учетные данные из хранилища данных или срок действия учетных данных истек, сервер должен обновить свои учетные данные, чтобы приложение могло продолжить работу с API, пока проблема не будет решена.
Управление учетными данными для нескольких учетных записей
Учётные данные, созданные для управляющего аккаунта Google Ads, можно использовать для доступа ко всем его дочерним аккаунтам. Таким образом, пользователям с иерархией одного управляющего аккаунта обычно достаточно сгенерировать учётные данные для управляющего аккаунта верхнего уровня, чтобы использовать их для всех подчиненных ему аккаунтов Google Ads.
Если вашему приложению необходим доступ к аккаунтам Google Ads, которые не связаны друг с другом ни в одной иерархии управляющих аккаунтов, вам следует создать и поддерживать разные учетные данные для разных аккаунтов, например, для каждого клиентского аккаунта Google Ads, к которому вы получаете доступ, или для каждого управляющего аккаунта верхнего уровня в независимых иерархиях, к которым вы получаете доступ.
Те же стратегии можно использовать для многопоточных , многопроцессных или распределенных приложений с небольшими изменениями. При использовании общего хранилища данных учетные данные должны быть индексированы по идентификатору учетной записи customerId , чтобы гарантировать их привязку к нужной учетной записи. Кроме того, задание обновления должно обновлять все учетные данные. При подключении новой учетной записи может потребоваться запуск задания обновления.
Наконец, в многопоточных приложениях следует передавать объект учетных данных только тем потокам, которые работают с учетной записью, с которой связан объект учетных данных.