Rate limits და კვოტები

Rate limits და კვოტები არის ფუნდამენტური მენეჯმენტის მექანიკა მთლიანი რესურსებისთვის: CPU, ქსელი, BD, რიგები, გარე API. მიზანია სამართლიანობა, SLO- ს პროგნოზირება და ციმციმებისგან დაცვა, ბოროტად გამოყენება და „neighbor neighbor“.

1) ძირითადი ცნებები

Rate limit - მოთხოვნის/ოპერაციების ინტენსივობის შეზღუდვა (req/s, msg/min, bit/s).
Burst არის დასაშვები მოკლევადიანი აწევა საშუალო დონის თავზე.
É ta - მოცულობის ზღვარი დროის ფანჯარისთვის (დოკუმენტები/დღე, GB/თვე).
Concurrency cap - ერთდროული ოპერაციების შეზღუდვა (ერთდროული მოთხოვნა/ჯობი).
Scope - გამოყენების სფერო: per-tenant, per-user, per-token, per-endpoint, per-IP, per-region, per-feature.

2) შეზღუდული ალგორითმები

2. 1 ტოკენ ბუკეტი (ბუკეტი ნიშნით)

პარამეტრები: 'rate' (ნიშნები/წმ), 'burst' (თაიგულის ზომა).
იგი მუშაობს როგორც „სესხი“: დაგროვილი ნიშნები საშუალებას იძლევა მოკლე მწვერვალები.
შესაფერისია გარე API და მომხმარებლის მოთხოვნებისთვის.

2. 2 Leaky Bucket (ვედრო)

შეუფერხებლად „ასხივებს“ ნაკადს მუდმივი სიჩქარით.
კარგია მგრძნობიარე ქუდების ტრაფიკის გასწორება.

2. 3 Fixed/Sliding Window

ფანჯრის ფანჯარა: მარტივი, მაგრამ დაუცველი „ფანჯრის გადართვა“.
Sliding window: უფრო ზუსტი, მაგრამ უფრო ძვირი, ვიდრე გამოთვლითი.

2. 4 GCRA (Generic Cell Rate Algorithm)

ტოკენ ბუკეტის ეკვივალენტი ჩამოსვლის ვირტუალური დროის თვალსაზრისით.
განაწილებული ლიმიტერების ზუსტი და სტაბილური (ნაკლებად კონფლიქტური სახელმწიფო).

2. 5 Concurrency Limits

ერთდროულად შესრულებული ოპერაციების შეზღუდვა.
იგი იცავს ნაკადის/ნაერთების ტყვიების ამოწურვისგან და „head-of-line blocking“.

3) სად უნდა გამოვიყენოთ ლიმიტები

საზღვარზე (L7/API კარიბჭე): მთავარი ბარიერი, სწრაფი უარი (429/503), იაფი შემოწმებები.
სერვისების შიგნით: დამატებითი caps მძიმე ოპერაციებისთვის (ექსპორტი, მოხსენებები, ტრანსფორმაციები).
გარე სისტემების გასასვლელში: ინდივიდუალური ლიმიტები მესამე მხარის ქვეშ (ანტი-პენალტი).
რიგებში/workers: fairness საერთო ტყვიები.

4) Spups და პრიორიტეტები (multi-tenant)

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.
Priority: VIP/Enterprise იღებს უფრო დიდ „burst“ და წონას, მაგრამ არ არღვევს საერთო SLO.
ლიმიტების შემადგენლობა: საბოლოო დაშვება = 'min (გლობალური, რეგიონალური, ჩრდილოვანი, მომხმარებელი, ენდოპოინტი) ".

5) კვოტები მოცულობით

ყოველდღიური/ყოველთვიური კვოტები: დოკუმენტები/დღე, GB/თვე, შეტყობინებები/წთ

რბილი/მკაცრი ბარიერები: გაფრთხილებები (80/90%) და „მძიმე გაჩერება“.
Roll-up: აღრიცხვა ობიექტებზე (ცხრილები, ფაილები, მოვლენები) და „ამოღება“ ბილინგზე.

6) განაწილებული ლიმიტები

მოთხოვნები: დაბალი შეფერხება, თანმიმდევრულობა, უარის თქმის წინააღმდეგობა, ჰორიზონტალური სკალირება.

ადგილობრივი + probabilistic sync: ადგილობრივი shard თაიგულები + პერიოდული სინქრონიზაცია.
Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).
Sharding: limit კლავიშები: {scope}: {id}: {window} "ერთგვაროვანი განაწილებით.
Clock skew: შეინახეთ „ჭეშმარიტება“ ლიმიტის სერვერზე და არა კლიენტებში.
Idempotence: „ოპერაციების“ გასაღებები ამცირებს ყალბ ჩამოწერებს.

7) ანტი აბიუსი და დაცვა

Per-IP + Device fingerprint საზოგადოებრივი ენდოინებისთვის.
Proof-of-Work/CAPTCHA ანომალიების დროს.
Slowdown (throttling) ნაცვლად სრული უარის თქმის ნაცვლად, როდესაც UX უფრო მნიშვნელოვანია (საძიებო მოთხოვნები).
Adaptive limits: ინციდენტების/ძვირადღირებული დეგრადაციის დროს ბარიერების დინამიური ვარდნა.

8) კლიენტის ქცევა და ოქმი

კოდი: '429 Too Many Requests' (კოდი), '403' (გადალახა კვოტა/გეგმა), '503' (დამცავი დეგრადაცია).

• 'Retry-After: "- როდესაც ისევ სცადეთ.

• `RateLimit-Limit: ;w=`
• `RateLimit-Remaining: `
• `RateLimit-Reset: `
• Backoff: ექსპონენციალური + ჯიტერი (სრული ჯიტერი, equal jitter).
• Idempotence: სათაური 'Idempotency-Key "და უსაფრთხო ოპერაციების განმეორება.
• დრო და გაუქმება: სწორად შეაჩერეთ შეჩერებული მოთხოვნები ისე, რომ არ „დაიჭიროთ“ ლიმიტები.

9) დაკვირვება და ტესტირება

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).
მეტრიკა: გამტარუნარიანობა, წარუმატებლობის წილი 429/403/503, ლიმიტერის p95/p99 შეფერხება, hit ratio kash გასაღებები, განაწილება გეგმების მიხედვით.
აუდიტის ლოგოები: ბლოკის მიზეზები, ტოპ „ხმაურიანი“ გასაღებები.
ტესტები: დატვირთული პროფილები „დალია/ბურსტი/პლატო“, ქაოსი - Redis/shard- ის უკმარისობა, საათების რასინქრონიზაცია.

10) ინტეგრაცია ბილინგთან

Usage მრიცხველები იკრიბებიან საზღვარზე, გაერთიანებულია ბრძოლებით (ყოველი N წუთი) იდემპოტენტურობით.
გეგმების შეჯამება: გადატვირთვა, გადატვირთვა ან გეგმის დროებითი ზრდა.
შეუსაბამობები: თავაზიანი ინვოისის შერჩევა; ალერტები დელტაზე.

11) Fairness შიგნით (რიგები, ვორკერები)

შაბათ Fair Queuing/DRR: სლოტების განაწილება მოიჯარეებს შორის გეგმის წონის მიხედვით.
Per-tenant worker pools: მკაცრი იზოლაცია VIP/ხმაურიანი.
Admission Control: უკმარისობა, თუ კვოტები ამოწურულია; რიგები არ იშლება.
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 კარიბჭე: TLS - ამოიღეთ კონტექსტი (tenant/plan) - შეამოწმეთ limites/კვოტები და განათავსეთ სათაურები RateLimit- ის ლოგო/ტრეისი.
2. Policy Engine: პრიორიტეტული წესები (VIP), ადაპტირებული ბარიერები.
3. Limiter Store: Redis/KeyDB (atomic ops, LUA), კლავიშების შარდვა, რეპლიკაცია.
4. მომსახურება: მეორადი ლიმიტი და caps მძიმე ოპერაციებისთვის; იდემპოტენტურობა; ხაზები WFQ/DRR.
5. Usage/Billing: კოლექცია, აგრეგაცია, ინვოისი, ალერტები.
6. Observability: მეტრიკა/logs/trages ერთად thags, dashbords per-tenant.

14) ჩეკის სია გაყიდვამდე

• განსაზღვრულია ლიმიტების სკოპები (tenant/user/token/endpoint/IP) და მათი იერარქია.
• შეირჩა ალგორითმი (Token Bucket/GCRA) და 'rate/burst' პარამეტრები.
• განხორციელდა concurrence caps და admission control მძიმე ოპერაციებისთვის.
• შედის სათაურები 'RateLimit-' და 'Retry-After'; მომხმარებლები მხარს უჭერენ backoff + jitter- ს.
• ლიმიტერი განაწილებულია და გამძლეა უარი თქვას (შარდები, რეპლიკაცია, დეგრადაცია).
• მომხმარებელთა კოლექცია იდემპოტენტურია; ლიგატი ბილინგით, ალერტები გადატვირთვისთვის.
• დაკვირვება: მეტრიკა/ტრეისი/ლოგები ჭდეებით, ტოპ „ხმაურიანი“ გასაღებები, ალერტერი.
• ტესტები: ბურსები, „დალია“, ნაკადის უკმარისობა, წებოვანი ციკლი, ცივი დასაწყისი.
• დოკუმენტაცია მომხმარებლებისთვის: გეგმების ლიმიტები, 429/Retry-After მაგალითები, ჭიდაობის საუკეთესო პრაქტივები.
• გამონაკლისების პოლიტიკა: როგორ დროებით გაზარდოს ლიმიტები და როდის.

15) ტიპიური შეცდომები

გლობალური ლიმიტი per-tenant/per-endpoint გარეშე - „noisy neighbor“ არღვევს ყველა SLO- ს.
'burst- ის არარსებობა: UX განიცდის მოკლე ციმციმებს.
მხოლოდ ფიქსირებული ფანჯრის გამოყენება არის „ორმაგი დარტყმა ფანჯრის საზღვარზე“.
არ არსებობს idempotence და retrais ერთად ჯიტერი და გამეორების ქარიშხალი.
ლიმიტები მხოლოდ საზღვარზე, სერვისებში/რიგებში არ არის შიდა „საცობები“.
პასუხებში ლიმიტების შეუსაბამობა (არა 'Retry-After', 'RateLimit-') არ არის ადაპტირებული მომხმარებლებისთვის.
ლიმიტერის მდგომარეობის შენახვა OLTP მონაცემთა ბაზაში - მაღალი ლატენტობა და „ცხელი“ ბლოკირება.

16) სტრატეგიის სწრაფი შერჩევა

საზოგადოებრივი API მწვერვალებით: Token Bucket + burst ', RateLimit- სათაურები, CDN/edge ქეში.
შიდა მძიმე ჯობი: concurrence caps + WFQ/DRR, admission Control.
ინტეგრაცია მესამე მხარესთან: ცალკეული გასასვლელი ლიმიტები, ბუფერიზაცია/რეწვა.
SaaS მულტფილმის ტენანტი: ლიმიტის იერარქია (global - tenant - user - endpoint), VIP პრიორიტეტიზაცია, კვოტები თვის განმავლობაში.

დასკვნა

კარგი ზღვარი და კვოტები არის სისტემური კონტრაქტი პლატფორმასა და კლიენტს შორის: რესურსების გულწრფელი წილი, ვარდნის წინააღმდეგობა, პროგნოზირებადი SLO და გამჭვირვალე ბილინგი. დააკავშირეთ ალგორითმები (Token/GCRA + concurrency caps), შემოიღეთ სკოპის იერარქია, მიეცით გასაგები სათაურები და მეტრიკები და რეგულარულად შეამოწმეთ სქემები რეალური ტრაფიკის პროფილების ქვეშ - ასე რომ, პლატფორმა დარჩება სტაბილური, თუნდაც დატვირთვის აგრესიული ზრდა.