在各個 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 客戶帳戶，或是您存取的獨立階層中的每個頂層管理員帳戶。
您可以小幅修改多執行緒或多程序 / 已發行應用程式，遵循相同的策略。使用共用資料儲存庫時，憑證必須依帳戶 ID customerId 建立索引，以確保憑證與正確的帳戶相關聯。此外，更新工作也應持續更新所有憑證。如果已連結新帳戶，可能需要觸發重新整理工作。
最後，在多執行緒應用程式中，您只應在與憑證物件相關聯帳戶上執行的執行緒之間共用憑證物件。