rate limiter '- ის დიზაინი

1) რატომ უნდა მოვიქცეთ

Rate limiting იცავს API- ს წვდომასა და ეკონომიკას: ის აჩერებს ფლუდებს, მიმღების „ბორტებს“, საკრედიტო ნაკადს, იცავს ძვირადღირებულ ოპერაციებს (ფულადი გარიგებები, ანგარიშების წარმოება), ამცირებს დატვირთვას დამოკიდებულ სისტემებზე (BD/პროვაიდერები). კარგი დიზაინი იძლევა სამართლიანობას, ლატენტობის პროგნოზირებას და მკაფიო SLO- ს.

ძირითადი მიზნები

RPS- ის სტაბილურობა და უკანა მხარის დაცვა გადატვირთვისგან.
კონტროლირებადი „ელასტიურობა“.
მომხმარებელთა დიფერენცირება (პრო-მომხმარებელი/პრო-ორგანიზაცია/პერ-გასაღები/პერ-IP/პერ-რეგიონი).
ღირებულების მოდელი: სხვადასხვა „ფასები“ სხვადასხვა ოპერაციებისთვის.

2) ლიმიტების ტიპები

RPS ლიმიტები: მოთხოვნა წამში/წუთში.
კვოტები: მთლიანი ბიუჯეტი პერიოდში (დღე/თვე).
კონკურენცია: ერთდროული ოპერაციები.
სიჩქარე/ზოლები: ბაიტი/წმ (დატვირთვა/გადმოტვირთვა).
შეჩერებული ლიმიტები: სირთულის მოთხოვნის „ღირებულება“ (მაგალითად, GraphQL კომპლექტი, batch ზომა).
ადაპტირებული: გამკაცრდა ანომალიების დროს (საეჭვო მოქმედება/შეცდომები 401/403/5xx).

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

3. 1 Fixed window counter

უბრალოდ: ინტერვალის მრიცხველი (მაგალითად, 100 r/min).
დადებითი: მინიმალური ღირებულება. უარყოფითი: „მარგინალური ბერსტი“ ფანჯრის საზღვრებზე.

როდის: ადმირალების პანელები, დაბალი სიზუსტე, დაბალი ღირებულება.

3. 2 Sliding window (log / counter)

ჟურნალი: ინახავს ბოლო მოთხოვნების დროის ეტიკეტებს, ზუსტი, მეხსიერების გზებს.
ქვეყანა: ორი მეზობელი ფანჯრის საშუალო, სიზუსტისა და ფასის კომპრომისი.

როდის: საშუალო ტრაფიკის საზოგადოებრივი API, საჭიროა გლუვი რთული მათემატიკის გარეშე.

3. 3 Token bucket

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

როდის: თითქმის ყოველთვის RPS- სთვის, თუ საჭიროა „ვოლიერები“ „ბ“ ფარგლებში.

3. 4 Leaky bucket (drip)

ხაზი, საიდანაც „გაჟღენთილია“ ფიქსირებული სიჩქარით.
დადებითი: თანაბარი გამომავალი ნაკადი. უარყოფითი მხარეები: მეტი შეფერხება.

როდის: გარუჯვა გარე „მყიფე“ პროვაიდერების მიმართ.

3. 5 GCRA (Generalized Cell Rate Algorithm)

• 'TAT _ next = max (TAT _ current, ახლა) + 1/r', მოთხოვნა მიიღება, თუ 'now <= TAT _ current + burst/r'.
• დადებითი: მკაცრი, ზუსტი, ცოტა მეხსიერება (TAT- ის გასაღები). უარყოფითი მხარეები: გაგება უფრო რთულია.

როდის: თქვენ გჭირდებათ მკაცრი კონტროლი და გლუვი, განაწილებული ლიმიტები.

3. 6 კონკურენტული სემფორები

აქტიური ოპერაციების მრიცხველი; შესასვლელი - თუ არის „ბილეთები“; გამოსავალი - განთავისუფლება.
როდის: გრძელი რუნინგის ოპერაცია, ნაკადები, WebSocket, ჩატვირთვა.

4) ლიმიტის გასაღების მოდელი

• `client_id`/`api_key`/`user_id`/`org_id`
• 'IP/ASN/geo' (უხეში დაცვა)
• 'endpoint/method' (ცხელი მარშრუტები)
• 'scope/plan/tier' (მონეტიზაცია)
• 'idempotency _ key' (write ოპერაციები)
• გამოიყენეთ იერარქია: ჯერ მკაცრი პრეს-გასაღები, შემდეგ პრეს ორგანიზაცია, შემდეგ გლობალური.

5) მოთხოვნის წონა (კოდი მოდელი)

• GraphQL: სირთულე მინდვრებში × სიღრმე.
• REST: პასუხის/მოთხოვნის ზომა, ოპერაციის ტიპი (read = 1, write = 3, ანგარიში = 10).
• Batch: `cost = min(n, cap)`.
• ჩვენ ვაწარმოებთ ნიშნებს და არა „მოთხოვნებს“: 'budget - = cost (q)'.

6) განაწილებული განხორციელება

6. 1 საცავი

In-process: ულტრა-სწრაფად, მაგრამ არა ზოგადი ლიმიტი (შესაფერისია ადგილობრივი „რბილი“ შეზღუდვებისთვის).
Redis: დე ფაქტო სტანდარტი. INCR/EXPIRE, Lua სკრიპტები (ატომურობა), ZSET sliding window, გასაღებები TTL.
Envoy/NGINX/Kong/Traefik: ჩაშენებული ფილტრები; მოსახერხებელია პერიმეტრისთვის.
Service Mesh: ადგილობრივი limites sidecar + გლობალური სინქრონიზაცია.

6. 2 ატომარობა და რბოლა

Lua in Redis: შემოწმება და კვალი ერთი ნაბიჯით.
GCRA: შეინახეთ ერთი TAT CAS/სკრიპტით.
საათის კოორდინაცია: NTP, ერთფეროვანი ტაიმერები.
Sharding: კომპოზიციური ჰაში; მოერიდეთ „ცხელ“ შარდს.

6. 3 განაწილება

ადგილობრივი ლიმიტები რეგიონულ მტევნებზე + ზედა გლობალური (coarse).
CRDT/რეპლიკაცია - ფრთხილად (შეფერხებები, ორმაგი მოხმარება). სასურველია რეგიონალური ლიმიტები ზღვარით.

7) პოლიტიკოსები და პრიორიტეტები

გეგმები: უფასო/Pro/Enterprise სხვადასხვა 'r', 'b', კვოტებით.
პრიორიტეტები: „ძვირადღირებული“ მარშრუტები იღებენ უფრო დაბალ ზღვარს ან უფრო დიდ კოდს.
სიები: ალოუ სია ინტეგრაციისთვის, დენის ASN/მარიონეტული/TOR.
ესკალაცია: განმეორებით ჭარბი რაოდენობით - ჩვენ ვამცირებთ ზღვარს, შემოიღეთ proof-of-work/challengi.

8) ჩამორთმევის მაგალითები

8. 1 Envoy (HTTP limit filter, ფსევდო)

yaml rate_limit:
domain: public-api descriptors:
- key: api_key rate_limit:
unit: second requests_per_unit: 50 burst: 100
- key: api_key value: payments. write rate_limit:
unit: second requests_per_unit: 5 burst: 10

8. 2 NGINX (lua + Redis, ფსევდო)

nginx lua_shared_dict limits 10m;

location /api/ {
access_by_lua_block {
local key = ngx. var. arg_apikey.. ":".. ngx. var. request_method.. ":".. ngx. var. uri
-- token bucket in Redis (evalsha)
local allowed, retry_after = ratelimit_allow(key, 50, 100) -- r=50/s, b=100 if not allowed then ngx. header["Retry-After"] = retry_after return ngx. exit(429)
end
}
proxy_pass http://backend;
}

8. 3 კონკურენტული ლიმიტები (ფსევდო კოდი)

pseudo on_request_start(key):
if redis. incr_with_ttl("sem:" + key, ttl=60) > MAX_CONCURRENCY:
redis. decr("sem:" + key); reject(429)
on_request_finish(key):
redis. decr("sem:" + key)

8. 4 GCRA (ფსევდო კოდი)

pseudo params: r tokens/sec, burst b tat = redis. get(key) or now allowed_time = tat - (b / r)
if now < allowed_time: reject(429, retry_after = allowed_time - now)
tat_next = max(tat, now) + 1/r redis. set(key, tat_next, ttl = ceil(b/r) + safety)

9) ინტეგრაცია retrais, taimauts და circuit breaker

Retry-budget: შეზღუდეთ ჭიდაობის წილი ძირითადი ტრაფიკის X% -მდე.
Jitter: backoff- ზე ყოველთვის დაამატეთ ჯიტერი - ამცირებს სინქრონიზებულ ციმციმებს.
Circuit breaker: მაღალი შეცდომით ('5xx', timeouts) შეამცირეთ ლიმიტები ან გადაიტანეთ მარშრუტების ნაწილი „read-only“ - ში.
Hedging: სისუფთავე; გაითვალისწინეთ cost ისე, რომ არ გაორმაგდეს ბიუჯეტის მოხმარება.

10) დაკვირვება და კონტროლი

Метрики: `rps_allowed`, `rps_blocked`, `429_rate`, `retry_after_avg`, `burst_used`, `quota_remaining`, `active_concurrency`.
ეტიკეტები: ლიმიტის გასაღები, რეგიონი, ენდოინტო, გეგმა.
გადაწყვეტილებების ლოგიკა (მოდულირებული): უარის თქმის მიზეზი, მიმდინარე მრიცხველები, TTL გასაღები.
დაშბორდები: თერმული ბარათები კლავიშებზე/ენდოინტებზე, „ცხელი“ მომხმარებლები.
ალერტები: კრიტიკულ მარშრუტებზე 429> 2-5% ზრდა, კვოტების ხშირი „ამოწურვა“, შარდების დისბალანსი.

11) ტესტირება და დამოწმება

პოლიტიკოსის საკონტრაქტო ტესტები (ცხრილები „ზოგჯერ“).
დატვირთვა: ბუჩქები (x10 რ), გრძელი პლატოები, „ბინძური“ ნიმუშები (slow-POST, გრძელი ნაერთები).
Chaos ტრეფიკი: არათანაბარი ნაკადები, clock drift, Redis/mesh- ის დაკარგვა.
A/B ჩართვა: ლიმიტების რულეტი, shadow გადაწყვეტილებები (ლოგიკური, მაგრამ არა ბლოკირება) ჩართვამდე.

12) Edge შემთხვევები და დახვეწილობები

Clock skew: გამოიყენეთ 'ახლა ()' ერთი წყაროდან (სერვერიდან) და არა კლიენტის სათაურებიდან.
Idempotency-Key: write- ისთვის - ამცირებს ამპლიტაციას გამოსხივების დროს.
Batch ოპერაციები: შეუზღუდავი ზომით batch და მთლიანი cost.
Long-poll/WebSocket: შეზღუდეთ არხების/ხელმოწერების რაოდენობა და ხანგრძლივობა.
ცივი სტარტი: მრიცხველების „თბილი“ დაწყება/წინასწარ დატვირთვა; წინააღმდეგ შემთხვევაში, ყალბი 429.
გამოთვლილად ძვირადღირებული მოთხოვნები: შეზღუდეთ ბიზნესის ლოგიკის შესრულებამდე.
TTL- ის საზღვრები: TTL გასაღებები უნდა მოიცავდეს ფანჯარას + მარაგს.

13) ანტიბიოტიკური ესკალაცია

ნაბიჯები: გაფრთხილება - 429 + 'Retry-After' - challenge (capcha/თავსატეხი) - დროებითი ბლოკი.
სიგნალები: მოწყობილობები-fingerprint, კურსორის/ტაიმინგის ქცევა, TOR/მარიონეტული/ჰოსტინგი.
პოლიტიკოსები უნდა იყვნენ დეტერმინისტები და რეპროდუცირებულნი იქნებიან გაფართოებისთვის.

14) უსაფრთხოება და შესაბამისობა

Deny-by-default კრიტიკულ მარშრუტებზე (write/ფინანსები).
აუდიტი: შეინახეთ გადაწყვეტილებები მარეგულირებელი შემთხვევებისა და ინციდენტების ანალიზისთვის.
PII: ლიმიტების გასაღებებმა არ უნდა გაამჟღავნოს პერსონალური მონაცემები ლოგებში.

15) მზადყოფნის სიის სია

• განსაზღვრულია ლიმიტების გასაღებები და cost მოდელი.
• შეირჩა ალგორითმი (ტოკენის ბუკეტი/GCRA) და საცავი (Redis/კარიბჭე).
• პოლიტიკოსები მომხმარებლებისთვის + გლობალური „დაუკრავენ“.
• კონკურენტული ლიმიტები გრძელი ოპერაციებისთვის.
• Retry-budget, backoff ერთად jitter, ინტეგრაცია circuit breaker- თან.
• Dashbords/alerty, გადაწყვეტილებების მოდულირებული ლოგოები.
• კანარი ჩართვა და shadow რეჟიმი.
• ბორტების ტესტები, გრძელი პლატოები, Redis ჩავარდნები, clock skew.
• დოკუმენტაცია მომხმარებლებისთვის: კოდი 429, 'Retry-After', ექსპონენციალური backoff- ის მაგალითები.

16) TL; DR

გამოიყენეთ token bucket ან GCRA Redis/Redis/Redis, შეიმუშავეთ ლიმიტების გასაღებები და მოთხოვნების ღირებულება, დაამატეთ კონკურენტული სემფორები გრძელი ოპერაციებისთვის, ინტეგრირდით retry-budget და circuit breaker- ით, Shadow/shadow- ის საშუალებით და აუცილებლად შეამოწმეთ ბუჩქები და საცავის უკმარისობა.