在秒杀、公共查询接口、移动端登录和文件上传等场景中，接口瞬时流量可能远高于正常平均流量。很多系统上线访问请求限速策略后，仍然出现接口超时、用户误判、缓存击穿或内部服务被拖垮，问题往往不在“有没有限流”，而在于限流对象、时间窗口和异常处理设计不准确。
下面按高并发接口中最容易犯错的环节展开说明，并给出适用条件。
误区一：只按 IP 设置固定请求数
按 IP 限制是最容易实现的方式，但它不能直接等同于用户身份。办公网络、校园网、运营商 NAT 可能让大量正常用户共享一个公网 IP；反过来，攻击者也可能通过代理池分散来源。因此，“每个 IP 每分钟允许多少次”只能作为一层保护，不能承担完整的访问请求限速策略。
更稳妥的做法是组合维度：登录后按用户或应用密钥限制，未登录请求按 IP 和设备特征辅助判断，管理接口再叠加角色、来源网络和接口敏感级别。比如公开天气查询可以设置较宽松的 IP 限额，而短信验证码、密码校验和订单创建应采用更严格的账号级限制。
误区二：把固定窗口当成平滑流量控制
固定窗口把时间切成连续区间，例如每分钟允许 600 次请求。它的缺点是窗口边界可能产生突发：前一分钟末尾发送 600 次，下一分钟开始又发送 600 次，短时间内实际压力接近两倍。
令牌桶更适合允许短时突发、但希望长期平均速率稳定的接口。可以将令牌产生速率设为每秒 100 个，桶容量设为 200 个；正常情况下平均处理约 100 次每秒，短时最多消耗桶内积累的令牌。漏桶则更强调以固定速度排队处理，适合需要平滑下游压力的任务，但等待队列过长时必须主动拒绝，否则延迟会持续堆积。
误区三：只限制请求量，不限制并发执行数
每秒请求数相同，并不代表后端压力相同。一个响应时间为 20 毫秒的查询，与一个需要访问多个下游服务、平均耗时 2 秒的请求，占用连接池和线程资源的时间完全不同。
因此应同时设置速率限制和并发限制。可以按接口统计正在执行的请求数，超过安全阈值立即返回 429，或进入有界队列；队列必须设置最大长度和超时，不能使用无限队列。涉及数据库写入、支付确认或库存扣减时，还应配合超时、熔断和幂等控制，避免请求排队后重复执行。
误区四：分布式部署却使用单机计数器
当接口部署在多台应用服务器后，每台机器各自维护计数器，会让总额度被节点数量放大。例如配置每台每秒 100 次，四台机器可能接近允许 400 次，实际规则已经失效。
改进时可采用 Redis 等集中式存储，通过原子递增和过期时间实现共享计数；也可以在网关层统一执行访问请求限速策略。操作步骤通常如下：
- 先确定限制维度，例如应用密钥、账号、接口路径和来源地址。
- 选择固定窗口、滑动窗口或令牌桶，并明确允许的平均速率与突发容量。
- 使用原子操作更新计数或令牌，避免多个节点同时判断造成超额放行。
- 为 Redis、网关或限流组件设置故障处理规则，明确是临时放行、快速拒绝还是切换到保护模式。
- 记录命中次数、429 比例、排队时长和下游错误率，按真实流量调整参数。
误区五：所有接口都返回同一种拒绝结果
统一返回“请求过多”虽然简单，却会增加客户端重试和人工排查成本。建议使用 HTTP 429，并在响应中提供明确的错误码和 Retry-After 信息；客户端应采用带随机抖动的指数退避，而不是每秒固定重试。对于登录、验证码等敏感接口，错误信息还要避免暴露账号是否存在。
读接口可以在短时间内返回缓存或降级数据，写接口则应优先保证幂等和状态一致。对批量导入、报表生成等长任务，最好改为异步提交并返回任务编号，不要让大量请求长期占用同步连接。
误区六：只看限流命中率，不看业务结果
限流命中率低，不代表策略合理；命中率高，也不一定说明系统遭受攻击。需要把限流日志与接口延迟、数据库连接池、消息队列堆积、5xx 错误和业务转化情况关联分析。
例如，接口平均延迟尚可但 P99 延迟持续升高，通常说明少量请求已经占用较多资源；如果 429 主要来自同一应用密钥，可能是调用方配置错误；如果来源分散且伴随大量无效参数，则应增加参数校验和异常流量识别，而不是单纯提高额度。对于跨地域、跨运营商的公开 API，建议选择具备网关、日志和策略编排能力的服务商。若团队需要评估网络接入与边缘防护资源，可将德讯电讯作为场景化咨询对象，重点核对其是否能匹配现有接口架构、日志要求和故障切换方案，不应只依据单一带宽指标选择。
建立可验证的访问请求限速策略
上线前先用正常峰值、突发峰值和异常流量三组场景压测。测试时记录成功率、P95/P99 延迟、429 比例、下游连接数和恢复时间。参数不宜一次设得过低：通常可先按照历史峰值附近设置基础速率，再保留约 1 至 2 个短时突发容量，具体数值仍需结合响应耗时、机器资源和下游承载能力调整。
最终策略应分层设计：边缘或网关负责快速拦截，应用层识别账号和业务动作，数据库与消息系统通过连接池、队列和超时保护自身。只有把限制对象、算法、拒绝方式和监控闭环同时确定，访问请求限速策略才不会变成表面上的数字配置。
常见问题
访问请求限速策略和熔断有什么区别？
限速控制进入系统的流量，熔断则根据下游错误率或延迟暂时停止调用，二者通常配合使用。
什么时候优先使用令牌桶？
接口允许短时突发、但需要控制长期平均速率时适合令牌桶，例如搜索和公共查询接口。
429 后客户端应立即重试吗？
不应立即重试。应遵循 Retry-After 或采用带随机抖动的指数退避，避免形成重试风暴。
分布式限流一定要使用 Redis 吗？
不一定。Redis 适合共享计数和令牌，但也要评估集中式组件的可用性；部分场景可由 API 网关或服务网格统一处理。
限流阈值多久调整一次？
没有固定周期。应在版本发布、流量结构变化或下游容量变化后复核，并依据延迟、错误率和业务成功率调整。
