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:
`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), ներկայացրեք ոսկորների հիերարխիա, տվեք հասկանալի վերնագրեր և չափումներ, և պարբերաբար ստուգեք սխեմաները իրական պրոֆիլների տակ, այնպես որ պլատֆորմը կմնա կայուն նույնիսկ բեռի ագրեսիվ աճի դեպքում։