最近公司上线了一个新项目，叫‘话题带货计划’，市场部搞得挺热闹，短视频、直播、社群都在推。作为负责后端服务器维护的，我原本以为跟我们关系不大，结果第一波活动一开，服务器直接炸了。
流量猛增，不是好事都得管
那天晚上八点刚过，监控系统就开始报警。QPS（每秒查询数）从平时的200左右，一下子冲到3500。数据库连接池被打满，Nginx 日志里全是 502 Bad Gateway。运维群里消息刷屏，开发同事电话一个接一个打过来问是不是网络出问题了。
查了半天才发现，是带货页面的接口被疯狂调用。前端为了做“实时销量滚动”，每隔两秒就请求一次订单数据。直播间一喊“还有最后100件”，用户全涌进来刷页面，接口瞬间被挤爆。
从日志里扒出真实反馈
等系统稳下来，我们抽了几个小时的日志做了个简单分析。发现一个有意思的现象：虽然访问量暴涨，但真正完成支付的订单只占总请求的不到7%。大部分用户就是点进去看看，刷几下就走了。
更夸张的是，有接近三成的请求来自同一个User-Agent，明显是脚本在刷。估计是有人想抢限量款，写了自动化工具。这波操作不仅没带来多少成交，反而把服务器压得喘不过气。
优化之后的变化
后面我们跟产品和技术开了个会，做了几件事：接口加了频率限制，把轮询改成了WebSocket推送，静态资源上了CDN。还把带货页面单独拆到独立的服务集群，避免影响主站。
第二次活动开始前，我们提前扩容了负载。结果这次虽然流量比上次还高，但服务器稳得很。CPU 最高也就跑到65%，数据库也没告警。最关键的是，成交转化率从7%提到了12%，说明真正的买家变多了，刷屏的少了。
数据不会说谎
现在每次活动结束，我都习惯翻一遍访问日志和响应时间图表。真实的用户行为藏在里面——哪些时段最忙，哪个接口压力最大，甚至能看出来宣传话术有没有戳中痛点。
比如有一次主播说“点击下方链接马上抢”，那五分钟内的跳转量直接翻倍。但链接打开后跳出率也高，一看是页面加载太慢。后来我们把首屏资源压缩了一半，再推同样的话术，留存明显变好了。
所谓‘话题带货计划效果反馈’，光看销售数字不够。服务器的响应码、延迟、并发连接数，其实都是用户态度的另一种表达。系统不崩，不代表做得好；系统崩了，也不代表没效果。关键是能不能从乱流里捞出真实信号。