การจำกัดอัตราแบบกระจายด้วย Redis

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.

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 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 at key by one. If the key doesn't exist, it's set to 0 before incrementing.
• EXPIRE key seconds: Sets a timeout on key. 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.

Let's consider a Fixed Window Counter algorithm using Redis. Imagine we want to limit a user to 5 requests per 60 seconds.

1. Define a key: A unique key for the user and the current time window, e.g., user:123:2023-10-27-10:00.
2. Increment Counter: When a request comes in, use INCR on this key.
3. Set Expiry: For the first request in a new window, also use EXPIRE to set the key's timeout (e.g., 60 seconds).
4. Check Limit: Before incrementing, check if the current count for the key is less than the allowed limit.

Here's a simple Python example for a fixed window rate limiter using Redis. This snippet shows the core logic without full error handling.

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.

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.

Here's a Lua script for an atomic fixed window counter. It takes the key, limit, and window duration as arguments.

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.

Which of the following are key benefits of using Redis for distributed rate limiting, especially when using Lua scripting?

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: INCR and EXPIRE are 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.