Het juiste rate-limitingalgoritme kiezen
Vergelijk de belangrijkste rate-limitingalgoritmen — fixed window, sliding window, token bucket en leaky bucket — en leer wanneer elk algoritme past bij uw verkeersprofiel en doelen voor eerlijkheid.
Het juiste rate-limitingalgoritme kiezen is een gratis Patronen voor API-snelheidsbeperking en schaalbaarheid-les op CoddyKit. Dit is les 4 van 4. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Patronen voor API-snelheidsbeperking en schaalbaarheid. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Patronen voor API-snelheidsbeperking en schaalbaarheid bevat in totaal 4 lessen.
Waarom het algoritme belangrijk is
Een beleid voor snelheidsbeperking is slechts zo goed als het algoritme dat het afdwingt. Dezelfde limiet van 100 requests/minute gedraagt zich heel anders afhankelijk van de manier waarop je telt.
In deze les vergelijken we vier klassieke benaderingen en leren we hoe je er één kiest op basis van je behoeften op het gebied van eerlijkheid, bursts en nauwkeurigheid.
Teller met vast venster
De eenvoudigste aanpak: tel verzoeken in een vast tijdvenster (bijvoorbeeld elke kalenderminuut) en reset de teller op de grens.
- Voordelen: eenvoudig te implementeren, weinig geheugen
- Nadelen: staat rond de venstergrens een burst van
2xde limiet toe
def allow(counter, limit):
if counter['count'] >= limit:
return False
counter['count'] += 1
return TrueHet probleem van bursts rond de grens
Bij een vast venster kan een client limit verzoeken sturen om 00:59 en nog eens limit om 01:00. Dat is twee keer de bedoelde snelheid binnen één seconde.
Sliding-windowalgoritmen bestaan precies om deze piek af te vlakken.
Sliding-windowlogboek
Sla voor elk verzoek een tijdstempel op. Om een beslissing te nemen, verwijder je tijdstempels die ouder zijn dan het venster en tel je wat overblijft.
- Voordelen: exact, geen burst rond de grens
- Nadelen: het geheugengebruik groeit mee met het aantal verzoeken
def allow(log, now, window, limit):
cutoff = now - window
log[:] = [t for t in log if t > cutoff]
if len(log) >= limit:
return False
log.append(now)
return TrueSliding-windowteller
Een hybride aanpak: houd de tellingen van het huidige en vorige vaste venster bij en schat vervolgens de snelheid met een gewogen overlap.
Deze aanpak benadert het sliding-windowlogboek met veel minder geheugen. Daarom geven API-gateways en CDN's hier de voorkeur aan.
weighted = prev_count * overlap + curr_count
allowed = weighted < limitTokenbucket
Een bucket bevat tokens tot aan een bepaalde capaciteit. Tokens worden met een vaste snelheid aangevuld; elk verzoek besteedt één token. Een lege bucket betekent dat het verzoek wordt geweigerd.
- Staat gecontroleerde bursts toe tot aan de capaciteit van de bucket
- Maakt het langetermijngemiddelde gelijk aan de aanvulsnelheid
def allow(bucket, now, rate, capacity):
elapsed = now - bucket['ts']
bucket['tokens'] = min(capacity, bucket['tokens'] + elapsed * rate)
bucket['ts'] = now
if bucket['tokens'] < 1:
return False
bucket['tokens'] -= 1
return TrueLeaky bucket
Verzoeken komen in een wachtrij die met een constante snelheid leegloopt. Als de wachtrij overstroomt, worden verzoeken verwijderd.
In tegenstelling tot de tokenbucket dwingt de leaky bucket een constante uitvoersnelheid af — ideaal wanneer een systeem verderop pieken niet aankan.
Tokenbucket versus leaky bucket
- Met een tokenbucket kan verkeer tot aan de capaciteit in bursts komen, waarna het wordt afgeremd — goed voor API's voor eindgebruikers die responsief moeten aanvoelen.
- Een leaky bucket dwingt een gelijkmatige, constante stroom af — goed voor het beschermen van kwetsbare backends.
Afwegingen tussen geheugen en nauwkeurigheid
Kies op basis van de beperkingen:
- Minste geheugen: vast venster
- Hoogste nauwkeurigheid: sliding-windowlogboek
- Beste balans: sliding-windowteller
- Geschikt voor bursts: tokenbucket
Aandachtspunten voor gedistribueerde systemen
Over meerdere servers heen kan elke node niet zijn eigen teller bijhouden, anders vermenigvuldig je de werkelijke limiet. Gebruik een gedeelde opslag zoals Redis met atomaire bewerkingen, zodat de telling globaal is.
Een tokenbucket en sliding-windowteller zijn beide eenvoudig te vertalen naar Redis-primitieven.
-- Redis atomic counter with expiry
INCR rate:user:42
EXPIRE rate:user:42 60Een checklist voor je keuze
Vraag jezelf af:
- Moeten korte bursts worden toegestaan? → tokenbucket
- Moet het systeem verderop een constante snelheid zien? → leaky bucket
- Is exactheid cruciaal voor facturering? → sliding-windowlogboek
- Wil je iets eenvoudigs en goedkoops? → vaste of sliding-windowteller
Korte controle
Test je begrip van het kiezen van een algoritme.
Samenvatting
Je hebt vier algoritmen voor snelheidsbeperking vergeleken:
- Vast venster — goedkoop, maar staat bursts rond de grens toe
- Sliding window — nauwkeurig en maakt grenzen gelijkmatiger
- Tokenbucket — geschikt voor bursts en maakt het gemiddelde gelijkmatiger
- Leaky bucket — constante uitvoersnelheid
Kies op basis van je tolerantie voor bursts, nauwkeurigheid en geheugembudget.
Leer Patronen voor API-snelheidsbeperking en schaalbaarheid met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 12
- Lessen
- 48
Veelgestelde vragen
Is de les “Het juiste rate-limitingalgoritme kiezen” gratis?
Ja — de volledige tekst van “Het juiste rate-limitingalgoritme kiezen” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus Patronen voor API-snelheidsbeperking en schaalbaarheid wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus Patronen voor API-snelheidsbeperking en schaalbaarheid bevat in totaal 4 lessen.
Wat leer ik in “Het juiste rate-limitingalgoritme kiezen”?
Vergelijk de belangrijkste rate-limitingalgoritmen — fixed window, sliding window, token bucket en leaky bucket — en leer wanneer elk algoritme past bij uw verkeersprofiel en doelen voor eerlijkheid. Je oefent met Patronen voor API-snelheidsbeperking en schaalbaarheid door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Patronen voor API-snelheidsbeperking en schaalbaarheid te beginnen?
Ervaring vooraf is niet nodig. Patronen voor API-snelheidsbeperking en schaalbaarheid op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 4 van 4.
Hoe lang duurt de les “Het juiste rate-limitingalgoritme kiezen”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Patronen voor API-snelheidsbeperking en schaalbaarheid?
Ja. Elke les over Patronen voor API-snelheidsbeperking en schaalbaarheid bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- Throttling versus rate limiting uitgelegd
- Beleid voor verkeerspieken en coulanceperiodes
- Limieten aan clientzijde versus serverzijde
- Het juiste rate-limitingalgoritme kiezen