محدودیت نرخ و کنترل بار

TL ؛ دکتر متخصص

یک مدار قابل اعتماد ترکیبی از محدودیت ها و سهمیه ها در سطوح مختلف (لبه → BFF → servis)، تخصیص منابع منصفانه (در هر مستاجر/کلید/مسیر)، SLO-adaptable throttling و backprescher به جای خاموش کردن خاموش است. استفاده از نشانه/سطل نشتی برای «سرعت»، پنجره کشویی برای سهمیه حسابداری، محدودیت های رقابتی برای عملیات سنگین، کاهش پویا در تخریب و قطع کننده مدار به بالادست شکننده. همه چیز تحت نظر و با بازی است.

1) چرا محدودیت در iGaming/fintech

SLO و پایداری: محافظت در برابر بهمن های برگشتی، قله های مسابقات/رویداد، سنبله های پرداخت.
عدالت: یک مستاجر یا شریک کل بودجه را نمی خورد.
ضد سوء استفاده/رباتها: ورود/ثبت نام, هرزنامه, خراش دادن دایرکتوری.
هزینه: محدود کردن تماس های گران قیمت (KYC، گزارش ها، جمع آوری ها).
انطباق/استفاده منصفانه: سهمیههای رسمی «استفاده منصفانه» در قراردادها.

2) طبقه بندی محدود

3) الگوریتم ها و جایی که باید اعمال شود

3. 1 سطل توکن (پیش فرض)

پارامترها: «نرخ» (نشانه ها/ثانیه)، «پشت سر هم» (حداکثر حاشیه).
عالی برای خواندن API، پرداخت/وضعیت، BFF.
با یک سطل خالی → 429 + 'Retry-After'.

3. 2 سطل نشتی (به طور متوسط)

تضمین «تخریب» RPS، مفید برای webhooks به طوری که به کارگران نمره نیست.

3. 3 پنجره ثابت در مقابل پنجره کشویی

ثابت - ساده، اما «مرزها» ؛ کشویی - حسابداری منصفانه در پنجره (حداقل/ساعت/روز).
اعمال کشویی برای سهمیه های قراردادی.

3. 4 محدودیت های همزمان

محدود کردن فعالیت های همزمان ایده آل برای صادرات/گزارش، بسته های KYC، پردازش مجدد.
در صورت کمبود - 429/503 + صف/نظرسنجی.

3. 5 هزینه/پیچیدگی محدود کننده

GraphQL/search: «هزینه» را با عمق/کاردینالیتی/پسوندها در نظر بگیرید.
بریده شدن/تخریب درخواست های «گران»، پاسخ با یک اشاره.

4) کلید های اندازه گیری

هر مستاجر (چند اجاره نامه، حقوق صاحبان سهام)،

per-api_key/client_id (همکاران)

در هر مسیر (جهش بحرانی شدید تر)،

در هر کاربر/دستگاه/IP/ASN/جغرافیایی

per-BIN/کشور (روش های پرداخت، حفاظت از صادرکنندگان و ارائه دهندگان)،

در هر روش (دریافت نرم تر، POST/PUT سخت تر).

ترکیب: کلید اصلی + «ضریب ریسک» (حساب جدید، TOR/پروکسی، ریسک بازپرداخت بالا).

5) کنترل کننده سازگار با SLO

• Triggers: «p95 latency↑»، «5xx↑»، «len↑ صف»، «اشباع CPU/IO».
• اقدامات: نرخ پایین تر/پشت سر هم, فعال کردن outlier-ejection, کاهش «گران» مسیرهای, تنزل موقت (بدون زمینه های سنگین/تجمع).
• بازگشت: گام به گام (25 → 50 → 100٪) هنگام عادی سازی سیگنال های N فواصل متوالی.

6) ادغام معماری

API دروازه (لبه): نرخ اولیه/سهمیه, جغرافیایی/ASN, HMAC/JWT اعتبار, 429/' تلاش مجدد پس از '.
BFF/سرویس مش: محدودیت های نازک در هر مسیر/در هر مستاجر، محدودیت های همزمان، قطع کننده مدار به بالادست.
در داخل سرویس: semaphores برای عملیات سنگین، backprescher در صف، «استخر کار» با اندازه محدود.
Webhooks: یک نقطه پایانی ورودی جداگانه با سطل نشتی و بافر retray.

7) تنظیمات (قطعات)

yaml plugins:
- name: rate-limiting config:
policy: local minute: 600    # 10 rps limit_by: consumer fault_tolerant: true
- name: response-ratelimiting config:
limits:
heavy: { minute: 60 }

yaml circuit_breakers:
thresholds: { max_connections: 1000, max_requests: 800 }
outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s http_filters:
- name: envoy. filters. http. local_ratelimit typed_config:
token_bucket: { max_tokens: 100, tokens_per_fill: 100, fill_interval: 1s }
filter_enabled: { default_value: 100% }
filter_enforced: { default_value: 100% }

pseudo sema = Semaphore(MAX_ACTIVE_EXPORTS_PER_TENANT)
if! sema. tryAcquire(timeout=100ms) then return 429 with retry_after=rand(1..5)s process()
sema. release()

pseudo cost = sum(weight(field) cardinality(arg))
if cost > tenant. budget then reject(429,"query too expensive")

8) سیاست برای کانال های مختلف

استراحت کردن

GET - نرم تر، POST/PATCH/DELETE - سخت تر ؛ وضعیت/چک «idempointent» می تواند رد شود.
برای پرداخت: محدودیت در «auth/capture/refund» برای هر کاربر/مستاجر/BIN/کشور.

GraphQL

عمق/پیچیدگی کلاه، نمایش داده شد ادامه/لیست سفید، محدودیت در نام مستعار.

WebSocket/SSE

محدودیت فرکانس 'subscribe/unsubscribe'، محدودیت تعداد موضوعات، کنترل اندازه رویدادها و ارسال صف → زمانی که سرریز «policy _ disconnect».

صفحات وب

سطل نشتی در پذیرش، سهمیه هر فرستنده، صف نامه مرده، قطعی 2xx/429.

9) بازخورد مشتری

• 'تلاش مجدد-پس از: <ثانیه>'
• 'X-RateLimit-Limit/Remaining/Reset'
• برای سهمیه - 403 با کد «quota _ exceeded» و پیوند به ارتقاء برنامه.
• مستندات: محدودیت در صفحات OpenAPI/SDL + «استفاده منصفانه».

10) نظارت و داشبورد

• Hits limits: میزان. محدود کردن ضربه توسط کلید/مسیر/مستاجران.
• 429/503 доля, تاخیر p50/p95/p99, نرخ خطا, طول صف, مدارهای باز.
• عادلانه سهم: مستاجران بالا در مصرف، «آشکارساز قلدر».
• Webhooks: پذیرش/retrai، قطره نرخ، تاخیر متوسط.

• 429 بیش از 1-3٪ از کل RPS (بدون ربات).
• افزودنی محدود کننده p95 ≤ 5-10 میلی ثانیه در هر لبه.
• زمان بازیابی تخریب ≤ 10 دقیقه.

sql
SELECT ts::date d, tenant, route,
SUM(hits) AS limit_hits,
SUM(total) AS total_calls,
SUM(hits)::decimal/NULLIF(SUM(total),0) AS hit_rate
FROM ratelimit_stats
GROUP BY 1,2,3
ORDER BY d DESC, hit_rate DESC;

11) کتاب های حادثه

Retray storm (upstream fall): خاموش کردن جهانی، افزایش بازده، قطع کننده مدار باز، بازگشت «اشتباهات سریع» به جای وقفه.
حمله ربات/خراش دادن: کلاه سخت توسط IP/ASN/geo، چالش WAF/JS را فعال کنید، دایرکتوری ها/جستجو را محدود کنید.
اوج مسابقات/رویداد: به طور پیشگیرانه محدودیت خواندن را افزایش می دهد، «زمینه های گران قیمت» را پایین می آورد، حافظه پنهان/غیرفعال سازی را فعال می کند.
اضافه شده webhooks از PSP: سطل موقت نشت، اولویت بندی انواع بحرانی، گسترش مرده نامه و retray.

12) تست و UAT

بار: نردبان RPS، مهره × 10 نرمال.
عدالت: تقلید از 1 مستاجر «حریص» - بیش از X٪ از بودجه جهانی.
تخریب: انطباق SLO محدودیت ها را کاهش می دهد و p95 را در راهرو نگه می دارد.
موارد مرزی: تغییر پنجره (min → chas)، لرزش ساعت (انحراف ساعت)، پوسته پوسته شدن Redis/کلید sharding.
قرارداد: 429 و هدر Retry-After وجود دارد، SDK به درستی خاموش است.

13) ذخیره سازی برای محدودیت

در حافظه برای محدودیت های محلی (خوشه های کوچک).
Redis/Memcached for distributed (اسکریپت های Lua برای اتمی بودن).
کلید های Sharding توسط هش ؛ TTL زیر پنجره ها ؛ متریک پشتیبان گیری برای از دست دادن کش.
Idempotency: محدود کننده نباید تماس های مکرر idempotent را قطع کند (حسابداری با کلید درخواست).

14) حکومت

کاتالوگ محدودیت: چه کسی مالک است، چه کلید/آستانه/جیره بندی شده است.
پرچم های ویژگی برای سوئیچ های سریع (حالت بحران).
سیاست های نسخه بندی و فرآیند RFC برای تغییر در سهمیه های قراردادی.
آزمایش A/B در انتخاب آستانه بهینه.

15) ضد الگوهای

جهانی یک حد «برای همه API ها».
فقط پنجرههای ثابت → پرشهای «لبه».
محدودیت بدون بازخورد (بدون «Retry-After »/هدر).
زمان خاموش به جای سریع 429/503.
فقدان سهم عادلانه هر مستاجر - یک مشتری بقیه را خفه می کند.
بدون حفاظت جستجوی GraphQL/پیچیدگی.
صفر در همزمان گارد → DB/PSP «جارو برقی».

16) ورق تقلب کوتاه از انتخاب

پیش فرض سطل توکن (نرخ + پشت سر هم) برای هر مستاجر + مسیر است.
سهمیه بندی بر اساس پول/گزارش: پنجره کشویی روز/ماه.
عملیات سنگین: محدودیت های همزمان + صف.

GraphQL/поиск: بودجه پیچیدگی + پرس و جوهای مداوم

WS/webhooks: سطل نشتی + فشار پشتی.
Кризис: dynamic throttling + circuit-breaker + degrade.

خلاصه

کنترل بار یک رشته چند سطحی است: الگوریتم های صحیح (سطل/پنجره/رقابت)، کلیدهای حد منصفانه، سازگاری SLO و بازخورد شفاف. با دوختن محدودیت ها به دروازه/مش/خدمات، مسلح کردن GraphQL/WS/webhooks با سیاست های نمایه و اتصال قابلیت مشاهده با playbooks، شما رویدادهای پیک و شکست های دیگران را به موقعیت های کنترل شده تبدیل می کنید - بدون سقوط، پرداخت های مختل شده و کاهش تبدیل.