每秒10万个请求砸过来，你的服务器能撑几秒？2023年某头部电商大促期间，一个未设限的支付接口在47秒内被刷爆，直接损失3400万订单。这不是攻击，是正常用户+爬虫+羊毛党的混合流量——没有限流（Rate Limiting），现代系统就像没有闸门的泄洪道。
限流的本质很简单：规定"Y时间内最多X次请求"。但简单的规则背后，藏着一整套生存哲学。
Token Bucket：允许你"透支"，但得还
想象一个不断往里投币的存钱罐。罐子的容量是100枚，每秒自动补充10枚。你可以一口气花光100枚买个大件，但之后每秒只能花10枚——这就是Token Bucket（令牌桶）的工作逻辑。
它聪明在"弹性"。某视频平台用这套算法处理上传请求：普通用户突传10条4K视频，系统放行；但想持续刷量？门儿没有。令牌耗尽后，第11条视频直接排队或拒绝。
具体参数怎么设？原文给出的典型配置是：桶容量100， refill rate（补充速率）10/秒。这意味着用户瞬间爆发100请求被允许，但长期平均必须压在10/秒以下。这种"先松后紧"的策略，比一刀切更符合真实业务场景。
Leaky Bucket：匀速排队，拒绝插队
与Token Bucket的弹性相反，Leaky Bucket（漏桶）像个纪律严明的流水线。请求进来先排队，以固定速率"漏"出去处理。桶满了？新来的直接溢出丢弃。
某金融交易系统选了这个方案。理由很现实：他们不能容忍任何突发，哪怕牺牲一点响应速度，也要保证每秒处理量绝对平稳。漏桶的缺陷也明显——它无法应对合法流量激增，大促时容易误杀。
两种算法没有优劣，只有场景适配。Token Bucket适合"偶尔浪一下可以"的业务，Leaky Bucket适合"必须稳如老狗"的场景。
分布式限流：单机思维死在微服务时代
当你的服务部署在12个可用区、800台实例上，单机的限流计数器就成了笑话。用户A的请求被负载均衡随机打到实例1和实例2，两台机器各自计数，限流阈值直接翻倍失效。
解决方案是集中式存储。Redis成了行业标配：每次请求先查Redis计数器，原子性递增，超过阈值即拒。但这里藏着延迟陷阱——网络往返多了几十毫秒，高频场景下Redis本身可能成为瓶颈。
更激进的方案是本地缓存+异步同步。每台机器先用自己的内存计数器快速决策，定期把消耗量上报中心。牺牲一点精度，换回十倍性能。某云厂商的内部数据显示，这种"最终一致"方案把限流延迟从15ms压到了0.3ms。
限流的反噬：误杀与用户体验
2022年某社交App上线新限流策略，把验证码接口压到1/分钟。本意是防羊毛党，结果正常用户注册时被反复拦截，次日留存率暴跌23%。技术团队复盘时发现：他们没区分"同一设备"和"同一IP"，网吧用户集体中招。
精细化的维度设计成了新战场。现代限流系统至少支持四层维度：用户ID、设备指纹、IP地址、业务类型。某头部云服务的控制台显示，其企业客户平均配置11.7条限流规则，最复杂的游戏客户有340条。
返回什么错误也讲究。直接抛503？用户以为服务挂了。好的实践是429状态码（Too Many Requests）+ Retry-After头，告诉客户端"多久后再试"。某出行App把这个时间窗口动态化：高峰期提示"60秒后重试"，平峰期"5秒即可"，用户投诉率下降67%。
从防御到博弈：限流的进化
早期限流是"挡子弹"，现在成了"做生意"。某内容平台的推荐接口，对不同用户等级实施差异化限流：免费用户100/天，会员1000/天，企业客户无上限。限流阈值直接写进了定价策略。
更隐蔽的是"柔性限流"。不直接拒绝，而是降级——返回缓存数据、简化计算逻辑、关闭非核心功能。某搜索引擎在流量洪峰时，会把结果排序的机器学习模型切换为轻量规则引擎，查询延迟从120ms降到40ms，用户几乎无感知。
这种设计哲学延伸到架构层面。Netflix的Chaos Engineering（混沌工程）团队定期模拟限流失效，验证系统在极端情况下的降级路径。他们的内部文档写道："我们不测试限流是否工作，测试的是限流失效后系统会不会优雅地烂掉。"
回到开头那个电商事故。事后复盘显示，他们的支付接口确实配置了限流，但阈值设得太高——5000/秒，而单实例实际承载只有800/秒。限流成了摆设，灾难如期而至。
你的系统限流阈值，是基于压测数据，还是拍脑袋定的？上次验证这个阈值的有效性，是什么时候？
热门跟贴