在 API 要求之間共用憑證可提升效能，並避免過多的額外負荷導致速率限制錯誤。本指南說明如何最佳化 OAuth2 憑證管理，讓應用程式能有效率地與 Google Ads API 互動。
您的憑證共用策略取決於應用程式是multithreaded或多程序 (或分散式)。如果應用程式在每個程序中都是多程序和多執行緒，就應該採用這兩種策略。這些策略也適用於多個 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 客戶帳戶，或是您存取的獨立階層中每個頂層管理員帳戶。
您可以略微修改，將相同的策略套用至multithreaded或多程序 / 分散式應用程式。使用共用資料存放區時，憑證必須依帳戶 ID customerId 編製索引，確保憑證與正確的帳戶建立關聯。此外，重新整理作業應會重新整理所有憑證。如果連結新帳戶，可能需要觸發重新整理作業。
最後，在多執行緒應用程式中，您應只在與憑證物件相關聯的帳戶上運作的執行緒之間，共用憑證物件。