محدودیت های نرخ
Google Ads API درخواست‌هایی را برای محدود کردن نرخ بر اساس پرس و جو در ثانیه (QPS) به ازای هر شناسه مشتری (CID) و نشانه توسعه‌دهنده جمع‌آوری می‌کند، به این معنی که اندازه‌گیری به‌طور مستقل هم روی CID و هم بر روی نشانه‌های توسعه‌دهنده اعمال می‌شود. Google Ads API از یک الگوریتم Token Bucket برای اندازه‌گیری درخواست‌ها و تعیین حد QPS مناسب استفاده می‌کند، بنابراین محدودیت دقیق بسته به بار کلی سرور در هر زمان معین متفاوت خواهد بود.
هدف از اعمال محدودیت‌های نرخ این است که از ایجاد اختلال در سرویس برای سایر کاربران توسط یک کاربر (اعم از عمد یا غیرعمد) جلوگیری شود که سرورهای Google Ads API با حجم بالایی از درخواست‌ها را تحت تأثیر قرار می‌دهد.
درخواست‌هایی که محدودیت‌های نرخ را نقض می‌کنند با این خطا رد می‌شوند: RESOURCE_TEMPORARILY_EXHAUSTED .
شما می توانید با کاهش فعال تعداد درخواست ها و محدود کردن QPS از سمت مشتری، کنترل برنامه خود را در دست بگیرید و محدودیت های نرخ را کاهش دهید.
راه های مختلفی برای کاهش احتمال تجاوز از حد مجاز وجود دارد. آشنایی با مفاهیم الگوهای ادغام سازمانی (EIP) مانند پیام‌رسانی، تحویل مجدد، و Throttling می‌تواند به شما در ایجاد یک برنامه مشتری قوی‌تر کمک کند.
روش‌های توصیه‌شده زیر که بر اساس پیچیدگی مرتب شده‌اند، با استراتژی‌های ساده‌تر در بالا و معماری‌های قوی‌تر اما پیچیده‌تر بعد از آن:
وظایف همزمان را محدود کنید
یکی از دلایل اصلی بیش از حد مجاز این است که برنامه مشتری تعداد زیادی کار موازی ایجاد می کند. در حالی که ما تعداد درخواست‌های موازی را که یک برنامه مشتری می‌تواند داشته باشد محدود نمی‌کنیم، این می‌تواند به راحتی از محدودیت درخواست در ثانیه در سطح توکن توسعه‌دهنده فراتر رود.
تنظیم یک حد بالا معقول برای تعداد کل وظایف همزمانی که قرار است درخواست‌ها را انجام دهند (در همه فرآیندها و ماشین‌ها)، و تنظیم به سمت بالا برای بهینه‌سازی توان خود بدون تجاوز از حد مجاز توصیه می‌شود.
علاوه بر این، می‌توانید QPS را از سمت کلاینت در نظر بگیرید ( محدود کننده‌های Throttling و نرخ را بررسی کنید).
بچینگ درخواست ها
دسته بندی چندین عملیات را در یک درخواست در نظر بگیرید. این بیشتر در تماس های MutateFoo کاربرد دارد. به عنوان مثال، اگر در حال به‌روزرسانی وضعیت برای چندین نمونه از AdGroupAd هستید - به جای اینکه برای هر AdGroupAd یک بار MutateAdGroupAds فراخوانی کنید، می‌توانید یک بار MutateAdGroupAds فراخوانی کنید و چندین operations را انجام دهید. برای چند مثال اضافی به راهنمای عملیات دسته ای ما مراجعه کنید.
در حالی که درخواست‌های دسته‌ای تعداد کل درخواست‌ها را کاهش می‌دهد و محدودیت نرخ درخواست‌ها در دقیقه را کاهش می‌دهد، اگر تعداد زیادی عملیات را علیه یک حساب واحد انجام دهید، ممکن است محدودیت نرخ عملیات در دقیقه را ایجاد کند.
محدود کننده های گاز و سرعت
علاوه بر محدود کردن تعداد کل رشته‌ها در برنامه مشتری، می‌توانید محدودکننده‌های نرخ را در سمت کلاینت نیز پیاده‌سازی کنید. این می تواند تضمین کند که تمام رشته ها در سراسر فرآیندها و / یا خوشه های شما توسط یک محدودیت QPS خاص از سمت مشتری کنترل می شوند.
می‌توانید Guava Rate Limiter را بررسی کنید، یا الگوریتم مبتنی بر Token Bucket خود را برای یک محیط خوشه‌ای پیاده‌سازی کنید. به عنوان مثال، می‌توانید توکن‌ها را تولید کنید و آنها را در یک فضای ذخیره‌سازی تراکنشی مشترک مانند پایگاه داده ذخیره کنید، و هر کلاینت باید قبل از پردازش درخواست، یک توکن را خریداری و مصرف کند. اگر توکن‌ها تمام می‌شدند، مشتری باید منتظر بماند تا دسته بعدی توکن‌ها تولید شود.
در صف
صف پیام راه حلی برای توزیع بار عملیات است و در عین حال نرخ درخواست و مصرف کننده را نیز کنترل می کند. تعدادی از گزینه های صف پیام در دسترس هستند - برخی منبع باز، برخی اختصاصی - و بسیاری از آنها می توانند با زبان های مختلف کار کنند.
هنگام استفاده از صف‌های پیام، می‌توانید چندین تولیدکننده داشته باشید که پیام‌ها را به صف ارسال می‌کنند و چندین مصرف‌کننده آن پیام‌ها را پردازش می‌کنند. دریچه‌های گاز را می‌توان با محدود کردن تعداد مصرف‌کننده‌های همزمان در سمت مصرف‌کننده پیاده‌سازی کرد، یا برای تولیدکنندگان یا مصرف‌کنندگان، محدودکننده‌های نرخ یا دریچه‌های گاز را اعمال کرد.
به عنوان مثال، اگر یک مصرف کننده پیام با خطای محدودیت نرخ مواجه شود، آن مصرف کننده می تواند درخواست را به صف بازگرداند تا دوباره امتحان شود. در همان زمان، آن مصرف کننده می تواند به همه مصرف کنندگان دیگر اطلاع دهد تا پردازش را برای چند ثانیه متوقف کنند تا از خطا بازیابی شود.