限流机制

监控里 User 123 一小时调用了 15000 次，平均每秒 4.2 次，24 小时不间断、模式非常规律——这是一个自动化程序，不是普通用户。它进来之后，QPS 从 5 翻倍到 10，响应时间从 50ms 变成 150ms，CPU 从 30% 涨到 70%，其他用户都在被它拖慢。

限流要解决三件事。第一是为什么限：共享资源需要保护，公平性也需要保障，先给免费用户定下 1 次/秒的配额。第二是用哪种算法：固定窗口实现简单，但两个桶交界处容易各放行一点；滑动窗口统计当前时刻往前一段固定长度内的请求数，流量更均匀；令牌桶按恒定速率投放令牌、取到才放行，长期速率可控、短期允许突发，很适合对外 API。

第三是怎么落地：在 API 层实现限流中间件，把放行、拒绝和等待时间写进监控指标，并建立告警。效果是 User 123 的调用降到每小时 3600 次，QPS 回到 5、响应回到 50ms、CPU 回到 30%，被限流的用户还收到了升级套餐的通知。

读完你应该能对比三种算法的取舍，说清令牌桶为什么允许突发，也能为免费用户定出配额并把限流效果变成可观测的指标。