Limity stawek i kwoty

Limity stawek i kwoty są podstawową mechaniką zarządzania popytem na wspólne zasoby: procesor, sieć, baza danych, kolejki, zewnętrzne API. Celem jest uczciwość, przewidywalność SLO i ochrona przed wybuchami, nadużyciami i „hałaśliwym sąsiadem”.

1) Podstawowe pojęcia

Limit szybkości - ograniczenie intensywności żądań/operacji (req/s, msg/min, bajty/sec).
Wybuch - dopuszczalny krótkoterminowy wybuch powyżej średniej stawki.
Kontyngent - limit objętości dla każdego okna czasowego (dokumenty/dzień, GB/miesiąc).
Ograniczenie współistnienia - ograniczenie jednoczesnych operacji (jednoczesne żądania/zadania).
Zakres - zakres: per-najemca, per-user, per-token, per-endpoint, per-IP, per-region, per-feature.

2) Ograniczenie algorytmów

2. 1 wiadro Token

Parametry: 'szybkość' (żetony/s), 'burst' (rozmiar wiadra).
Działa jak „kredyt”: nagromadzone żetony pozwalają na krótkie szczyty.
Nadaje się do zewnętrznych interfejsów API i żądań użytkowników.

2. 2 Nieszczelne wiadro

Płynnie „krwawi” przepływ ze stałą prędkością.
Dobry do wygładzania ruchu do wrażliwych pleców.

2. 3 Okno stałe/przesuwne

Okno stałe: proste, ale podatne na „przełączanie okien”.
Okno przesuwne: dokładniejsze, ale droższe obliczeniowo.

2. 4 GCRA (generyczny algorytm szybkości komórek)

Token Bucket równoważne pod względem wirtualnego czasu przyjazdu.
Dokładne i stabilne dla ograniczników rozproszonych (stan mniej sprzeczny).

2. 5 Granice równoczesności

Ograniczanie jednoczesnych operacji.
Chroni przed wyczerpaniem puli gwintu/połączenia i blokowaniem głowicy.

3) Gdzie stosować limity

Na granicy (brama L7/API): główna bariera, szybka awaria (429/503), tanie kontrole.
Usługi wewnętrzne: dodatkowe pułapy dla operacji ciężkich (eksport, raporty, przekształcenia).
Na wyjściu do systemów zewnętrznych: indywidualne limity dla osób trzecich (anty-kary).
W sprawie kolejek/pracowników: uczciwość do wspólnych basenów.

4) Zakres i priorytety (wieloosobowy najemca)

Иерардий: Global → Region → Tenant/Plan → Użytkownik/Token → Endpoint/Feature → IP/Device.
Świadomość priorytetu: VIP/Enterprise uzyskać więcej „pęknięcia” i wagi, ale nie złamać ogólnych SLO.
Skład graniczny: tolerancja całkowita = 'min (globalny, regionalny, najemca, użytkownik, punkt końcowy)'.

5) Kontyngenty ilościowe

Dzienne/miesięczne kwoty: dokumenty/dzień, GB/miesiąc, wiadomości/min.
Progi miękkie/twarde: Ostrzeżenia (80/90%) i stop twardy.
Roll-up: księgowanie według obiektów (tabele, pliki, zdarzenia) i „wypłata” do rozliczenia.

6) Ograniczenia rozproszone

Wymagania: niska opóźnienie, konsystencja, tolerancja uszkodzeń, skalowanie poziome.

Synchronizacja lokalna + probabilistyczna: miejscowe wiadra odłamkowe + synchronizacja okresowa.
Sklep centralny: Redis/МDB/Memcached.LUA/atomic ops (INCR/PEXPIRE).
Shading: klucze formularza 'limit: {scope}: {id}: {window}' z jednolitą dystrybucją.
Skew zegara: przechowywać „prawdę” na serwerze limitera, a nie na klientach.
Idempotencja: Idempotency-Keys zmniejszyć fałszywe opłaty.

7) Przeciwdziałanie nadużyciom i ochrona

Odcisk palca urządzenia per-IP + dla publicznych punktów końcowych.
Dowód pracy/CAPTCHA w nieprawidłowościach.
Spowolnienie (throttling) zamiast kompletnej awarii, gdy UX jest ważniejszy (wiersze wyszukiwania).
Limity adaptacyjne: dynamiczne zmniejszanie progów w przypadku incydentów/drogich degradacji.

8) Zachowanie klienta i protokół

Kody: „429 Zbyt wiele wniosków” (stawka), „403” (kwota/plan przekroczony), „503” (degradacja ochronna).

• 'Retry-After: ' - kiedy spróbować ponownie.

• 'Limit-Limit: ; w = '
• 'Limit-Pozostałe: '
• 'Limit-Reset: '
• Backoff: wykładniczy + jitter (full jitter, equal jitter).
• Idempotencja: nagłówek „Idempotency-Key” i powtarzalność bezpiecznych operacji.
• Terminy i anulowania: prawidłowo przerwać zawieszone żądania, aby nie „przechwytywać” limitów.

9) Obserwowalność i badania

Тева: 'tenant _ id',' plan ',' user _ id', 'endpoint', 'region', 'decision' (zezwolenie/odmowa), 'reason' (quota/rate/concurrency).
Wskaźniki: przepustowość, wskaźnik awarii 429/403/503, opóźnienie ogranicznika p95/p99, wskaźnik trafienia pamięci podręcznej klucza, przydział planu.
Dzienniki audytu: przyczyny bloków, top „hałaśliwe” klucze.
Testy: profile obciążenia „piła/pęknięcie/płaskowyż”, chaos - awaria Redis/shard, desynchronizacja zegara.

10) Integracja z rozliczeniami

Liczniki użytkowania są zbierane na granicy, zagregowane przez partie (co N minut) z idempotencją.
Podsumowanie planu: nadmierne wydatki → doładowanie lub tymczasowe zwiększenie planu.
Rozbieżności: wykorzystanie uzgodnień w stosunku do faktury; wpisy do delty.

11) Sprawiedliwość wewnątrz (kolejki, pracownicy)

Ważone targi kolejkowania/DRR: Przydzielanie czasu na start lub lądowanie najemcom według wagi planu.
Baseny na najemcę: sztywna izolacja VIP/hałaśliwa.
Kontrola wjazdu: awaria przed wykonaniem, jeżeli kwoty są wyczerpane; kolejki nie puchną.
Czapki na równoczesność: Ograniczyć jednoczesne ciężkie jabs.

12) Typowe profile planu (przykład)

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) Odniesienie architektoniczne (system słowny)

1. Brama krawędzi/API: TLS → kontekst ekstraktu (najemca/plan) → sprawdzenie limitów/kwot → umieszczenie nagłówków Limit → dziennik/ślad.
2. Silnik polityki: zasady priorytetowe (VIP), progi adaptacyjne.
3. Limiter Store: Redis/PowerDB (operacje atomowe, LUA), shading klucza, replikacja.
4. Usługi: drugorzędny limit i pułapy dla ciężkich operacji; idempotencja; Kolejki z WFQ/DRR.
5. Użycie/Rozliczenie: zbieranie, agregacja, faktura, wpisy według progów.
6. Obserwowalność: znaczniki/kłody/szlaki, deski rozdzielcze na najemcę.

14) Lista kontrolna przedsprzedaży

• Zdefiniowano zakresy limitów (najemca/użytkownik/token/punkt końcowy/IP) oraz ich hierarchię.
• Wybrany algorytm (Token Bucket/GCRA) i 'rate/burst' parametry.
• Wdrożone pułapy współistnienia i kontrola dopuszczenia do ciężkich operacji.
• W tym nagłówki „ Limit-” i „Retry-After”; klienci obsługują backoff + jitter.
• Ogranicznik jest rozproszony i odporny na uszkodzenia (odłamki, replikacja, degradacja).
• Zbieranie użytkowania jest idempotentne; pakiet z rachunkami, alerty za nadmierne wydatki.
• Obserwowalność: mierniki/ścieżki/znakowane kłody, górne „hałaśliwe” klucze, zmiany.
• Testy: wybuchy, „piła”, awaria storu, skok zegara, zimny start.
• Dokumentacja klienta: limity planu, przykłady 429/Retry-After, przekwalifikowanie najlepszych praktyk.
• Polityka wykluczenia: Jak tymczasowo podnieść limity i kiedy.

15) Typowe błędy

Globalny limit bez jednego najemcy/punktu końcowego - „hałaśliwy sąsiad” łamie wszystkie SLO.
Brak „wybuchu”: UX cierpi w krótkich wybuchach.
Używając tylko stałe okno → „podwójne trafienie na granicy okna”.
Nie ma idempotencji i retras z jitter → burza powtórzeń.
Limity tylko na granicy, bez czapek w usługach/kolejkach → wewnętrzne „korki”.
Brak odrzucenia limitów w odpowiedziach (brak 'Retry-After', ' Limit-') → klienci nie dostosowują się.
Przechowywanie stanu ogranicznika w bazie danych OLTP → wysokie opóźnienia i gorące blokady.

16) Szybki wybór strategii

Publiczne interfejsy API ze szczytami: Token Bucket + duży 'burst', Limit - nagłówki, pamięć podręczna CDN/krawędź.
Wewnętrzne ciężkie dźwignie: czapki równoległe + WFQ/DRR, kontrola wstępu.
Integracja z osobami trzecimi: oddzielne limity wyjścia, buforowanie/przekładki.
Wieloosobowy najemca SaaS: hierarchia limitów (globalny → najemca → użytkownik → punkt końcowy), priorytety VIP, miesięczne kwoty.

Wniosek

Dobre limity stawek i kwoty to umowa systemowa między platformą a klientem: uczciwy udział zasobów, odporność na kolce, przewidywalne SLO i przejrzyste rozliczenia. Łączyć algorytmy (Token/GCRA + czapki równoległe), wdrożyć hierarchię ospreys, dać jasne nagłówki i mierniki, i regularnie sprawdzać schematy w prawdziwych profilach ruchu - w ten sposób platforma pozostanie stabilna nawet przy agresywnym wzroście obciążenia.