GH GambleHub

Rate limits և քվոտաներ

Rate limits-ը և քվոտաները ընդհանուր ռեսուրսների հարցման հիմնական մեխանիկա են 'CPU, ցանցը, BD, գծերը, արտաքին API-ները։ Նպատակը արդարությունն է (fairness), SLO կանխատեսելիությունը և պաշտպանությունը աճը, չարաշահումները և «neighbor» -ը։


1) Հիմնական հասկացությունները

Rate limit-ը հարցումների/վիրահատությունների ինտենսիվության սահմանափակումն է (req/s, www.g/min, բայթ/վայրկյան)։

Burst-ը թույլատրելի կարճ աճն է միջին rate-ի վերևում։

Դելտան ժամանակի պատուհանի սահմանափակում է (փաստաթղթեր/օր, ԳԲ/ամիս)։

Concurrency cap-ը միաժամանակ վիրահատությունների սահմանափակումն է (միաժամանակ հարցումներ/ջոբներ)։

Scoase-ը օգտագործման ոլորտն է ՝ per-tenae, per-user, per-token, per-endpoint, per-IP, per-region, per-feature։


2) Սահմանման ալգորիթմներ

2. 1 Token Bucket (Wedro Token)

Պարամետրերը ՝ «rate» (toxen/վայրկյան), «burst» (դույլերի չափը)։

Աշխատում է որպես «վարկ», կուտակված հոսանքները թույլ են տալիս կարճ պիկի։

Հարմար է արտաքին API-ի և օգտագործողների համար։

2. 2 Leaky Bucket (հոսող դույլ)

Սահուն «թափահարում» հոսքը անընդհատ արագությամբ։

Լավ է բացելու համար զգայուն backend 'am։

2. 3 Fixed/Sliding Window

Fixed-ը պարզ է, բայց խոցելի է «պատուհանի տեղափոխման» համար։

Sliding-ը ավելի ճշգրիտ է, բայց ավելի թանկ է հաշվարկային։

2. 4 GCRA (Generic Cell Rate Algorithm)

Token Bucket-ի համարժեքը վիրտուալ ժամանման ժամանակի տերմիններում։

Ճշգրիտ և ֆոսֆիլեն բաշխված լիմիտերների համար (ավելի քիչ կոնֆլիկտային state)։

2. 5 Concurrency Limits

Միաժամանակ կատարված վիրահատությունների սահմանափակումը։

Պաշտպանում է հոսքերի/շարժիչների գնդակների սպառումից և «head-of-blocking» -ից։


3) Որտե՞ ղ օգտագործել սահմանները

Սահմանին (L7/API-դարպաս) 'հիմնական խոչընդոտը, արագ հրաժարվելը (429/503), էժան ստուգումները։

Ծառայությունների ներսում 'ավելացված կապիտալ ծանր վիրահատությունների համար (օրինագծեր, հաշվետվություններ, փոխակերպումներ)։

Արտաքին համակարգերի ելքի վրա 'անհատական սահմաններ երրորդ կողմի տակ (anti-penalty)։

Հերթերի/գողերի վրա 'fairness ընդհանուր փամփուշտների։


4) Սկոպները և գերակայությունները (multi-tenae)

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.

Priority-a.ru: VIP/Enterprise ստանում են ավելի մեծ «burst» և քաշը, բայց չեն կոտրում ընդհանուր SLO-ը։

Mastlimits: Windows = 'min (գլոբալ, windows, tenant, օգտագործողի, endpoint) "։


5) Ծավալի քվոտաները

Ամենօրյա/ամսական քվոտաները ՝ փաստաթղթեր/օր, ԳԲ/ամիս, հաղորդագրություններ//

Փափուկ/կոշտ շեմեր 'զգուշացումներ (80/90%) և «կոշտ կանգառ»։

Roll-up: ստանդարտ (աղյուսակներ, ֆայլեր, իրադարձություններ) և «հեռացում» բիլինգում։


6) Բաշխված լիմիտերներ

Պահանջները ՝ ցածր ուշացում, ներդաշնակություն, նվազեցման դիմադրություն, հորիզոնական մեծացում։

Contal + probabilistic pronnc: Տեղական շարդի դույլերը + պարբերական համաժամեցումը։

Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).

Sharding: limit: w.co.co.com: w.id: wwww.com ', միատեսակ բաշխմամբ։

Clock skew: պահել «ճշմարտությունը» լիմիտերի սերվերի վրա, ոչ թե հաճախորդների վրա։

Idempotenty: «վիրահատությունների» բանալիները (Idempotency-Key) նվազեցնում են կեղծ դուրս գրումները։


7) Անտի Աբուզը և պաշտպանությունը

Per-IP + device fingerprint հանրային էնդպոինտների համար։

Proof-of-Work/CAPTCHA-ը անոմալիաների ժամանակ։

Slowdown (throttling) փոխարեն ամբողջովին հրաժարվելու փոխարեն, երբ UX-ը ավելի կարևոր է (որոնողական հուշումներ)։

Adaptive limits: շեմերի դինամիկ նվազեցում միջադեպերի/թանկ դեգրադացիաների ժամանակ։


8) Հաճախորդի վարքագիծը և արձանագրությունը

Շվեյցարիա ՝ «429 Too Many Reques.ru» (rate), «403» (ավելի քան քվոտան/պլանը), «503» (պաշտպանիչ քայքայումը)։

Պատասխանների վերնագրերը (best practice)

"Retry-After: , երբ նորից փորձել։

Ընտանիքը 'Rox Limit- "(IETF)։

`RateLimit-Limit: ;w=`

`RateLimit-Remaining: `

`RateLimit-Reset: `

Backoff: էքսպոնենցիալ + ջիտթեր (fultjitter, equal jitter)։

«Idempotency-Key» վերնագիրը և անվտանգ վիրահատությունների կրկնությունը։

Թայմ-աուտները և վերացումը 'ճիշտ ընդհատել հարցումները, որպեսզի չգրավեն սահմանները։


9) Դիտողությունն ու փորձարկումը

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).

Մետրիկները ՝ թողունակություն, 429/403/503, p95/p99 limiter, hit ratio kasha, պլանների բաշխում։

Լոգները նշում են, որ բլոկների պատճառները, լավագույն «աղմկոտ» լուծումները։

Թեստեր ՝ բեռի պրոֆիլներ «պիլ/բուրստ/սարահարթ», քաոսը 'Redis/shard-ի հրաժարումը, ժամացույցի վերակենդանացումը։


10) Ինտեգրումը բիլինգի հետ

Usage-հաշվիչները հավաքվում են սահմանին, համախմբվում են մարտերով (յուրաքանչյուր N րոպե) իդեմոտենտով։

Պլանների միջով անցնելը վերափոխումն է կամ պլանի ժամանակավոր բարձրացումը։

Տարբերություններ ՝ usage vs proice; ալերտները դելտա վրա։


11) Fairness ներսում (հերթեր, գողեր)

Weighted Fox Queuing/CSR-ը պլանի քաշի վարձողների միջև արցունքների բաշխումն է։

Per-tenault worker poo.ru: VIP/աղմկոտ կոշտ մեկուսացում։

Admission nol: հրաժարվելը մինչև կատարումը, եթե քվոտաները սպառված են։ հերթերը չեն փչանում։

Caps-ը 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. Edge/API-դարպասը 'TMS-ն խորհուրդ է տալիս ստանալ ենթատեքստը (tenault/plan) նախատեսվում է ստուգել limits/քվոտաները։

2. Policy Engine: առաջնահերթության կանոնները (VIP), հարմարվողական շեմերը։

3. Limiter Store: Redis/Kance DB (atomic ops, LUA), կոմպոզիցիայի շարդինգը, կրկնօրինակումը։

4. Իսպանիան 'հիբրիդային սահմանը և կապսը ծանր վիրահատությունների վրա։ գաղափարախոսություն; գծեր WFQ/WPR-ից։

5. Usage/Billing: Հավաքումը, ագրեգացիան, invois, ալտերտերը։

6. Observability: metrics/logs/treiss թեգերով, dashbords per-tenae։


14) Չեկ թուղթ մինչև վաճառելը

  • Սահմանվել են սահմանների սկոպները (tenault/user/token/endpoint/IP) և նրանց հիերարխիան։
  • Ընտրվել է ալգորիթմը (Token Bucket/GCRA) և պարամետրերը 'rate/burst "։
  • Իրականացվել են concurrency caps և admission prol ծանր վիրահատությունների համար։
  • Ներառված են «Rox Limit-» և «Retry-After» վերնագրերը։ հաճախորդները աջակցում են backoff + jitter։
  • Limiter-ը բաժանված է և դիմացկուն է կախվածություններին (շարդի, կրկնօրինակման, քայքայման)։
  • Usage-հավաքածու idempotenten; փոխպատվաստում, ալտերտեր փոխպատվաստման համար։
  • Դիտարկումը 'չափումներ/թրեյսներ/լույսեր, թեգերով, լավագույն «աղմկոտ» ոճերով, alerter' a։
  • Թեստեր ՝ փոթորիկներ, «խմել», սթորի մերժում, clock skew, սառը սկիզբ։
  • Հաճախորդների համար 'պլանների սահմաններ, 429/Retry-After, best practerraev օրինակներ։
  • Բացառությունների քաղաքականությունը 'ինչպես ժամանակավորապես բարձրացնել սահմանները և երբ։

15) Տիպիկ սխալներ

Համաշխարհային սահմանը առանց per-ten.ru/per-endpoint - «endisy neighbor» կոտրում է բոլոր SLO-ները։

"Burst ': UX-ը տառապում է կարճ արագությամբ։

Միայն ֆիքսված պատուհանի օգտագործումը բացատրում է «կրկնակի հարվածը պատուհանի սահմանին»։

Ոչ մի գաղափարախոսություն և ռենտգեն չկա ջիթերի հետ, ոչ էլ դետեկտորների փոթորիկ։

Լիմիտները միայն սահմանին, առանց caps ծառայություններում/հերթերում ներքին «խցանումները» են։

Limits-ի բացակայությունը պատասխաններում (ոչ «Retry-After», «Rance Limit-») ռուսական հաճախորդները չեն հարմարվում։

Limiter վիճակի պահպանումը BD OLTP-ում բարձր լատենտ և «տաք» արգելափակումը։


16) Ռազմավարության արագ ընտրություն

Հանրային API-ը գագաթներով 'Token Bucket + մեծ «burst», Raw Limit- վերնագրեր, CDN/edge kash։

Ներքին ծանր ջոբները ՝ concurrency caps + WFQ/MSR, admission corl։

Երրորդ կողմերի հետ 'առանձին սահմաններ ելքի, բուֆերիզացիայի/ռեգրայի համար։

Multi-tenant SaaS: Limits-ի հիերարխիա (global prodenae endpoint), VIP գերակայություն, ամիսների քվոտաներ։


Եզրակացություն

Լավ rate limits և քվոտաները համակարգային պայմանագիր են պլատֆորմի և հաճախորդի միջև 'ռեսուրսների ազնիվ մասը, աճի դիմադրությունը, կանխատեսելի SLO և թափանցիկ բիլինգ։ Ներմուծեք ալգորիթմներ (Token/GCRA + concurrency caps), ներկայացրեք ոսկորների հիերարխիա, տվեք հասկանալի վերնագրեր և չափումներ, և պարբերաբար ստուգեք սխեմաները իրական պրոֆիլների տակ, այնպես որ պլատֆորմը կմնա կայուն նույնիսկ բեռի ագրեսիվ աճի դեպքում։

Contact

Կապ հաստատեք մեզ հետ

Կապ հաստատեք մեզ հետ ցանկացած հարցի կամ աջակցության համար։Մենք միշտ պատրաստ ենք օգնել։

Սկսել ինտեգրացիան

Email-ը՝ պարտադիր է։ Telegram կամ WhatsApp — ըստ ցանկության։

Ձեր անունը ըստ ցանկության
Email ըստ ցանկության
Թեմա ըստ ցանկության
Նամակի բովանդակություն ըստ ցանկության
Telegram ըստ ցանկության
@
Եթե նշեք Telegram — մենք կպատասխանենք նաև այնտեղ՝ Email-ի дополнение-ով։
WhatsApp ըստ ցանկության
Ձևաչափ՝ երկրի կոդ և համար (օրինակ՝ +374XXXXXXXXX)։

Սեղմելով կոճակը՝ դուք համաձայնում եք տվյալների մշակման հետ։