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