跨 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 将凭据编入索引，以确保凭据与正确的帐号相关联。此外，刷新作业应使所有凭据保持刷新状态。如果关联了新帐号，则可能需要触发刷新作业。
最后，在多线程应用中，您应仅在与凭据对象相关联的帐号上运行的线程之间共享凭据对象。