Contador de janela fixa explicado
Descubra como funciona o algoritmo do contador de janela fixa, sua simplicidade e suas possíveis limitações ao lidar com picos de tráfego.
Contador de janela fixa explicado é uma aula grátis de API Rate Limiting & Scalability Patterns no CoddyKit. Esta é a aula 1 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de API Rate Limiting & Scalability Patterns, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de API Rate Limiting & Scalability Patterns inclui 4 aulas no total.
Partes desta aula ainda não foram traduzidas e aparecem em inglês.
Why Algorithms?
Rate limiting isn't just a 'yes' or 'no' check. It relies on smart algorithms to manage traffic. These algorithms decide how and when to allow or deny requests, ensuring fairness and stability.
We'll start with one of the simplest: the Fixed Window Counter.
Fixed Window Counter: The Idea
The Fixed Window Counter is a straightforward rate limiting algorithm. It works by dividing time into fixed, non-overlapping windows.
- Each window has its own request counter.
- Once a request comes in, the counter for the current window increments.
- If the counter exceeds a predefined limit within that window, further requests are blocked.
How It Counts
Imagine a clock. For every minute (our fixed window), we allow, say, 10 requests. When a new minute starts, the counter resets to zero.
- Window: A specific time period (e.g., 60 seconds).
- Limit: Maximum requests allowed in that window.
- Counter: Tracks requests within the current window.
It's like a bouncer at a club, letting in only a set number of people each hour, then resetting the count for the next hour.
Example: 10 RPS Limit
Let's say our limit is 10 requests per second (RPS).
- Window 1 (0-1s): 7 requests made. 3 requests remaining.
- Window 2 (1-2s): 12 requests made. First 10 allowed, next 2 blocked.
- Window 3 (2-3s): 5 requests made. All allowed.
At the start of each new second, the counter resets, regardless of activity in the previous second.
Basic Counter Logic
Here's a simple Java class simulating a request counter. This forms the foundation of our rate limiter. It keeps track of requests within a defined window.
import java.time.Instant;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;
class FixedWindowCounter {
private final int limit;
private final long windowSizeMillis; // e.g., 60_000 for 1 minute
private final ConcurrentHashMap<Long, AtomicInteger> counters;
public FixedWindowCounter(int limit, long windowSizeMillis) {
this.limit = limit;
this.windowSizeMillis = windowSizeMillis;
this.counters = new ConcurrentHashMap<>();
}
public boolean allowRequest(String userId) {
long currentWindowKey = Instant.now().toEpochMilli() / windowSizeMillis;
// Get or create counter for the current window
AtomicInteger counter = counters.computeIfAbsent(
currentWindowKey, k -> new AtomicInteger(0)
);
// Increment and check if within limit
return counter.incrementAndGet() <= limit;
}
}
public class Main {
public static void main(String[] args) {
System.out.println("FixedWindowCounter class defined.");
System.out.println("Ready to use in next example.");
}
}Testing the Window
Let's use our FixedWindowCounter class to simulate requests and see how it limits them within a 1-second window. Observe how requests are counted and then reset for the next window.
import java.time.Instant;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;
// The FixedWindowCounter class
class FixedWindowCounter {
private final int limit;
private final long windowSizeMillis;
private final ConcurrentHashMap<Long, AtomicInteger> counters;
public FixedWindowCounter(int limit, long windowSizeMillis) {
this.limit = limit;
this.windowSizeMillis = windowSizeMillis;
this.counters = new ConcurrentHashMap<>();
}
public boolean allowRequest(String userId) {
long currentWindowKey = Instant.now().toEpochMilli() / windowSizeMillis;
AtomicInteger counter = counters.computeIfAbsent(
currentWindowKey, k -> new AtomicInteger(0)
);
return counter.incrementAndGet() <= limit;
}
}
public class Main {
public static void main(String[] args) throws InterruptedException {
// Allow 3 requests per 1-second window
FixedWindowCounter limiter = new FixedWindowCounter(3, 1000);
System.out.println("--- First Window ---");
for (int i = 0; i < 5; i++) {
boolean allowed = limiter.allowRequest("user1");
System.out.println("Request " + (i + 1) + ": " + (allowed ? "ALLOWED" : "BLOCKED"));
}
// Wait for next window to start
Thread.sleep(1100);
System.out.println("\n--- Second Window ---");
for (int i = 0; i < 2; i++) {
boolean allowed = limiter.allowRequest("user1");
System.out.println("Request " + (i + 1) + ": " + (allowed ? "ALLOWED" : "BLOCKED"));
}
}
}Fixed Window: Pros
The Fixed Window Counter algorithm is popular for its simplicity and efficiency in certain scenarios.
- Easy to Implement: Requires minimal logic and data structures (just a counter and a timestamp).
- Low Resource Usage: Very little memory and CPU overhead per window.
- Predictable: The reset at the start of each window is clear and easy to understand.
It's a good choice for basic rate limiting where precision isn't paramount.
The Burst Problem
Despite its simplicity, the Fixed Window Counter has a significant drawback: it can allow twice the intended rate limit at the window boundaries.
Imagine a limit of 10 requests per minute.
- A user makes 10 requests at 0:59 (end of window 1).
- They then make 10 more requests at 1:01 (start of window 2).
This means 20 requests were made within a very short 2-minute period, effectively doubling the rate in a small burst.
Boundary Bursts
Let's visualize the burst issue with a 5 requests/minute limit.
- Window 1 (0:00 - 0:59): 5 requests sent at 0:58. (Allowed)
- Window 2 (1:00 - 1:59): 5 requests sent at 1:01. (Allowed)
In just 3 minutes (0:58 to 1:01), 10 requests were allowed. This is effectively 5 requests in ~3 seconds, not 5 requests per minute, defeating the purpose of the limit.
This 'burst' can overwhelm your system if not accounted for.
Fixed Window Check
Consider a fixed window rate limiter set to 5 requests per minute. The current time is 0:59:30. A user has already made 4 requests in the current window (0:00:00 to 0:59:59).
They then make another 3 requests at 0:59:45. Immediately after, at 1:00:05 (5 seconds into the next window), they make 3 more requests.
Recap: Fixed Window
We've explored the Fixed Window Counter algorithm:
- It divides time into distinct, non-overlapping windows.
- Each window has a request counter that resets at the start of a new window.
- It's simple to implement and understand.
- Its main drawback is the burst problem, where requests at window boundaries can effectively double the rate in a short period.
Next, we'll look at algorithms that try to smooth out these bursts!
Perguntas Frequentes
A aula “Contador de janela fixa explicado” é grátis?
Sim — o texto completo de “Contador de janela fixa explicado” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de API Rate Limiting & Scalability Patterns, atualize para CoddyKit PRO. O curso de API Rate Limiting & Scalability Patterns inclui 4 aulas no total.
O que vou aprender em “Contador de janela fixa explicado”?
Descubra como funciona o algoritmo do contador de janela fixa, sua simplicidade e suas possíveis limitações ao lidar com picos de tráfego. Você pratica API Rate Limiting & Scalability Patterns com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar API Rate Limiting & Scalability Patterns?
Nenhuma experiência prévia é necessária. API Rate Limiting & Scalability Patterns no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 1 de 4.
Quanto tempo leva a aula “Contador de janela fixa explicado”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de API Rate Limiting & Scalability Patterns?
Sim. Cada aula de API Rate Limiting & Scalability Patterns inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Contador de janela fixa explicado
- Análise detalhada do algoritmo do balde furado
- Mecânica do algoritmo do balde de tokens
- Escolha do algoritmo adequado