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