速率限制器架构

Architecture

速率限制器架构图，实现令牌桶算法，使用 Redis 支持的分布式计数器、滑动窗口日志、API 密钥识别、速率限制头和多节点同步以实现一致的执行。该模板展示如何保护 API 免受滥用并确保客户端间的公平使用，包括适当的 HTTP 429 响应和 Retry-After 头。对于构建生产级速率限制基础设施的 API 平台团队至关重要。

下载 .fz 文件

完整 FlowZap 代码

Client { # Client
n1: circle label:"API Request"
n2: rectangle label:"Attach API Key"
n3: rectangle label:"Receive Response"
n4: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> RateLimiter.n5.handle(top) [label="Request"]
n3.handle(right) -> n4.handle(left)
}
RateLimiter { # Rate Limiter (Token Bucket)
n5: rectangle label:"Extract Client Identity"
n6: rectangle label:"Lookup Rate Limit Config"
n7: rectangle label:"Check Token Bucket"
n8: diamond label:"Tokens Available?"
n9: rectangle label:"Consume Token"
n10: rectangle label:"Return 429 Too Many Requests"
n11: rectangle label:"Add Rate Limit Headers"
n12: rectangle label:"Forward to Backend"
n5.handle(right) -> n6.handle(left) [label="API Key / IP"]
n6.handle(right) -> n7.handle(left) [label="100 req/min"]
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="Yes"]
n8.handle(bottom) -> n10.handle(top) [label="No"]
n9.handle(right) -> n11.handle(left) [label="Decrement"]
n11.handle(right) -> n12.handle(left) [label="X-RateLimit-Remaining"]
n10.handle(right) -> n11.handle(left) [label="Retry-After"]
n10.handle(top) -> Client.n3.handle(bottom) [label="429"]
n12.handle(bottom) -> Backend.n13.handle(top) [label="Allowed"]
}
Backend { # Backend Service
n13: rectangle label:"Process Request"
n14: rectangle label:"Return Response"
n13.handle(right) -> n14.handle(left) [label="Execute"]
n14.handle(top) -> Client.n3.handle(bottom) [label="200"]
}
Store { # Rate Limit Store (Redis)
n15: rectangle label:"Redis Counter"
n16: rectangle label:"Sliding Window Log"
n17: rectangle label:"Distributed Sync"
n7.handle(bottom) -> Store.n15.handle(top) [label="INCR + EXPIRE"]
n15.handle(right) -> n16.handle(left) [label="Window Check"]
n16.handle(right) -> n17.handle(left) [label="Multi-Node"]
}

为什么需要这个工作流？

Without rate limiting, a single abusive client or a traffic spike can overwhelm your API, degrading performance for all users. A rate limiter enforces fair usage quotas per client, protecting backend services from overload while providing clear feedback through standard HTTP headers.

工作原理

Step 1: The client identity is extracted from the API key or IP address.
Step 2: The rate limit configuration is looked up for the identified client tier.
Step 3: The token bucket in Redis is checked for available tokens.
Step 4: If tokens are available, one is consumed and the request proceeds with rate limit headers.
Step 5: If no tokens are available, a 429 Too Many Requests response is returned with a Retry-After header.
Step 6: Distributed Redis synchronization ensures consistent rate limiting across multiple API gateway nodes.

替代方案

Application-level rate limiting does not work across multiple instances. Cloud provider rate limiting (AWS API Gateway) is simpler but less customizable. This template shows the distributed token bucket implementation with Redis.

Key Facts

Template Name	速率限制器架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)