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