上周跟南京某电商团队的测试组撸串，领头的哥们喝了半杯冰啤酒就拍桌子吐槽，去年双11压测全绿通过，结果零点流量一冲，数据库直接打满，告警短信炸了一晚上。查了三天才找到根因——压测用的全是刚生成的空白用户数据，连购物车都没一个，模拟的流量还是均匀分布的，完全没还原真实大促时80%请求挤在支付、刷优惠券页面的状态。
你以为的压测场景，可能从一开始就偏了
太多团队做压测的逻辑特别简单：把预期峰值QPS乘以1.5，跑半小时，响应时间达标、错误率低于1%就算过。
完全不考虑流量的真实分布。
大促零点的流量不是平的，是尖的——前一分钟可能还是日常流量，后十分钟直接冲到峰值，之后还要维持半小时的高位，再慢慢回落。还有大量的黄牛脚本、爬虫请求混在正常用户流量里，占比甚至能到20%。
之前有个做生鲜电商的团队，压测的时候把所有接口的流量按1:1:1分配，结果上线后发现，用户全在挤着刷新优惠券页面，商品详情接口的QPS是预期的3倍，支付接口反而只有预期的一半，直接把缓存层打穿了。
假数据骗得了工具，骗不了线上流量
说完场景说数据，这才是绝大多数团队的重灾区。
我见过最离谱的造数据方式，是脚本批量insert100万条用户，昵称全是test开头，收货地址全填南京市玄武区某路100号，订单状态全是已支付，连商品ID都是随便编的不存在的值。
这不叫压测，这叫给性能工具跑空转。
我之前在支付团队的时候也踩过这坑。当时压测风控系统，造的银行卡号全是测试用的虚拟号，结果风控规则直接把所有压测请求标记为高风险，拦了90%的流量，跑了10分钟QPS才上去50，我们还以为是风控逻辑有性能瓶颈，查了三天才发现是数据不对。
更常见的问题是数据分布和真实业务完全脱节。比如压测用户订单查询接口，所有压测用户的历史订单数都是0，缓存命中率直接拉到100%，测出来的响应时间只有50ms，结果上线后真实用户一上来，平均每个用户有20多笔历史订单，缓存命中率只有30%，接口响应时间直接涨到800ms。
能扛住真实流量的压测，全是贴着业务长出来的
说实话，我从来不推崇什么标准化的压测模板，每个业务的流量特点、数据分布都不一样，抄别人的方案没用。
场景设计别拍脑袋，直接抓线上的真实流量日志就行。把过去30天、甚至过去几次大促的日志导出来，按时间维度拆分流量曲线，模拟从预热到峰值再到回落的完整过程，甚至要把爬虫、黄牛的异常流量也算进去——别觉得这些流量占比小，真到峰值的时候，这些垃圾请求能占走30%的系统资源。
数据构造更要抠细节。核心业务字段的分布必须和线上完全对齐：比如用户等级里普通用户占92%，黄金会员占5%，钻石会员占1%，剩下的2%是黑产账号；商家库存里，小商家的库存大多在100-500之间，连锁大商家的库存才会上万，不能全造库存99999的商家数据。
还要记得留一点“脏数据”。真实业务里永远有2%-3%的异常数据：比如用户填了错误的手机号，订单是已取消状态，商品已经下架。如果压测数据全是完美的正常数据，就测不出系统处理异常场景的性能。之前有个社区团购的团队，压测的时候所有商品都是上架状态，上线后发现大量用户点到下架商品，系统每次都要查库判断状态，缓存命中率骤降30%，接口直接慢了4倍。
不过话说回来，也不能直接用线上的真实用户数据，隐私合规的红线不能碰。一般我们的做法是把线上数据做脱敏处理，手机号、身份证号这些敏感字段全部替换成随机值，但是保留用户行为、订单状态、商品属性这些核心业务字段，既合规，又能保证数据的真实性。
别为了压测方便，把风控、限流、缓存的逻辑全关了——我见过有团队压测的时候把这些中间件的保护全关了，测出来的QPS高得能吹半年，结果上线半小时就崩，这有啥意义呢？
上次跟我们撸串的那个电商团队，回去花了一周时间重新调了流量模型，用脱敏后的线上真实数据跑了三轮压测，今年618的时候，系统扛住了平时5倍的峰值，数据库CPU最高才到62%，连个告警都没触发。