令牌桶算法本质是用“变量配额”实现柔性限流，通过容量（突发上限）、速率（长期均值）和时间戳（动态校准）三个变量协同控制请求授权，支持空闲积累、高峰透支、低峰恢复的弹性流量管理。
令牌桶算法本质是用“变量配额”做动态资源授权，不是简单计数，而是通过令牌的生成、积累和消耗，实现对请求速率的柔性控制。
核心变量怎么配：容量、速率、时间戳
三个关键变量决定限流行为：
- 容量（Capacity）：桶能存的最大令牌数，代表系统可承受的突发峰值。设为100，意味着最多允许100个请求瞬时通过。
- 速率（Rate）：单位时间生成令牌数，比如5 token/s，即长期平均吞吐上限为每秒5个请求。
- 时间戳（lastRefillTime）：记录上次补令牌时刻，用于按需计算累积量，避免频繁定时任务开销。
这三者共同构成“变量配额”——容量管上限，速率管均值，时间戳管动态校准。它们不是静态阈值，而是随时间推移持续演化的状态。
配额怎么动态生效：补+取两步原子操作
每次请求到来时，并非直接查当前令牌数，而是先“补”，再“取”：
- 根据当前时间与lastRefillTime的差值，算出应新增令牌数：
elapsed × rate； - 更新令牌数：
tokens = min(capacity, tokens + 新增量)； - 再判断
tokens ≥ 1：满足则减1并放行，否则拒绝。
这个过程把“时间流逝”显式建模进配额计算，让限流具备自然恢复能力——哪怕连续被拒，只要等够时间，令牌就会自动回填。
为什么叫“变量配额”：它能适应业务节奏
固定窗口或计数器类算法只看“过去N秒内多少次”，而令牌桶的配额始终在变：
- 空闲期：令牌持续积累，桶逐渐填满，为后续突发预留缓冲；
- 高峰时：快速消耗存量令牌，允许短时超速（如20请求/秒持续2秒），只要长期不超速率即可；
- 低峰后：配额缓慢回升，无需人工重置或窗口翻转。
这种弹性正是“变量配额”的价值——它不卡死流量曲线，而是像有弹性的带宽一样，既守住底线，又尊重真实业务波动。
单机与分布式中的配额一致性
单机场景下，用锁或CAS保证变量读写安全即可；分布式环境里，“变量配额”必须集中维护：
- Redis常用
HASH结构存{capacity, rate, tokens, lastRefillTime}； - 补令牌逻辑建议用Lua脚本原子执行，防止并发覆盖；
- 若用Guava RateLimiter，其内部也是基于类似变量模型，但仅限JVM内有效。
无论在哪种部署形态下，只要配额的三个变量被统一管理、精确更新，系统级限流就真正落地了。
