استراتژی های مدیریت اعتبار

اشتراک‌گذاری اعتبارنامه‌ها در درخواست‌های API عملکرد را بهبود می‌بخشد و از هزینه‌های اضافی که می‌تواند منجر به خطاهای محدودیت نرخ شود، جلوگیری می‌کند. این راهنما نحوه بهینه سازی مدیریت اعتبار OAuth2 را توضیح می دهد تا برنامه شما بتواند به طور موثر با Google Ads API تعامل داشته باشد.

استراتژی به اشتراک گذاری اعتبار شما بستگی به این دارد که آیا برنامه شما چند رشته ای است یا چند فرآیندی (یا توزیع شده) . برنامه‌ای که هم چند فرآیندی و هم چند رشته‌ای در هر فرآیند است، باید از هر دو استراتژی استفاده کند. این استراتژی‌ها را می‌توان برای چندین حساب Google Ads نیز تطبیق داد.

چند رشته ای

هر جلسه یا کاربری که توسط یک رشته ترسیم می شود باید از همان شی اعتبار استفاده کند. تازه کردن نشانه دسترسی نیز باید به طور همزمان انجام شود تا از شرایط مسابقه جلوگیری شود.

کتابخانه‌های سرویس گیرنده ما اطمینان می‌دهند که اعتبار یک شیء ایمن برای رشته است که زمانی که رمز دسترسی آن منقضی می‌شود، خود را به طور همزمان تازه‌سازی می‌کند. هر یک از کتابخانه های مشتری ما یک شی جلسه (یا کاربر) با اعتبار دارد که در طول عمر خود مجدداً از آن استفاده می کند. برای به اشتراک گذاشتن اعتبار در سراسر رشته ها، فقط هر جلسه را با استفاده از اعتبار یکسان می سازید. برای مثال، در کتابخانه کلاینت جاوا، می‌توانید یک Credential singleton ایجاد کنید و آن را در تمام جلسات به اشتراک بگذارید.

چند فرآیندی یا توزیع شده

برای چند فرآیند یا فرآیندهای توزیع شده، قبل از اینکه بتوانید آن را به اشتراک بگذارید، باید اعتبار را حفظ کنید. برای اطمینان از اینکه چندین پردازش یا سرور به طور همزمان سعی نمی‌کنند اعتبارنامه را به‌روزرسانی کنند و در نتیجه درخواست‌های تازه‌سازی بیش از حد انجام شود، باید به‌روزرسانی را به یک فرآیند اختصاص دهید.

به عنوان مثال، یک کار یا سرویس جداگانه می‌تواند مسئول تجدید دوره‌ای اعتبارنامه و انتقال فعال آن به یک فروشگاه داده باشد که توسط مجموعه‌ای از سرورها به اشتراک گذاشته شده است. سپس هر سرور می تواند در هنگام درخواست 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 نمایه شوند تا اطمینان حاصل شود که اعتبارنامه ها با حساب مناسب مرتبط هستند. علاوه بر این، کار به‌روزرسانی باید تمام اعتبارنامه‌ها را تازه نگه دارد. اگر حساب جدیدی پیوند داده شده باشد، ممکن است لازم باشد کار به‌روزرسانی فعال شود.

در نهایت، در برنامه‌های چند رشته‌ای، فقط باید شی اعتبارنامه را در رشته‌هایی به اشتراک بگذارید که در حسابی که شی اعتبار با آن مرتبط است، کار می‌کنند.