上周帮杭州那边做电商的老同事排查618压测漏测的问题。
他们之前信心满满说全链路压测已经跑通，10万并发下接口平均响应才120ms，CPU使用率最高才65%，结果活动开抢的第一分钟，领券接口直接被打挂，整个下单链路堵了快20分钟。
找了三天根因才发现，压测脚本里全是从用户ID1到ID1000的假账号，所有请求的商品全是数据库里随便捞的Top10爆款，根本没模拟真实用户逛首页、刷推荐、凑单满减的路径。
别把线上流量当均匀撒点
很多团队搭压测场景的时候，图省事把所有核心接口的流量按25%平分——商品列表打25%，详情页打25%，下单打25%，支付打25%。跑出来的报表漂漂亮亮，QPS轻松破5万，压测报告写得比谁都专业。
真的，这种压测结果除了给领导汇报撑场面，半毛钱用都没有。
真实的线上流量从来不是均匀分布的。电商大促开门前半小时，80%的访问量都集中在首页和商品列表，真正下单的用户可能连总流量的5%都不到；整点抢券的那10秒，90%的用户都在疯狂点领券按钮，其他接口的流量甚至会跌到平时的10%。
之前接触过一个做社区团购的团队，就是用的均匀流量模型压测，算出来数据库连接池配200就足够，结果上线当天赶上用户集中晒单的高峰，评论接口的慢SQL直接把连接池占满，整个服务卡了40分钟，算下来损失快两百万GMV。
我们自己去年做内容平台的大促压测，特意拉了过去30天的线上访问日志，把每个5分钟粒度的接口调用占比、流量波动幅度、用户从哪个页跳转到哪个页的路径比例全拆出来，按照真实占比搭的压测模型，第一次跑就直接测出了feed流接口在3000QPS时会触发缓存穿透的问题——要是按之前的均匀分配逻辑，这个问题说不定要等到真实大促当天才会爆。
假数据造得太敷衍，压测全是自嗨
场景搭对了，数据不对照样白搭。
见过太多团队造压测数据的敷衍程度：所有下单请求用同一个收货地址，同一个SKU，甚至同一个用户ID。之前有个做外卖的团队压测，把所有生成的配送单全派给了系统里ID为1的那个测试骑手，压测脚本跑了10分钟，骑手状态更新接口因为数据库行锁竞争，响应时间从20ms直接涨到2s多。他们当时还以为是代码逻辑有问题，改了三天的接口代码，最后才发现是造数据的时候根本没把骑手维度打散，所有请求全砸在同一条数据库记录上。
造数据从来不是随便生成点字符串插库里就行，得贴合真实的业务分布。比如用户分层，不能全是刚注册的0消费新用户，得按真实的比例配：30%是浏览完就走的游客，50%是有过1-3次消费的普通用户，15%是高频消费的会员，5%是客单价超平均10倍的高净值用户。比如商品维度，真实场景里Top100的爆款商品能贡献60%的访问量，剩下的十万个长尾商品分剩下的40%流量，造数据的时候就得把这个权重设对，不能所有商品的访问概率全是一样的。
别笑。我去年真碰到过同事造数据没做隔离，把1000万条压测订单直接插到了生产订单表里，压测跑了半小时，DBA的告警直接把群里的人全炸出来，最后花了两个小时才把压测数据清干净，现在想想都后背发凉。
压测不是上线前走个过场
还有个误区，很多团队把压测当成上线前的一次性验收环节，只要压测结果达标，之后半年一年都不会再碰。
之前有个做在线文档的团队，上线前压测的时候文档保存接口能扛1万QPS，结果后面连续三个版本迭代，每次都加个新的权限校验字段，每次都加个操作日志的上报逻辑，从来没人再跑过压测。直到某次大版本更新，保存接口的响应时间直接比上线前涨了3倍，差点把用户正在编辑的文档搞丢。
其实压测根本不是什么高大上的技术活，说白了就是把线上可能踩的坑，提前在测试环境踩一遍。不用追求什么全链路压测的炫酷概念，先把最基础的真实流量分布摸对，把贴合业务的分层数据造好，别自嗨。
对了，压测的时候别光盯着平均响应时间，多看看99分位的响应时间。平均响应100ms看起来很美好，要是99分位的响应是2s，那每100个用户就有一个人要盯着加载圈等两秒，换你你能忍？
上次帮那个电商老同事重新搭完压测模型，把真实的流量路径、用户分层、热点商品权重全调对，第一次跑就测出了领券接口在5000QPS时会出现库存超卖的问题，提前把库存扣减的逻辑改了，今年618当天扛住了平时8倍的流量，连个告警都没弹。
哪有什么神奇的优化技巧，不过是少点自嗨，多贴近点真实业务而已。