允许受控突发
令牌桶
请求先拿令牌；桶里有就立刻通过，没有就当场拒绝。用掉的令牌随后按固定速率补回。
到达时立刻拿到令牌—
没拿到令牌，当场拒绝—
重新补满预计还需—
通过0
拒绝0
排队中0
最大等待0.0s
Rate limit / 同流量对照实验
令牌桶与漏桶，究竟在保护谁？
把同一波请求同时倒进两个桶。一个把积攒的额度交给突发，一个把突发压进队列慢慢放行。先看代价，再谈选型。
业务预设
令牌桶每秒补充的令牌数，也是漏桶每秒稳定放出的请求数。
令牌桶最多积攒多少额度；漏桶最多暂存多少等待请求。
假设这些请求在同一瞬间到达，不把网络耗时混进算法差异。
30 个请求
t = 0.0s
保护稳定下游
漏桶
请求先进入队列，再按固定速率出队。短时拥堵变成等待；队列装不下的部分才会溢出。
进入队列，等待稳定出流—
队列已满，直接溢出—
最后一个接收请求离开—
已通过0
拒绝0
排队中0
最大等待0.0s
当前参数下的判断
先运行一次，观察两种代价
令牌桶把代价放在“突发时拒绝”，漏桶把代价放在“队列里等待”。调整参数后，这里的结论会跟着变化。
- 突发余量
- —
- 下游节奏
- —
- 主要代价
- —
令牌桶不是“每秒只能通过 N 个”
如果桶提前攒满了令牌，一次可以立即放过整桶容量；长期平均速率才受补充速率约束。
漏桶的容量购买的是时间
队列越大，越不容易溢出，但最后一项等待越久。把拒绝变成等待，并不等于没有代价。
同一个算法也会因业务变样
公共 API 常希望吸收短突发；短信供应商更怕瞬间打满下游。选型取决于要保护的边界。