问卷系统的并发与导出

把问卷链接发进五百人的微信群，前十分钟的提交量很可能占全天的一半。问卷系统的技术难点不在表单本身，而在这种脉冲式的提交峰值，以及事后的结果导出。 一、峰值怎么削 提交接口做三件事：前端提交后按钮置灰防重复点击；服务端按用户或 IP 做幂等，同一份答卷只收一次；入库异步化，请求先进消息队列，后台进程批量落库，数据库压力被拉平。没有队列条件的话，至少把校验和入库拆开，校验放前面快速拒绝，减少无效写入。数据库连接池在峰值前调大一档，但别超过数据库的 max_connections，否则两边一起拖垮。 二、导出走后台 几百份答卷直接导出没问题，几万份就会把 PHP-FPM（PHP 的进程管理器）或应用进程拖到超时。正确做法是导出任务进队列：用户点导出，接口把任务塞进队列立刻返回，后台进程生成 CSV 后提供下载链接。导出文件按日期命名并设过期清理，别让磁盘被历史文件堆满。夜间低峰还可以自动导一份当日数据： 0 2 * * * /opt/survey/bin/export.sh >> /var/log/survey-export.log 2>&1 三、存储设计 题目选项用单独的明细表存，别把整份答卷塞进一个 JSON 大字段，否则后面统计单题分布会很痛苦。答卷表按活动分表或按时间分区，导出时只查当前活动，速度快得多。必答校验前端做一遍、服务端再做一遍，纯前端校验挡不住脚本提交。 四、部署建议 图文问卷流量不大，高防云服务器 S4 足够，数据库单独设置每日备份。问卷有截止时间，活动结束后先把原始数据归档，再清理线上表，只保留统计结果的只读副本供查询。答卷数据导出两份，一份分析用，一份归档留存。 问卷系统的体验分水岭在交卷那一刻：提交快、不出错，答卷人的感受就是好的。峰值和导出这两处处理好，其余都是常规搭建。