德讯高防云高并发业务遭遇恶意请求的限流策略，重点不是简单地“少放请求”，而是识别哪些请求消耗大、来源可疑或重复异常，再按风险逐层处理。只按总请求数设一个门槛，可能让正常用户和自动化攻击一起被拦；完全依赖单一来源标识，也容易被轮换身份绕过。
先按请求特征分层，而不是只看总量
限流规则可从四个维度组合：请求路径及计算成本、用户或会话身份、单位时间内的行为频率、业务操作优先级。例如，读取缓存中的公开信息与执行复杂检索，资源成本不同；重复尝试登录与正常浏览，行为风险也不同。规则越贴近具体接口，越能避免低成本流量拖累高成本操作。
为不同风险设置不同处置
- 普通读取：按接口和身份设置基础速率上限，超过后短暂排队或返回限流提示。
- 高成本请求：使用并发数上限保护数据库、搜索服务等下游资源；这与单位时间请求数限制不同，适合少量但执行时间较长的任务。
- 可疑行为：对短时重复提交、连续失败等模式提高限制强度，必要时要求额外验证，不必立即封禁所有同来源请求。
- 关键操作：为确认、提交等核心请求保留容量，避免低优先级查询耗尽全部处理能力。
组合算法，避免门槛过硬
令牌桶允许短暂突发，适合有自然流量波峰的接口；滑动窗口统计一段连续时间内的请求，更便于约束高频行为，但需要考虑计数存储和分布式一致性。对于耗时任务，可再加并发闸门：正在执行的任务达到上限时，不继续无界地占用工作线程。
限流标识也要组合使用。可按账户、会话、来源网络和接口分别计数，并为可信身份与匿名请求设置不同规则。单靠来源地址容易误伤共享网络中的用户；单靠账户则挡不住批量注册或轮换账户。多维计数能提高绕过成本，但会增加状态管理开销。
从观测到上线的操作步骤
- 盘点接口：列出请求频率、平均及较慢请求耗时、下游依赖和业务优先级，先找出容易造成资源堆积的路径。
- 建立基线：观察不同时间段的正常流量分布，并结合压测确认服务容量。阈值应按接口和实际容量确定，不直接套用统一的每秒请求数。
- 先记录、后拦截：以影子模式记录哪些请求会触发规则，核对正常用户是否会被误判；再对低风险规则小范围启用。
- 返回可恢复的结果：适用时使用 HTTP 429，并提供合理的重试提示；客户端应采用退避重试，避免收到拒绝后立刻重复请求。
- 持续复核：监控拒绝比例、接口延迟、队列长度和下游错误。流量形态或容量变化后重新校准，并为误判保留人工排查路径。
这里的高并发业务遭遇恶意请求的限流策略，应同时考虑公平性和保护效果：限制过松，资源仍会被异常请求挤占；限制过严，突发的正常访问也会失败。分层规则、清晰的响应和持续校准，比一次性设置全局硬阈值更可靠。
常见问题
限流和封禁有什么区别？
限流通常控制一段时间内可通过的请求，适合流量超标但身份未必恶意的情形；封禁针对明确风险更高的对象，影响更强，应有复核和解除机制。
所有接口都应该返回 429 吗？
不一定。请求频率受限时常用 429；若服务暂时过载，也可能返回 503。应结合实际原因和客户端处理方式，避免错误状态让调用方持续重试。
怎样减少误伤正常用户？
按接口、身份和行为分层，先观察规则命中情况，再逐步启用；同时为关键操作保留容量，并检查共享网络、批量任务等正常流量场景。
限流阈值多久调整一次？
没有适用于所有业务的固定周期。新增接口、容量变化、流量模式改变或误拒绝增多时应及时复核；平稳运行时也要定期查看指标和规则命中记录。