Hastighetsbegränsning och antimönster
Utforma och implementera effektiva mekanismer för hastighetsbegränsning med Redis för att skydda era API:er och tjänster.
Hastighetsbegränsning och antimönster är en gratis lektion i Redis: cachelagring och meddelanden (Pub/Sub, Streams) på CoddyKit. Detta är lektion 3 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Redis: cachelagring och meddelanden (Pub/Sub, Streams), och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Redis: cachelagring och meddelanden (Pub/Sub, Streams) innehåller totalt 4 lektioner.
Varför begränsa anropsfrekvensen?
Rate limiting är en viktig teknik för att kontrollera hur ofta en applikation tar emot anrop. Tänk på det som en dörrvakt på en klubb som bara släpper in ett visst antal personer åt gången.
Det skyddar dina API:er och tjänster mot:
- Missbruk: Förhindrar skadliga angrepp som brute-force-försök.
- Överbelastning: Säkerställer att servrarna inte överbelastas av för många anrop.
- Rättvis användning: Fördelar åtkomsten rättvist mellan alla användare.
Begrepp inom rate limiting
När vi talar om rate limiting dyker några viktiga begrepp upp:
- Gräns: Det maximala antalet tillåtna anrop.
- Tidsfönster: Den tidsperiod som gränsen gäller för (till exempel 60 sekunder).
- Spurt: En plötslig ökning av antalet anrop.
Det finns olika algoritmer, till exempel Fixed Window och Sliding Window, och var och en har sina egna avvägningar.
Redis roll vid rate limiting
Redis är ett utmärkt val för att implementera rate limiters tack vare sin snabbhet, minnesbaserade natur och atomära operationer.
Förmågan att snabbt öka räknare och ange giltighetstider gör Redis idealiskt för att spåra anropsfrekvenser i ett distribuerat system.
Algoritmen Fixed Window
Algoritmen Fixed Window är en av de enklaste att implementera. Den fungerar genom att:
- Definiera ett fast tidsfönster (till exempel 60 sekunder).
- Räkna anrop inom det tidsfönstret.
- Blockera anrop när gränsen har nåtts.
I slutet av varje tidsfönster återställs räknaren. Metoden är enkel, men kan tillåta anropsspurter vid tidsfönstrens gränser.
Fixed Window i praktiken
Så här kan du implementera en enkel rate limiter med ett fast tidsfönster med hjälp av Redis-kommandona INCR och EXPIRE.
Prova att köra det här Python-exemplet:
import redis
import time
r = redis.Redis(decode_responses=True)
def check_rate_limit(user_id, limit_per_min):
key = f"rl:{user_id}"
# Increment counter for the user
current_count = r.incr(key)
# If it's the first request in this window, set expiration
if current_count == 1:
r.expire(key, 60) # Expire in 60 seconds
return current_count <= limit_per_min
if __name__ == "__main__":
test_user = "user_A"
rate_limit = 3 # 3 requests per minute
print(f"User '{test_user}' limit: {rate_limit} req/min")
for i in range(1, 6):
if check_rate_limit(test_user, rate_limit):
print(f"Request {i}: ALLOWED")
else:
print(f"Request {i}: BLOCKED")
time.sleep(0.5) # Simulate quick requests
print("\nWaiting for 60s window to reset...")
# In a real app, this delay would be handled by subsequent requests
# For demo, we'll clear the key
r.delete(f"rl:{test_user}")
time.sleep(1) # Small pause
print("Window reset. New request:")
if check_rate_limit(test_user, rate_limit):
print("Request 1: ALLOWED")
else:
print("Request 1: BLOCKED")Algoritmen Sliding Window Log
Algoritmen Sliding Window Log ger högre precision genom att spåra tidsstämplarna för enskilda anrop.
Så här fungerar den:
- Tidsstämpeln för varje anrop lagras i en Redis Sorted Set (ZSET).
- När ett nytt anrop kommer tas gamla tidsstämplar bort, det vill säga de som ligger utanför det aktuella tidsfönstret.
- Antalet återstående tidsstämplar i ZSET är det aktuella antalet anrop.
Den här metoden förhindrar problemet med spurter som kan uppstå vid gränserna för fasta tidsfönster.
Demonstration av Sliding Window
Nu ska vi se Sliding Window Log i praktiken. Vi använder Redis-kommandot ZADD för att lägga till tidsstämplar och ZREMRANGEBYSCORE för att ta bort gamla tidsstämplar.
Prova att köra det här exemplet:
import redis
import time
r = redis.Redis(decode_responses=True)
def check_sliding_window_limit(user_id, limit, window_seconds):
key = f"rl_sliding:{user_id}"
current_time = int(time.time() * 1000) # Milliseconds timestamp
# Remove scores older than the window
r.zremrangebyscore(key, 0, current_time - (window_seconds * 1000))
# Add current request timestamp
r.zadd(key, {current_time: current_time})
# Set expiration for the key itself to clean up old rate limiters
# This is a fallback if no new requests come for a long time
r.expire(key, window_seconds + 5)
# Count requests in the window
current_requests = r.zcard(key)
return current_requests <= limit
if __name__ == "__main__":
test_user = "user_B"
rate_limit = 3 # 3 requests per 10 seconds
window = 10 # seconds
print(f"User '{test_user}' limit: {rate_limit} req/{window}s (Sliding Log)")
for i in range(1, 6):
if check_sliding_window_limit(test_user, rate_limit, window):
print(f"Request {i}: ALLOWED")
else:
print(f"Request {i}: BLOCKED")
time.sleep(1) # Simulate requests over time
print("\nWaiting for window to slide...")
time.sleep(window)
print("Window slid. New request:")
if check_sliding_window_limit(test_user, rate_limit, window):
print("Request 1: ALLOWED")
else:
print("Request 1: BLOCKED")Vanliga fallgropar
Undvik följande vanliga anti-mönster när du implementerar rate limiting:
- Använda
KEYS *: Använd aldrig detta i produktion för att hitta nycklar för rate limiting, eftersom det kan blockera din Redis-server. - Ignorera spurter: Enkla fasta tidsfönster kan tillåta många anrop vid tidsfönstrens gränser, vilket fortfarande kan överbelasta tjänsten.
- Överkomplicera lösningen: Gör inte logiken för rate limiting onödigt komplex, eftersom det kan leda till buggar och sämre prestanda.
- Ingen återkoppling till klienten: Returnera alltid lämpliga HTTP-statuskoder (som
429 Too Many Requests) ochRetry-After-headers.
Bästa praxis för rate limiting
Så här bygger du robusta rate limiters med Redis:
- Atomära operationer: Använd alltid atomära Redis-kommandon som
INCR,ZADDochEXPIREför att förhindra race conditions. - Ange giltighetstider: Se till att dina Redis-nycklar har lämpliga Time-To-Live-värden (TTL) så att gamla data rensas bort.
- Välj med omsorg: Välj rätt algoritm (fixed, sliding log eller sliding counter) utifrån dina krav på precision och prestanda.
- Ge återkoppling: Informera klienterna när de begränsas av rate limiting genom att använda standardiserade HTTP-svar.
- Övervaka: Håll uppsikt över dina rate limiters för att säkerställa att de fungerar som förväntat och inte orsakar falska positiva eller negativa resultat.
Testa dina kunskaper
Du har lärt dig om algoritmen Fixed Window. Nu testar vi dina kunskaper om de Redis-kommandon som ingår.
Sammanfattning och nästa steg
I den här lektionen undersökte vi rate limitingens viktiga roll när det gäller att skydda dina tjänster och säkerställa rättvis användning. Du lärde dig hur Redis snabbhet och atomära operationer gör det till ett idealiskt verktyg för detta.
Vi gick igenom två grundläggande algoritmer: Fixed Window (med INCR och EXPIRE) och den mer precisa Sliding Window Log (med ZADD och ZREMRANGEBYSCORE).
Kom ihåg att undvika vanliga anti-mönster och följa bästa praxis för robust rate limiting. Fortsätt öva på dessa mönster för att behärska dem!
Lär dig Redis: cachelagring och meddelanden (Pub/Sub, Streams) med en AI-lärare – gratis
Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.
- Kurser
- 12
- Lektioner
- 48
Vanliga frågor
Är lektionen ”Hastighetsbegränsning och antimönster” gratis?
Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Redis: cachelagring och meddelanden (Pub/Sub, Streams), inklusive ”Hastighetsbegränsning och antimönster”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Redis: cachelagring och meddelanden (Pub/Sub, Streams) innehåller totalt 4 lektioner.
Vad lär jag mig i ”Hastighetsbegränsning och antimönster”?
Utforma och implementera effektiva mekanismer för hastighetsbegränsning med Redis för att skydda era API:er och tjänster. Ni övar på Redis: cachelagring och meddelanden (Pub/Sub, Streams) med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.
Behöver jag någon erfarenhet för att börja lära mig Redis: cachelagring och meddelanden (Pub/Sub, Streams)?
Du behöver inga förkunskaper. Utbildningen i Redis: cachelagring och meddelanden (Pub/Sub, Streams) på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 3 av 4.
Hur lång tid tar lektionen ”Hastighetsbegränsning och antimönster”?
De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.
Kan jag skriva och köra kod i den här Redis: cachelagring och meddelanden (Pub/Sub, Streams)-lektionen?
Ja. Varje Redis: cachelagring och meddelanden (Pub/Sub, Streams)-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.
Alla lektioner i den här kursen
- Avancerade cachemönster
- Sessionshantering med Redis
- Hastighetsbegränsning och antimönster
- Strategier för cache-invalidering