商品维度限流的本质，是把“整个集群共用一个总闸”改成“每个SKU各有一路保险丝”：给热点商品单独配额、单独隔离、单独降级，单个爆款再猛也只能烧掉自己那一路，压不垮共享资源池。
很多团队第一次遇到大促事故,复盘时都会愣一下：集群CPU打满、数据库连接池耗尽、GC飙到停不下来，可翻遍监控发现，出问题的其实就那一个SKU，流量不是均匀洒下来的，它像洪水，永远往最低的那条沟里灌，集群限流挡的是总量，挡不住单点倾斜。
为什么一个爆款就能把集群打穿
流量分布天然是长尾的，平均值会骗人
商品维度的真实流量形态,用一句话概括：头部极热、腰部长尾、尾部几乎没人看，首页一个坑位、一场直播、一次补贴券投放，就能把某个SKU的QPS从几十推到几万，而集群的资源池是共享的线程池、连接池、缓存带宽、下游库存服务的接口配额，全都是公共财产。
公共财产被一个SKU霸占,其他商品就只能排队，用户的体感是“整个App卡了”，实际上只是某一件羽绒服在疯狂抢资源。
业内专家指出,电商大促期间的线上故障里，相当一部分源头指向单点热点未做隔离，而非整体容量不足，这句话的意思是：扩容解决不了倾斜，只有隔离才行。
单机限流和集群限流的区别，决定了爆款为什么还是压垮集群
这是最容易踩的认知坑,很多人配了限流就以为万事大吉，结果继续崩。
- 单机限流：每台机器各自计数，10台机器、单机阈值100QPS，理论上限1000QPS，但流量分配不均时，热key打到的那3台机器先被打满，其余7台很闲，总量没超，局部已死。
- 集群限流：全局统一计数，总量可控，但它只管“总共多少”，不管“谁在用”，爆款吃掉全部配额，长尾商品一样被误杀。
- 商品维度限流：在集群维度之上再加一层身份识别，按SKU（或SPU、类目）分配独立配额，总池子不超，单商品也不超。
三者的差异,落到表格里更直观：
| 维度 | 限流粒度 | 爆款影响面 | 配置复杂度 | 适用场景 |
|---|---|---|---|---|
| 单机限流 | 单实例 | 局部热点机器被打满 | 低 | 小流量、实例少 |
| 集群限流 | 全局总量 | 长尾被误杀 | 中 | 保护下游总容量 |
| 商品维度限流 | SKU/SPU/类目 | 仅该商品自身降级 | 较高 | 大促、秒杀、直播带货 |
行业共识认为,成熟的电商链路通常是三层叠加：网关做集群总量闸门，服务层做商品维度配额，下游存储再做一次兜底。
商品维度限流怎么配置：从SKU打标到规则落地的完整路径
第一步：给商品分层打标，别急着配阈值
没有标签就没有维度,先回答一个问题：哪些商品需要独立配额？
实操路径通常是离线任务 + 实时修正：
- 离线侧每天跑一次近7日成交、曝光、加购数据，输出热、温、冷三档SKU清单，写入配置中心。
- 实时侧订阅大促会场、直播预告、补贴券投放事件，把即将爆发的SKU提前5到10分钟升级为“预热点”。
- 冷门商品统一走默认配额,不为每个SKU单独建规则，避免规则表膨胀到几十万条。
标签粒度建议先做SPU、再做类目，SKU级别只给真正的高价值单品开小灶，规则条数控制在千级以内，否则配置中心推送和客户端刷新都会变慢。
第二步：规则怎么落到网关和RPC层
以Sentinel为例,热点参数限流是现成的商品维度能力，核心是给参数建索引：
ParamFlowRule rule = new ParamFlowRule("skuQuery")
.setParamIdx(0) // 第0个参数是skuId
.setCount(500) // 该SKU默认QPS上限
.setGrade(RuleConstant.FLOW_GRADE_QPS)
.setClusterMode(true); // 开集群模式，避免单机阈值失效
// 给个别超热SKU单独放宽或收紧
ParamFlowItem item = new ParamFlowItem()
.setObject("10086")
.setClassType("java.lang.String")
.setCount(2000);
rule.setParamFlowItemList(Collections.singletonList(item));
网关层用Nginx提取商品ID做key,是成本最低的第一道闸：
map $args $sku_key {
~skuId=(?<sid>[^&]+) $sid;
default "unknown";
}
limit_req_zone $sku_key zone=sku_limit:20m rate=800r/s;
这段配置的意思是：同一个skuId的请求共享每秒800次的桶，超出直接返回503，其他SKU完全不受影响，注意zone内存要按key数量给足，20m大约能放十几万个key。
第三步：配额从哪来，动态调整怎么做
配额的来源只有两个字：压测，单机跑一遍全链路，找到该商品链路最弱的一环通常是库存扣减或详情页的缓存穿透点反推安全水位，再乘上一个7到0.8的系数留buffer。
动态调整要设两条线：
- 自动扩容线：SKU被标记为预热点，配额自动上浮，上浮幅度由配置中心下发。
- 自动降级线：连续多个采样周期错误率超过阈值，自动把配额压回默认值，并触发缓存预热。
阈值别追求一次配准,先配一个保守值跑一周，看拒绝率曲线再调，这比拍脑袋靠谱得多。
大促期间热点商品限流方案：三道防线加一条兜底
场景化管理比规则本身更重要,大促的真实节奏是：零点前30分钟流量爬坡，零点瞬间冲顶，之后高位震荡。
第一道防线在接入层：按邮编、用户ID、商品ID三个维度同时限流，优先保商品维度，因为它是热点传播的载体。
第二道防线在业务层：热点商品走独立线程池，和普通商品物理隔离，这一步比限流更狠限流是拒绝，隔离是“你可以慢，但别拖累别人”。
第三道防线在存储层：热点商品的库存扣减走独立Redis实例或分片，别和普通商品挤在同一个cluster里。
兜底手段是排队和降级,秒杀类请求进令牌桶排队，等待超过阈值直接返回“活动太火爆”；详情页在极限情况下切到静态兜底页，用户能看不能抢，系统活着。
北京电商系统限流改造：存量系统该按什么顺序动
北京电商系统限流改造的典型难点不在技术选型,在于老系统里商品ID没有贯穿全链路，很多请求进来时是商品ID，出去时变成了类目或店铺维度，链路中间断了好几截。
改造顺序建议这样排：
- 先补透传：把skuId写进RPC的隐式参数或Trace上下文，保证每一跳都能拿到。
- 再接网关：网关层加商品维度限流，成本最低，见效最快，还不改业务代码。
- 最后改服务层：服务层的配额要和网关的配比对得上，网关放800，服务层收到1200，说明中间有放大，得查。
- 灰度范围从1%到10%再到全量，每档观察至少一个大促周期。
地域上还有个小细节：北京、上海多机房部署时，集群限流模式依赖统一的Token Server，跨机房延迟会抬高限流判定耗时，优先在同机房内做集群限流，跨机房靠总量配额兜。
几个高频误区，顺手排掉
- 只配阈值不配隔离：限流是拒绝，隔离是分资源，两个动作解决的是不同问题。
- 规则写死在代码里：大促改阈值要发版，等不起，规则必须走配置中心。
- 忽略被限流商品的用户体验：直接抛500不如返回可读的降级文案加一个稍后重试入口。
- 忘记校验下游配额：上游限了，下游没限，压力只是换了个地方爆。
商品维度限流不是给系统加锁,是给每个爆款划一块自己的地，地界划清楚了，再大的流量也只在自家院子里折腾，集群这栋楼才塌不了。
商品维度限流落地Q&A
Q1：商品维度限流和集群限流必须二选一吗？
不冲突,是包含关系，集群限流管总量，商品维度限流管分布，正确的做法是总量闸门在外层、商品配额在内层，两层同时生效，只做一层，要么总量失控，要么长尾误杀。
Q2：SKU数量上百万，规则表怎么维护？
不逐条建,用“类目默认配额 + 热点清单单独覆盖”的两级结构，热点清单每天由离线任务刷新，量级控制在千级，查询时先命中覆盖规则，未命中回落到类目默认值，规则表规模就和SKU总量解耦了。
Q3：限流阈值设多少才安全？
阈值由压测反推,不由经验拍定，单机跑一遍目标商品链路，找到最先出现耗时陡增或错误率抬升的那个点，取该点承载能力的七到八成作为上限，再在真实流量中观察一周拒绝率收敛情况。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/772089.html
