محدودیت ها و سهمیه های نرخ

محدودیت ها و سهمیه ها مکانیک اساسی مدیریت تقاضا برای منابع مشترک هستند: CPU، شبکه، پایگاه داده، صف ها، API های خارجی. هدف این است که عدالت، قابل پیش بینی بودن SLO ها و حفاظت از طغیان، سوء استفاده و «همسایه پر سر و صدا» باشد.

1) مفاهیم اساسی

محدودیت نرخ - محدود کردن شدت درخواست/عملیات (req/s، msg/min، بایت/ثانیه).
پشت سر هم - مجاز پشت سر هم کوتاه مدت بیش از نرخ متوسط.
سهمیه - محدودیت حجم در هر پنجره زمانی (اسناد/روز، GB/ماه).
محدودیت عملیات همزمان (درخواست/شغل همزمان).
محدوده - محدوده: در هر مستاجر، در هر کاربر، در هر نشانه، در هر نقطه پایانی، در هر IP، در هر منطقه، در هر ویژگی.

2) محدود کردن الگوریتم ها

2. 1 سطل نشانه

پارامترها: «نرخ» (نشانه ها/ثانیه)، «پشت سر هم» (اندازه سطل).
مانند «اعتبار» کار می کند: نشانه های انباشته اجازه می دهد قله های کوتاه.
مناسب برای API های خارجی و درخواست های کاربر.

2. 2 سطل نشتی

هموار «خونریزی» جریان در یک سرعت ثابت.
خوب برای صاف کردن ترافیک به عقب حساس.

2. 3 پنجره ثابت/کشویی

پنجره ثابت: ساده اما آسیب پذیر به «تعویض پنجره».
پنجره کشویی: دقیق تر، اما گران تر محاسباتی.

2. 4 GCRA (الگوریتم نرخ سلول عمومی)

معادل سطل توکن از نظر زمان ورود مجازی.
دقیق و پایدار برای محدود کننده های توزیع شده (حالت کمتر متضاد).

2. 5 محدودیت های همزمانی

محدود کردن عملیات همزمان

محافظت در برابر تخلیه استخر موضوع/اتصال و سر از خط مسدود کردن.

3) از کجا به اعمال محدودیت

در مرز (دروازه L7/API): مانع اصلی، شکست سریع (429/503)، چک های ارزان قیمت.
خدمات داخلی: درپوش های اضافی برای عملیات سنگین (صادرات، گزارش ها، تحولات).
در خروج به سیستم های خارجی: محدودیت های فردی برای اشخاص ثالث (ضد مجازات).

در صف/کارگران: انصاف به استخر به اشتراک گذاشته

4) حوزه ها و اولویت ها (چند مستاجر)

Иерархия: جهانی → منطقه → مستاجر/برنامه → کاربر/رمز → نقطه پایانی/ویژگی → IP/دستگاه.
آگاهی از اولویت: VIP/Enterprise «پشت سر هم» و وزن بیشتری کسب می کند، اما SLO های کلی را خراب نکنید.
ترکیب محدود: تحمل کل = 'min (جهانی، منطقه ای، مستاجر، کاربر، نقطه پایانی).

5) سهمیه های حجم

سهمیه روزانه/ماهانه: اسناد/روز، GB/ماه، پیام/دقیقه.
آستانه نرم/سخت: هشدارها (80/90٪) و توقف سخت.
Roll-up: حسابداری توسط اشیاء (جداول، فایل ها، رویدادها) و «برداشت» به صورتحساب.

6) محدود کننده های توزیع شده

مورد نیاز: تاخیر کم، سازگاری، تحمل خطا، مقیاس افقی.

همگامسازی محلی + احتمالاتی: سطلهای شارد محلی + همگامسازی دورهای.
فروشگاه مرکزی: Redis/KeyDB/Memcached с LUA/عملیات اتمی (INCR/PEXPIRE).
Sharding: کلیدهای فرم «limit: {scope}: {id}: {window}» با توزیع یکنواخت.
ساعت انحراف: فروشگاه «حقیقت» در سرور محدود کننده، نه در مشتریان.
Idempotency: Idempotency-Keys هزینه های کاذب را کاهش می دهد.

7) ضد سوء استفاده و حفاظت

اثر انگشت دستگاه Per-IP + برای نقاط پایانی عمومی.
اثبات کار/CAPTCHA در ناهنجاری ها.
کاهش سرعت (کاهش سرعت) به جای شکست کامل زمانی که UX مهم تر است (پیشنهادات جستجو).
محدودیت های تطبیقی: کاهش پویا آستانه برای حوادث/تخریب گران.

8) رفتار مشتری و پروتکل

کدهای: «429 Too Many Requests» (نرخ)، «403» (سهمیه/طرح بیش از حد)، «503» (تخریب محافظ).

• 'Retry-After: ' - چه زمانی دوباره امتحان کنید.

• 'RateLimit-Limit: ; w = '
• 'RateLimit-Remaining: '
• 'RateLimit-Reset: '
• برگشت: نمایی + لرزش (لرزش کامل، لرزش برابر).
• Idempotency: هدر «Idempotency-Key» و تکرارپذیری عملیات ایمن.
• زمان و لغو: به درستی درخواست های معلق را قطع کنید تا محدودیت ها را «ضبط» نکنید.

9) قابلیت مشاهده و آزمایش

Теги: 'tenant _ id', 'plan', 'user _ id', 'endpoint', 'region', 'decision' (allow/deny), 'reason' (quota/rate/concurrency).
معیارها: توان، نرخ شکست 429/403/503، تاخیر محدود کننده p95/p99، نسبت ضربه کلیدی حافظه پنهان، تخصیص برنامه.
سیاهههای مربوط به حسابرسی: علل بلوک ها، کلید های «پر سر و صدا» بالا.
تست ها: بارگذاری پروفایل ها «اره/پشت سر هم/فلات»، هرج و مرج - خرابی Redis/shard، desynchronization ساعت.

10) ادغام با صدور صورت حساب

شمارنده استفاده در مرز جمع آوری، جمع شده توسط دسته (هر N دقیقه) با idempotency.
خلاصه برنامه: هزینه های بیش از حد → بیش از حد و یا به طور موقت افزایش طرح.

اختلاف: استفاده از آشتی در مقابل فاکتور ؛ هشدار به دلتا

11) انصاف در داخل (صف، کارگران)

وزن صف عادلانه/DRR: اختصاص اسلات به مستاجران توسط وزن برنامه.
در هر مستاجر استخر کارگر: جداسازی سفت و سخت از VIP/پر سر و صدا.
کنترل پذیرش: شکست قبل از اجرا اگر سهمیه ها خسته شوند ؛ صف ها متورم نمی شوند.
Caps on concurrency: محدود کردن ضربات سنگین همزمان.

12) پروفایل های طرح معمولی (مثال)

yaml plans:
starter:
rate: 50  # req/s burst: 100 concurrency: 20 quotas:
daily_requests: 100_000 monthly_gb_egress: 50 business:
rate: 200 burst: 400 concurrency: 100 quotas:
daily_requests: 1_000_000 monthly_gb_egress: 500 enterprise:
rate: 1000 burst: 2000 concurrency: 500 quotas:
daily_requests: 10_000_000 monthly_gb_egress: 5000

13) مرجع معماری (طرح کلامی)

1. دروازه لبه/API: TLS → استخراج زمینه (مستاجر/طرح) → بررسی محدودیت ها/سهمیه ها → هدر RateLimit محل → ورود به سیستم/ردیابی.
2. موتور سیاست: قوانین اولویت (VIP)، آستانه تطبیقی.
3. فروشگاه محدود کننده: Redis/KeyDB (عملیات اتمی، LUA)، تقسیم کلید، تکرار.

4. خدمات: محدودیت ثانویه و کلاه برای عملیات سنگین ؛ idempotency ؛ استفاده از WFQ/DRR

5. استفاده/صورتحساب: جمع آوری، جمع آوری، فاکتور، هشدار توسط آستانه.
6. قابلیت مشاهده: معیارهای/سیاهههای مربوط/مسیرهای پیاده روی، داشبورد در هر مستاجر.

14) چک لیست پیش فروش

• محدوده محدود (مستاجر/کاربر/نشانه/نقطه پایانی/IP) و سلسله مراتب آنها تعریف شده است.
• الگوریتم انتخاب شده (Token Bucket/GCRA) و پارامترهای «نرخ/پشت سر هم».
• اجرا کلاه همزمانی و کنترل پذیرش برای عملیات سنگین.
• شامل 'RateLimit-' و 'Retry-After' هدر ؛ مشتریان از backoff + jitter پشتیبانی می کنند.
• محدود کننده توزیع شده و تحمل خطا (قطعات، تکرار، تخریب) است.
• استفاده از جمع آوری idempotent است ؛ بسته نرم افزاری با صدور صورت حساب، هشدار برای هزینه های بیش از حد.
• مشاهدهپذیری: metrics/trails/tagged logs, top «noisy» keys, alterters.
• تست: انفجار، «دیدم»، شکست stor، ساعت، شروع سرد.
• مستندات مشتری: محدودیت برنامه، نمونه های 429/Retry-After، بهترین شیوه ها را بازنویسی کنید.
• سیاست خروج: چگونه به طور موقت محدودیت ها را افزایش می دهد و زمانی که.

15) خطاهای معمول

محدودیت جهانی بدون هر مستاجر/نقطه پایانی - «همسایه پر سر و صدا» تمام SLO ها را می شکند.
فقدان «انفجار»: UX در انفجار کوتاه رنج می برد.
با استفاده از تنها یک پنجره ثابت → «دو ضربه در مرز پنجره».
هیچ idemotency و retrays با jitter → طوفان تکرار وجود دارد.
محدودیت فقط در مرز، بدون کلاه در خدمات/صف → «ترافیک» داخلی.
عدم رد محدودیت ها در پاسخ ها (بدون «Retry-After»، «RateLimit-») → مشتریان سازگار نیستند.
ذخیره سازی حالت محدود کننده در پایگاه داده OLTP → تاخیر بالا و قفل داغ.

16) انتخاب استراتژی سریع

API های عمومی با قله: Token Bucket + 'burst' بزرگ، RateLimit - هدر، حافظه پنهان CDN/لبه.
ضربه های سنگین داخلی: کلاه های همزمانی + WFQ/DRR، کنترل پذیرش.
ادغام با اشخاص ثالث: محدودیت خروج جداگانه، بافر/retrays.
SaaS multi-tenant: سلسله مراتب محدود (global → tenant → endpoint)، اولویت بندی VIP، سهمیه ماهانه.

نتیجه گیری

محدودیت ها و سهمیه های نرخ خوب یک قرارداد سیستم بین پلت فرم و مشتری است: سهم صادقانه از منابع، مقاومت در برابر خوشه ها، SLO های قابل پیش بینی و صورتحساب شفاف. الگوریتم ها را ترکیب کنید (کلاه های همزمانی Token/GCRA +)، سلسله مراتب ospreys را پیاده سازی کنید، هدر ها و معیارهای واضح را ارائه دهید، و به طور مرتب طرح ها را تحت پروفایل های ترافیک واقعی بررسی کنید - به این ترتیب پلتفرم حتی با رشد بار تهاجمی پایدار خواهد ماند.