在各個 API 要求之間共用憑證可改善效能，避免產生過多負擔，以免發生頻率限制錯誤。本指南說明如何調整 OAuth2 憑證管理方式，讓應用程式能有效與 Google Ads API 互動。
您的憑證共用策略取決於應用程式為多執行緒或多程序 (或發布) 應用程式。無論應用程式在每項程序中，同時是多程序和多執行緒的應用程式，就應同時採用這兩種策略。這些策略也可針對多個 Google Ads 帳戶進行調整。
多執行緒
由執行緒繪製的每個工作階段或使用者應使用相同的憑證物件。系統也必須同步執行存取權杖重新整理作業，以免發生競爭狀況。
我們的用戶端程式庫會確保憑證是一個安全的執行緒物件，它會在存取權杖到期時，同步更新。我們每個用戶端程式庫都有一個工作階段 (或使用者) 物件，其中包含可在整個生命週期中重複使用的憑證。如要在各執行緒之間共用憑證，只要使用同一個憑證建構每個工作階段即可。例如，在 Java 用戶端程式庫中，您可以建立 Credential 單例模式，並在所有工作階段之間共用。
多程序或分散式
如果是多程序或分散式程序，則必須先保留憑證，才能共用憑證。為確保多個程序或伺服器不會嘗試同時更新憑證，導致更新要求量過多，您應將重新整理作業指派給單一程序。
舉例來說，獨立的工作或服務可以負責定期更新憑證，並主動將其推送到由眾多伺服器共用的資料儲存庫。如此一來，在提出 API 要求時，每個伺服器就可以從資料儲存庫擷取憑證。
更新工作
應等到目前的憑證到期後，才啟動重新整理工作。這麼做可能會導致應用程式因缺少有效憑證而停滯；但如果憑證的存取權杖在 API 要求處理期間到期，要求仍會完成，而系統會傳回結果。
建議您追蹤上次更新存取權杖的時間，並在到期前不到 5 分鐘強制重新整理。
如果不知道存取權杖上次更新的時間，可以嘗試重新整理 (假設存取權杖已過期)。如果存取權杖接近間隔，伺服器會傳回相同的存取權杖；而在權杖過期前，還有幾毫秒的時間。
資料儲存庫
您可以使用現有的資料儲存區，也可以另外部署專用的儲存區，方便各伺服器共用憑證。解決方案包括快取伺服器 (例如 Memcached 或 Infinispan)，或是 MongoDB 等 NoSQL 資料儲存庫。
資料儲存庫應針對快速讀取作業進行最佳化，因為讀取要求的數量會多於寫入。此外，憑證必須妥善儲存。
儲存憑證時，應將計算出的 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 建立索引，以確保憑證與正確的帳戶建立關聯。此外，更新工作也必須讓所有憑證維持最新狀態。如果您連結了新帳戶，可能就需要觸發重新整理工作。
最後，在多執行緒應用程式中，您應只在與憑證物件相關聯的帳戶上運作的執行緒之間共用憑證物件。