系统设计 Lab
Rate limiter 设计本质是一个对 latency 敏感的 atomic state 问题。
调节请求量、quota、burst 容忍度、key cardinality、hot-key 倾斜、region 数量和 latency 目标。架构会从本地 counter 逐步演进到 Redis/Lua、sharded state、本地 pre-check，当全局正确性变得重要时再加上一个 quota service。
分步讲解
一步一步把它想清楚
要点
常规演进场景
从左到右点击，就是预设的演示路径。每张卡片都会改变 workload 输入。
推荐形态
当前架构路径
Client
Client 发出必须得到同步 allow 或 deny 的流量
Edge / API
API gateway 在调用 backend 之前执行 enforcement
Local pre-check 对低风险或已缓存 state 的快速进程内检查
Limiter state
Redis Lua 为分布式 server 提供 atomic 的 check-and-update
Shard router 分散 key state 并隔离 hot key
协调
Quota service 协调严格全局或各 region 的预算
Service + analytics
Backend 只接收允许的流量
Events 记录判定结果，供滥用分析和调优
瓶颈
Atomic 路径负载
Hot-key 压力
State 内存
跨 region 正确性
Latency 预算
为什么会变
决策权衡
有出处支撑的规则
这些是模型背后那些经得起时间考验的 system design 论断。而 slider 的具体阈值，则被刻意标注为教学用的假设。
atomic 自增加上过期是最简单的 rate-limiter 基线
Redis 文档用 INCR 和 key 过期描述了基于 counter 的 rate limiter 模式，正好对应单窗口的基线。
Redis DocsLua 脚本让 check-and-update 在单个 Redis shard 上 atomic
当很多 API server 在竞争时，limiter 不应该把读、算、写做成各自独立的网络操作。
Redis Docs生产环境的 rate limiting 通常在 origin 之前执行
edge enforcement 在花费 origin 资源之前就判定请求能否继续，从而保护 backend。
Cloudflare Docs分布式 rate limiting 有明确的 local 对 global 权衡
global rate limiting 把判定集中起来，而 local 检查更快，但跨多 instance 或多 region 时不够精确。
Envoy Docs教学用假设
- 这个 lab 建模的是同步 enforcement 路径；Kafka 风格的 event stream 用于 analytics、滥用调查和调优。
- Hot-key 阈值刻意保守，因为即使总 QPS 看起来安全，一个滥用 key 也可能主导一个 shard。
- 跨 region 的严格全局 quota 被建模成一种正确性选择，它会花掉 latency 和可用性预算。