接口限流：先保护自己再谈体验

很多系统直到被打挂才想起限流。常见的触发场景有三种：第三方接口回调集中重试、某个客户端脚本死循环、活动期间真实流量突增。前两种是异常，第三种是业务。

限流放在哪一层

网关层做全局限流，挡住明显异常的流量，配置简单，适合作为第一道防线。

服务层做业务限流，比如同一账号每分钟最多提交几次，与业务语义绑定更紧密。

数据库层做保护，连接池上限和慢查询超时是最后的安全网，不能依赖它做常规限流。

阈值怎么定

先用监控数据看正常峰值，再留两到三倍余量。凭直觉设阈值，不是太松就是误伤。

限流触发时返回明确的状态码和重试时间，让客户端知道该怎么办，而不是直接超时。

把限流事件记进日志并做趋势统计，频繁触发说明容量或设计需要调整。

限流的价值在于把故障控制在局部。一个接口被打挂，不应该让整个系统跟着不可用。