Google Ads API is returning to beta status. Please read our blog post for more details.

优化 OAuth 请求

如果您的应用不能在服务器、进程和线程之间共享凭据,就可能会向 Google 发送过多的请求。这可能导致我们的服务器对您的应用强制执行速率限制,造成性能下降。

本节介绍如何优化 OAuth2 凭据管理,以便您的应用可以与 Google Ads API 进行高效互动。

凭据共享策略

跨 API 请求共享凭据可提高性能,并避免可能引发速率限制错误的过多开销。

您的凭据共享策略取决于您的应用设计:

在多线程应用中,应该为每个线程的会话提供相同的凭据。

在多进程或分布式应用中,必须实现一些基础架构,才能跨进程共享凭据。您还应该确保线程不会被阻止,并且自己的实现中不存在争用的情况。

在每个进程中,既是多进程/分布式又是多线程的应用,应同时使用两种策略。

下面对这些可执行单个 Google Ads 帐号(例如层级结构中的顶级经理帐号)身份验证的策略进行了介绍。

然后介绍了如何调整这些策略,以便对多个 Google Ads 帐号进行身份验证

多线程应用

多线程应用应在线程之间共享凭据。应同步执行对凭据的刷新,以避免出现争用情况。

运行时

该图显示了一个运行时,其中带有从会话(或用户)池提取的线程,可向 Google Ads API 发出请求。请注意,每个会话应使用相同的凭据对象。在每个 API 请求中,线程会获取会话(或用户)。如果凭据需要进行访问令牌刷新,则必须同步执行,即凭据对象必须具有线程安全性,以避免出现争用情况。

客户端库可直接跨线程共享凭据。每个客户端库都有一个会话(或用户)对象,该对象带有可在其生命周期中重用的凭据。要跨线程共享该凭据,只需使用这个相同的凭据构建每个会话即可。在所有客户端库中,凭据都是具有线程安全性的对象,会在其访问令牌期满时进行自我同步刷新。例如,在 Java 客户端库中,您可以将 Credential 创建为单实例模式,然后在所有会话间共享。

多进程或分布式应用

在多进程或分布式应用中,应使用共享的凭据。为了确保多个进程或服务器不会同时尝试刷新凭据,而导致刷新请求过多,我们建议在中央位置主动刷新凭据,然后在进程/服务器之间进行共享。

例如,可安排独立的作业或服务负责周期性地刷新凭据,然后主动地将凭据推送到数据存储,供服务器池使用。

刷新

上图显示的凭据刷新作业会定期运行,并将凭据的属性写入数据存储。然后,每个服务器都会在向 API 发出请求前获取该凭据。

刷新作业

刷新作业会定期刷新凭据并将其存储在数据存储中。作业不应等到当前凭据到期才启动刷新,否则可能导致应用因缺少有效凭据而停止运行,开一个“天窗”。

较好的替代方法是定期强制刷新,每次都用新凭据替换数据存储中的凭据。刷新作业应该在当前凭据到期之前尽早运行,以便预留一些时间,防止出现瞬间失败。比如,可考虑先从每 15 分钟刷新一次开始。

数据存储

中央数据存储可用于在进程和服务器之间共享凭据。

您既可以使用现有的数据存储,也可以部署一个特定于服务器间凭据共享的数据存储。解决方案既可以是缓存服务器(如 MemcachedInfinispan),也可以是 NoSQL 数据存储(如 MongoDB)。

对于向 API 发出请求的所有服务器,数据存储都必须提供可靠的接口。此外,还应对数据存储进行优化,以便实现快速读取操作,因为服务器或进程读取当前凭据的频率高于刷新作业更新该凭据的频率。

请记住,必须对凭据进行安全存储

存储凭据时,应该随 access_token 存储计算出的 expiry_time(现在要加上 expires_in)和 refresh_tokenexpiry_time 计算方法是 access_token 刷新请求的时间加上 expires_in 时间。

服务器池

池中的每个服务器或进程先从数据存储中获取最新的凭据,然后才发出请求。只要刷新作业成功运行,凭据就会有效。但是,如果刷新作业或数据存储失败,您应该有一个回退机制。

如果服务器或进程无法从数据存储获取凭据,或者凭据已过期,则服务器应刷新自己的凭据,以允许应用继续使用 API,直到问题解决。

在有多个线程的处理过程中,您应该使用上述共享策略在线程间共享凭据。

验证多个帐号的身份

为 Google Ads 经理帐号生成的凭据可用于访问其所有子帐号。因此,对于具有单一经理帐号层级结构的用户,通常只需为顶级经理帐号生成凭据,即可为其下的所有 Google Ads 帐号实现应用授权。

另一些情况下,您的应用必须访问在任何经理帐号层级结构中彼此都不相关的 Google Ads 帐号。在这种情况下,对于不同的帐号(例如您访问的每个 Google Ads 客户帐号,或您访问的独立层级结构中的每个顶级经理帐号),您应该生成并维护不同的凭据。

只需进行最低程度的修改,即可对多线程多进程/分布式应用采用相同的策略。在使用共享数据存储时,必须通过帐号标识符 customerId 对凭据编制索引,以确保凭据与正确的帐号相关联。此外,刷新作业应保持对所有凭据进行刷新。如果关联了新帐号,则可能需要触发刷新作业。

最后,在多线程应用中,您应该只在凭证对象所关联的帐号上运行的线程之间共享凭证对象。

后续步骤