TG咨询促销活动期间，网站防护阈值设置不能简单理解为“流量超过某个数字就拦截”。同一站点中，商品详情、搜索、购物车、下单和售后查询的资源消耗不同；同一个接口在平日、预热期和正式开售时也可能出现明显差异。合理做法是先建立可观测的并发基线，再按访问主体、接口类型和风险等级分层处理。
先确定阈值依据，而不是直接套用数字
活动前至少准备过去数周的访问记录，重点观察工作日、周末、整点促销和推送后的变化。建议分别记录每分钟请求量、并发连接数、响应时间、错误率、队列长度以及关键业务成功率。没有历史数据的新站点，可以先用容量测试和小范围预热得到初步范围，但应把初始阈值设得保守，并安排人工观察。
按接口消耗划分等级
- 低消耗接口：商品说明、活动规则、门店地址等主要返回固定内容的页面，通常可以承受较高请求量，适合配合边缘缓存和较宽的速率限制。
- 中消耗接口：搜索、筛选、价格计算等需要查询数据库的功能，应按照查询复杂度设置独立阈值，不能与普通页面共用一个数字。
- 高消耗接口：库存锁定、订单创建、优惠资格校验等会触发事务或排队的接口，应采用更严格的速率限制，并优先保护已登录且行为正常的用户。
例如，某接口平时每秒约处理10至20次请求，活动期间预期增长到平时的3至5倍，可以先把软预警放在约30至60次每秒，再根据响应时间和错误率调整。这个范围只适用于容量、查询复杂度和缓存命中情况相近的环境，不能跨站点照搬。
用分层网站防护阈值设置替代单点拦截
有效的限流策略通常至少分为四层：全站、接口、用户主体和风险行为。全站阈值用于防止入口被突然打满；接口阈值用于保护数据库和业务队列；用户主体阈值用于限制单个账号或设备的异常重复操作；风险行为阈值则处理短时间内快速切换页面、集中提交和大量失败请求等情况。
推荐的执行顺序
- 先采集最近5至15分钟的请求量、延迟和错误率，确认增长是正常活动流量还是突发异常。
- 当请求量接近容量上限的约60%至70%时，启用软限制，例如排队、延迟处理或降低非关键接口的调用频率。
- 当关键接口延迟持续升高，或错误率达到预先设定的告警线时，收紧高消耗接口的速率限制，保留商品浏览、订单查询等必要路径。
- 只有在明显的自动化冲击、连接耗尽或资源持续饱和时，才启用更强的挑战或拦截，并为正常用户保留可验证的通道。
阈值应绑定时间窗口。短窗口适合发现瞬时突发，常见可从10秒、1分钟和5分钟分别观察；长窗口适合判断活动高峰是否已经稳定。单看1秒内的峰值容易误判，单看15分钟平均值又可能错过瞬时冲击。
设置动态阈值，避免活动开始就误伤用户
促销活动的流量变化往往不是匀速上升。短信、站内信或直播导流可能在几分钟内带来集中访问，因此网站防护阈值设置应至少准备“预热、开售、稳定、异常”四种状态。
| 状态 | 重点观察 | 处理方式 |
|---|---|---|
| 预热 | 访问增长速度、页面延迟 | 扩大静态内容承载能力，保持接口限制相对宽松 |
| 开售 | 队列长度、下单成功率、数据库等待 | 优先保护订单和库存链路，延后非关键查询 |
| 稳定 | 持续请求量、用户完成率 | 根据实际数据逐步放宽或收紧限制 |
| 异常 | 失败请求比例、重复请求、资源饱和 | 提高风险评分，缩短限制窗口并保留人工放行机制 |
动态调整不等于每分钟随意改规则。可以规定每次调整幅度，例如在确认业务指标稳定后，将某接口阈值上调约10%至20%；若延迟和错误率连续两个观察周期恶化，则回退到上一个安全值。变更必须记录时间、原因和影响范围，便于活动后复盘。
如何减少误拦截并验证保护效果
保护效果不能只看拦截了多少请求，还要看正常用户是否能够完成关键流程。建议把成功率、平均响应时间、排队放弃率、客服反馈和人工抽样结果放在同一面板中。若限制后资源使用下降，但订单完成率也明显下降，说明网站防护阈值设置可能过于激进。
对于企业网络、移动运营商共享出口或大型校园网络，按单一来源地址限流可能把多个正常用户视为一个主体。更稳妥的做法是结合账号、会话、设备稳定标识和请求路径，并将这些信号用于风险评分，而不是仅凭一个字段直接封禁。未登录用户可以采用较宽的浏览限制，对提交订单、领取权益等高风险动作再提高验证强度。
活动前应进行一次分阶段演练：先验证软限制是否生效，再验证高峰时关键接口能否保持可用，最后测试规则回退。演练不宜只压测首页，还要覆盖搜索、购物车、订单查询和售后入口。每项规则都应明确负责人、启停条件和回退方式。
常见问题
网站防护阈值设置越低越安全吗？
不是。阈值过低会造成大量误拦截，降低转化并增加客服压力。安全目标应是让异常请求受到限制，同时保持关键业务路径可用。
没有历史流量时如何设置？
先通过容量测试获得可承受范围，再选择约50%至70%的保守起点，并在预热阶段持续观察。正式活动前不要一次性放开到理论最大值。
是否可以全站使用同一个限制值？
不建议。静态展示、搜索、订单创建等接口的资源消耗不同，应采用分接口、分主体的速率限制。
什么时候应该临时放宽阈值？
当请求量上升但延迟、错误率和关键业务成功率仍稳定时，可以小幅放宽，并设置观察窗口。指标恶化时应立即回退，而不是继续追求更高吞吐。
归根结底，网站防护阈值设置应服务于业务可用性，而不是单纯追求更强拦截。用并发基线确定起点，用分层规则保护高消耗接口，再通过实时指标和可回退机制校正，才能在促销高峰中兼顾承载能力、用户体验与风险控制。
