跨 API 请求共享凭据可以提高性能，并避免可能导致速率限制错误的过多开销。本指南介绍了如何优化 OAuth2 凭据管理，以便您的应用能够与 Google Ads API 高效互动。
您的凭据共享策略将取决于您的应用是多线程还是多进程（或分布式）。在每个进程中，既是多进程又是多线程的应用，应同时采用这两种策略。这些策略同样适用于多个 Google Ads 帐号。
多线程
线程绘制的每个会话或用户都应使用相同的凭据对象。访问令牌刷新还必须同步执行，以避免争用情况。
我们的客户端库可确保凭据是线程安全对象，并在其访问令牌过期时同步刷新。我们的每个客户端库都有一个会话（或用户）对象，该对象带有一个可在其整个生命周期内重复使用的凭据。若要跨线程共享凭据，您只需使用相同的凭据构建每个会话即可。例如，在 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 Ads 经理帐号生成的凭据可用于访问其所有子帐号。因此，对于具有单一经理帐号层次结构的用户，通常只需为顶级经理帐号生成一个凭据，即可将其下级的所有 Google Ads 帐号用于该经理帐号。
如果您的应用需要访问在任何经理帐号层次结构中都不相关的 Google Ads 帐号，您应该为不同帐号生成并维护不同的凭据，例如为您访问的每个 Google Ads 客户帐号，或您访问的独立层次结构中的每个顶级经理帐号。
只需进行细微修改，即可对多线程或多进程 / 分布式应用遵循相同的策略。使用共享数据存储时，必须通过帐号标识符 customerId 将凭据编入索引，以确保凭据与正确的帐号相关联。此外，刷新作业还应确保所有凭据均已刷新。如果关联了新帐号，则可能需要触发刷新作业。
最后，在多线程应用中，您应仅在与凭据对象关联的帐号上运行的线程之间共享凭据对象。