Redis Caching & Messaging (Pub/Sub, Streams) · Ders

Hız Sınırlama ve Karşıt Kalıplar

API'lerinizi ve hizmetlerinizi korumak için Redis kullanarak etkili hız sınırlama mekanizmaları tasarlayıp uygulayın.

3. ders / 411 adım

Hız Sınırlama ve Karşıt Kalıplar, CoddyKit'te ücretsiz bir Redis Caching & Messaging (Pub/Sub, Streams) dersidir. Bu, 4 dersinin 3. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Redis Caching & Messaging (Pub/Sub, Streams) öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Redis Caching & Messaging (Pub/Sub, Streams) kursu toplamda 4 dersten oluşur.

Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.

Why Rate Limit?

Rate limiting is a crucial technique to control the frequency of requests an application receives. Think of it as a bouncer at a club, letting only a certain number of people in at a time.

It protects your APIs and services from:

Abuse: Preventing malicious attacks like brute-force attempts.
Overload: Ensuring your servers aren't overwhelmed by too many requests.
Fair Usage: Distributing access fairly among all users.

Rate Limiting Concepts

When we talk about rate limiting, a few key terms come up:

Limit: The maximum number of requests allowed.
Window: The time period over which the limit applies (e.g., 60 seconds).
Burst: A sudden spike in requests.

Different algorithms exist, like Fixed Window and Sliding Window, each with its own trade-offs.

Redis's Role in Rate Limiting

Redis is an excellent choice for implementing rate limiters due to its speed, in-memory nature, and atomic operations.

Its ability to quickly increment counters and set expirations makes it ideal for tracking request frequencies across a distributed system.

Fixed Window Algorithm

The Fixed Window algorithm is one of the simplest to implement. It works by:

Defining a fixed time window (e.g., 60 seconds).
Counting requests within that window.
Blocking requests once the limit is reached.

At the end of each window, the counter resets. This method is straightforward but can allow bursts of requests at the window boundaries.

Fixed Window in Action

Here's how you can implement a basic fixed-window rate limiter using Redis's INCR and EXPIRE commands.

Try running this Python example:

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")

Sliding Window Log Algorithm

The Sliding Window Log algorithm offers more accuracy by tracking individual request timestamps.

Here's how it works:

Each request's timestamp is stored in a Redis Sorted Set (ZSET).
When a new request arrives, old timestamps (outside the current window) are removed.
The number of remaining timestamps in the ZSET is the current request count.

This method prevents the burst issue seen at fixed window boundaries.

Sliding Window Demo

Let's see the Sliding Window Log in action. We'll use Redis's ZADD to add timestamps and ZREMRANGEBYSCORE to remove old ones.

Try running this example:

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")

Common Pitfalls

When implementing rate limiting, avoid these common anti-patterns:

Using KEYS *: Never use this in production to find rate limit keys, as it can block your Redis server.
Ignoring Bursts: Simple fixed windows can allow many requests at window boundaries, which might still overload your service.
Over-engineering: Don't make your rate limiting logic overly complex, as it can introduce bugs and performance overhead.
No Client Feedback: Always return appropriate HTTP status codes (like 429 Too Many Requests) and Retry-After headers.

Rate Limiting Best Practices

To build robust rate limiters with Redis:

Atomic Operations: Always use atomic Redis commands like INCR, ZADD, and EXPIRE to prevent race conditions.
Set Expirations: Ensure your Redis keys have appropriate Time-To-Live (TTL) values to clean up old data.
Choose Wisely: Select the right algorithm (fixed, sliding log, sliding counter) based on your accuracy and performance needs.
Provide Feedback: Inform clients when they are rate-limited using standard HTTP responses.
Monitor: Keep an eye on your rate limiters to ensure they are working as expected and not causing false positives or negatives.

Check Your Knowledge

You've learned about the Fixed Window algorithm. Now, let's test your understanding of the Redis commands involved.

İnteraktif derste cevapla

Recap & Next Steps

In this lesson, we explored the critical role of rate limiting in protecting your services and ensuring fair usage. You learned how Redis's speed and atomic operations make it an ideal tool for this.

We covered two fundamental algorithms: the Fixed Window (using INCR and EXPIRE) and the more accurate Sliding Window Log (using ZADD and ZREMRANGEBYSCORE).

Remember to avoid common anti-patterns and follow best practices for robust rate limiting. Keep practicing these patterns to master them!

Başlamak ücretsiz

Yapay zeka eğitmeniyle Redis Caching & Messaging (Pub/Sub, Streams) öğren — ücretsiz

Tarayıcında gerçek kod yaz ve çalıştır, 7/24 yapay zeka eğitmeninden anında yardım al; web'de ya da uygulamada kaldığın yerden devam et.

Kurslar: 12
Dersler: 48

Ücretsiz öğrenmeye başla Tüm kursu görüntüle

Sıkça Sorulan Sorular

“Hız Sınırlama ve Karşıt Kalıplar” dersi ücretsiz mi?

Evet — “Hız Sınırlama ve Karşıt Kalıplar” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Redis Caching & Messaging (Pub/Sub, Streams) kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Redis Caching & Messaging (Pub/Sub, Streams) kursu toplamda 4 dersten oluşur.

“Hız Sınırlama ve Karşıt Kalıplar” dersinde ne öğreneceğim?

API'lerinizi ve hizmetlerinizi korumak için Redis kullanarak etkili hız sınırlama mekanizmaları tasarlayıp uygulayın. Redis Caching & Messaging (Pub/Sub, Streams) ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

Redis Caching & Messaging (Pub/Sub, Streams) öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te Redis Caching & Messaging (Pub/Sub, Streams), başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 3. dersidir.

“Hız Sınırlama ve Karşıt Kalıplar” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu Redis Caching & Messaging (Pub/Sub, Streams) dersinde kod yazıp çalıştırabilir miyim?

Evet. Her Redis Caching & Messaging (Pub/Sub, Streams) dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

← Redis Caching & Messaging (Pub/Sub, Streams) Sayfasına Dön