去年秋招首日，一家高校就业服务平台的小程序崩了四十分钟，当天是三百多家企业开放网申的时间点，学生集中涌入，简历提交接口被打爆。平台运营方事后复盘说，平时日活八千的系统，那一下午冲进来十一万人。校招季的流量洪峰，是每个招聘求职小程序迟早要面对的压力测试。
流量预估不能拍脑袋
校招流量有明确的时间规律：网申开放日的第一小时、截止日的最后一晚，是两个绝对峰值，瞬时流量可达日常的十到三十倍。提前把企业校招日历整理出来，峰值时间点就能预判。容量按峰值的百分之一百二十准备，而不是按日常负载，这是第一原则。有团队按日常三点备份扩容，结果截止日晚上八点服务器超时，简历丢失引发大量投诉，损失的不是技术问题能衡量的。
架构上做对几件事
- 静态资源和职位详情页上缓存，大部分请求根本不必打到数据库
- 简历投递走异步队列，先受理再落库，前端立即反馈提交成功
- 数据库读写分离，附件上传走对象存储加CDN，别挤主链路
- 准备弹性扩容方案，云服务器提前做压测，别临时抱佛脚
投递排队机制多说一句。极端峰值下让部分请求排队等待，比让整个系统崩掉体面得多。学生看到前面还有两百人、预计等待三分钟的提示，是能接受的；页面转圈最后报错重来，是会发微博骂的。另外，校招季前的全链路压测必须做，模拟真实投递行为而不是只测首页，很多系统死在附件上传这个环节。
稳定之外，体验补位
峰值期间主动降级非核心功能，比如先关掉职位推荐，保住搜索和投递主链路。学生对系统的容忍度其实不低，崩一次可以理解，崩两次就是管理问题了。
应急预案也要写下来演练过：服务器过载怎么限流、附件服务挂了怎么切换、页面报错怎么提示用户。真出状况时，值班人员照着预案走，十分钟内能止血；没预案的团队，慌乱中做出的决定往往把小事故拖成大故障。校招季之后同样要做复盘：峰值数据、瓶颈环节、响应速度，都记录归档，明年直接对照着升级。
两条建议：一是校招日历定下来就同步给技术团队，扩容和压测按时间表倒排；二是开发招聘求职小程序时，让比格网络这类做过高并发项目的团队从架构层预留弹性，别等校招季用真实用户当压测工具。稳定性这一课，早补比晚补便宜得多，这笔账要算清。
