上个月接了个电商客户的咨询，对方的技术负责人一上来就倒苦水：之前全链路压测跑出来系统扛10万QPS毫无压力，结果618当天刚到3万，数据库直接挂了，客服电话被打爆，损失了几百万。
我翻完他们的压测脚本和报告，差点气笑。
别把脚本回放当真实场景
所有虚拟用户的操作路径完全一致，没有任何随机跳转，请求间隔全是固定的100毫秒，连用户浏览商品的停留时间都一模一样。这哪是真实用户？这是机器人阅兵啊。
真实用户哪有这么规整的？大促当天一半人蹲在秒杀按钮前反复刷新，有人领完优惠券直接退出去，还有人下单到一半想起没填地址，退回去填完又回来。他们的压测脚本里，连这些路径的占比都没摸清楚，测出来的结果除了能给领导看，半毛钱用没有。
这里的核心问题，就是场景设计脱离真实流量分布。很多团队做场景设计，习惯拿通用的电商路径套，根本不去拉自己家的真实流量日志。你家的用户是喜欢先看直播还是先搜商品？整点秒杀的流量占比是多少？这些数据不扒出来，压测场景就是空中楼阁。
对了，还有个坑，很多人压测的时候把思考时间设成固定值，要么全是1秒，要么全是3秒，正确的做法是拉真实的用户行为日志，把停留时间的分布做成随机变量，比如30%的用户停留1秒，50%停留3秒，20%停留10秒以上，这样压出来的结果才靠谱。别总拿脚本回放的结果当圣旨，真实用户的操作，可比你写的脚本野多了。
假数据比没有数据更害人
说完场景，再说说数据构造的坑。我见过最离谱的一个团队，压测的时候造了1000万条商品数据，每个SKU的库存都是1000件，用户数据全是随机生成的手机号，连用户的历史下单记录都没有。结果压测的时候，数据库的慢查询率只有0.1%，锁等待率更是低到可以忽略。
别不信。
真到大促当天，90%的下单请求都集中在那50个爆品上，所有请求都抢这几个SKU的库存行锁，锁等待率直接飙到32%，数据库连接池瞬间打满，整个系统直接雪崩。我当时看到他们的库存数据，直接问他们，你们家大促真的会每个SKU都有1000件库存？对方技术负责人愣了半天，说好像不是，爆品都是备货10万件，滞销品连10件都没有。你看，这就是想当然造数据的下场。
还有个细节，很多人造数据的时候，直接把生产数据脱敏了就用，这其实也有问题。生产数据里的历史订单，很多都是几年前的，压测的时候根本不会触达这些数据，但是你把这些数据全导进去，数据库的存储成本翻了好几倍，压测的时候缓存命中率反而降了，完全得不偿失。正确的做法是，把和核心业务路径相关的数据造足，比如爆品的库存、高等级用户的优惠券、经常被查询的收货地址，这些数据要和真实的数据倾斜分布一致，那些压测根本不会用到的冷数据，少造点没关系。
落地别追求一步到位
说实话，很多团队搞压测，一开始就追求100%的场景覆盖率，结果搞了半个月，连核心路径都没测明白，钱花了不少，啥问题都没发现。
其实完全没必要。
先把最核心的路径摸清楚，比如你们家的核心业务是秒杀，那就先把秒杀场景的流量占比、数据分布搞对，先把这个场景的性能打测准，能扛住真实大促的流量，就已经解决了80%的问题。剩下的边缘场景，比如用户反馈、客服咨询这些，流量占比本来就不到5%，就算崩了影响也不大，完全可以后面再补。
哦对，还有个小技巧，压测的时候不要一上来就跑满全量流量，先从10%的真实流量开始，逐步往上加，每加一档就看看数据库、缓存、应用服务器的指标有没有异常，别一上来就跑10万QPS，直接把生产库打挂了，那可就尴尬了。
性能压测这东西，从来不是靠工具堆出来的，核心是你能不能真的搞懂自己家的用户是什么样的，系统在真实流量下会遇到什么问题。别总想着套通用模板，多扒扒自己家的流量日志，比看十篇技术教程都有用，对吧？