系统级的第一道闸门
端上削峰拦的是重复点击与无意流量，但脚本不点按钮、直接打接口——系统的第一道防线必须自己站住。网关是所有流量的必经之路，在这里做三件事：限流决定系统最多接多少，防刷决定谁来得太频繁，黑白名单决定谁根本不该来。网关层微服务系列里讲过路由与过滤器链，这一篇聚焦秒杀场景的特殊配置。
入口限流：按容量放行
秒杀接口的限流值不来自拍脑袋，来自压测：全链路压测测出系统安全容量，比如 2 万 QPS，网关就按 2 万放行——令牌桶匀速发牌，超出的请求不进系统，直接返回排队页或售罄页。两个配置要点：限流规则按接口单独配置，秒杀接口的阈值远小于普通接口，互不影响；阈值进配置中心，活动期间随时可调——发现下游吃紧，先把入口阀门拧小，这比事后扩容快得多。
// 网关限流：令牌桶，秒杀接口独立配置
filters:
- name: RequestRateLimiter
args:
redis-rate-limiter.replenishRate: 20000 # 稳态放行速率（压测得来）
redis-rate-limiter.burstCapacity: 40000 # 瞬时容忍突发
key-resolver: "#{@userKeyResolver}" # 按用户维度限，不是全局一刀切
// 被限流的请求返回 429 + 排队页地址，而不是裸报错防刷三板斧
频次控制按维度交叉：IP 维度——单 IP 秒级窗口限频，对付最粗糙的脚本；设备维度——设备指纹限频，穿透换 IP 的脚本；账号维度——单账号参与次数与下单次数上限。单维度都好绕（IP 池、设备农场），交叉才是关键：同一设备换一百个账号、同一账号换一百个 IP，交叉维度下都会露出马脚。频次数据用 Redis 原子计数，窗口用滑动窗口统计更精确。
黑名单与白名单
已知作恶的直接进名单：命中风控的设备与账号、历史黄牛、异常代理网段——网关过滤器查名单命中即拦，名单从风控中心实时下发到 Redis，网关本地再缓存一份降低延迟。白名单同样重要：内部压测账号、特定渠道用户需要确定性放行时，走白名单旁路。名单是动态的：活动进行中持续更新，误杀的及时捞出，新发现的实时加入——名单管理的本质是把风控的判断能力前置到入口。
排队：把硬拒变成等待
超过容量的流量不能一拒了之——几十万用户同时收到"系统繁忙"，舆情立刻爆炸。排队方案把硬拒变成等待：超容量的请求进入虚拟排队，前端展示"您前面还有 N 人"，后台按消化能力逐步放行。实现可以轻可以重：轻量版用 Redis 计数器分配排队号，超出的直接显示预计等待；重量版做真正的消息队列排队。排队的意义不在公平，在把不可控的洪峰转成可控的消化节奏。
网关拦下的是"来得太猛的"，还剩一类更难缠的——"伪装成真人的"。下一篇讲风控：黄牛与脚本的对线。
评论 (0)