Pembatasan Laju Terdistribusi dengan Redis
Pelajari cara memanfaatkan Redis untuk membangun pembatas laju terdistribusi yang tangguh dan dapat diskalakan di berbagai instans layanan.
Pembatasan Laju Terdistribusi dengan Redis adalah pelajaran API Rate Limiting & Scalability Patterns gratis di CoddyKit. Ini adalah pelajaran 2 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar API Rate Limiting & Scalability Patterns, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus API Rate Limiting & Scalability Patterns mencakup 4 pelajaran total.
Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.
Scaling Beyond Single Server
In previous lessons, we learned about basic rate limiting. But what happens when your application grows and runs on multiple servers?
- In-memory limits: They only track requests on a single server.
- Multiple servers: Each server has its own counter, leading to inaccurate and ineffective limits.
- The problem: Users can bypass limits by hitting different servers.
We need a way for all servers to share the same rate limit state.
Introducing Redis for Shared State
To build a distributed rate limiter, we need a centralized, fast data store accessible by all our application instances. This is where Redis shines!
- What is Redis? An open-source, in-memory data structure store.
- Why Redis? It's extremely fast, supports various data types, and is designed for concurrent access.
- Key for Rate Limiting: Its atomic operations are perfect for incrementing counters reliably across multiple services.
Redis Commands for Counters
Redis provides simple yet powerful commands that are ideal for building rate limiters. The two main ones you'll use are INCR and EXPIRE.
INCR key: Atomically increments the number stored atkeyby one. If the key doesn't exist, it's set to 0 before incrementing.EXPIRE key seconds: Sets a timeout onkey. After the timeout, the key is automatically deleted. This is crucial for defining our rate limiting windows.
These commands ensure our counters are consistent even with many concurrent requests.
Implementing Fixed Window with Redis
Let's consider a Fixed Window Counter algorithm using Redis. Imagine we want to limit a user to 5 requests per 60 seconds.
- Define a key: A unique key for the user and the current time window, e.g.,
user:123:2023-10-27-10:00. - Increment Counter: When a request comes in, use
INCRon this key. - Set Expiry: For the first request in a new window, also use
EXPIREto set the key's timeout (e.g., 60 seconds). - Check Limit: Before incrementing, check if the current count for the key is less than the allowed limit.
Basic Redis Fixed Window Code
Here's a simple Python example for a fixed window rate limiter using Redis. This snippet shows the core logic without full error handling.
import redis
import time
def is_rate_limited(user_id, limit, window_seconds):
r = redis.Redis(host='localhost', port=6379, db=0)
current_minute = int(time.time() // window_seconds)
key = f"rate_limit:{user_id}:{current_minute}"
count = r.get(key)
if count is None:
r.setex(key, window_seconds, 0) # Initialize and set expiry
count = 0
else:
count = int(count)
if count < limit:
r.incr(key)
return False # Not rate limited
return True # Rate limited
if __name__ == "__main__":
user = "user_alice"
requests_limit = 5
time_window = 60 # seconds
print(f"Testing rate limiter for {user} ({requests_limit} reqs/{time_window}s)")
for i in range(1, 8):
if is_rate_limited(user, requests_limit, time_window):
print(f"Request {i}: Rate limited!")
else:
print(f"Request {i}: OK")
time.sleep(0.1) # Simulate some workAddressing Race Conditions
In the previous example, the `get`, `setex`, and `incr` operations are separate. This can lead to a race condition:
- Two requests might `GET` the key when it doesn't exist.
- Both might `SETEX` it, potentially overwriting each other's expiry.
- The `EXPIRE` might not be set for the *first* incremented value, causing the counter to persist indefinitely.
We need to perform these multiple Redis commands as a single, atomic operation.
Atomic Operations with Lua Scripts
Redis allows you to execute server-side Lua scripts. This is incredibly powerful for rate limiting because:
- Atomicity: A Lua script runs as a single, indivisible command. No other Redis commands can interrupt it.
- Efficiency: Reduces network round trips for complex operations.
We can write a Lua script to check the counter, increment it, and set its expiry all in one go.
Lua Script Example for Limiter
Here's a Lua script for an atomic fixed window counter. It takes the key, limit, and window duration as arguments.
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local current_count = redis.call('INCR', key)
if current_count == 1 then
redis.call('EXPIRE', key, window)
end
if current_count > limit then
return 1 -- Rate limited
else
return 0 -- Not rate limited
endPython Calling Lua Script
Now, let's see how to integrate and execute this Lua script from our Python application. The EVAL command sends the script to Redis for atomic execution.
import redis
import time
def is_rate_limited_atomic(user_id, limit, window_seconds):
r = redis.Redis(host='localhost', port=6379, db=0)
current_minute = int(time.time() // window_seconds)
key = f"rate_limit_atomic:{user_id}:{current_minute}"
# The Lua script to execute
lua_script = """
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local current_count = redis.call('INCR', key)
if current_count == 1 then
redis.call('EXPIRE', key, window)
end
if current_count > limit then
return 1 -- Rate limited
else
return 0 -- Not rate limited
end
"""
# Execute the Lua script atomically
# KEYS[1] is 'key'
# ARGV[1] is 'limit', ARGV[2] is 'window_seconds'
result = r.eval(lua_script, 1, key, limit, window_seconds)
return bool(result)
if __name__ == "__main__":
user = "user_bob"
requests_limit = 5
time_window = 60 # seconds
print(f"Testing atomic rate limiter for {user} ({requests_limit} reqs/{time_window}s)")
for i in range(1, 8):
if is_rate_limited_atomic(user, requests_limit, time_window):
print(f"Request {i}: Rate limited!")
else:
print(f"Request {i}: OK")
time.sleep(0.1) # Simulate some workDistributed Limiting Check
Which of the following are key benefits of using Redis for distributed rate limiting, especially when using Lua scripting?
Recap: Redis for Scale
Great job! You've learned how to build robust distributed rate limiters using Redis.
- Distributed Problem: In-memory limits fail with multiple application instances.
- Redis Solution: Provides a fast, centralized, and shared state for rate limit counters.
- Key Commands:
INCRandEXPIREare fundamental. - Atomicity with Lua: Crucial for preventing race conditions and ensuring correctness when multiple Redis commands are involved.
This approach is foundational for building scalable and resilient APIs.
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Pembatasan Laju Terdistribusi dengan Redis” gratis?
Ya — teks lengkap “Pembatasan Laju Terdistribusi dengan Redis” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus API Rate Limiting & Scalability Patterns, upgrade ke CoddyKit PRO. Kursus API Rate Limiting & Scalability Patterns mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Pembatasan Laju Terdistribusi dengan Redis”?
Pelajari cara memanfaatkan Redis untuk membangun pembatas laju terdistribusi yang tangguh dan dapat diskalakan di berbagai instans layanan. Kamu berlatih API Rate Limiting & Scalability Patterns dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai API Rate Limiting & Scalability Patterns?
Tidak diperlukan pengalaman sebelumnya. API Rate Limiting & Scalability Patterns di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 2 dari 4.
Berapa lama pelajaran “Pembatasan Laju Terdistribusi dengan Redis” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran API Rate Limiting & Scalability Patterns ini?
Ya. Setiap pelajaran API Rate Limiting & Scalability Patterns menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- Rancangan Pembatas Laju Dalam Memori
- Pembatasan Laju Terdistribusi dengan Redis
- Menangani Pelampauan Batas Laju
- Menguji dan Memantau Pembatas Laju Anda