问卷系统真正难的不是访问量，是截止前十分钟：提交风暴、半途作答和导出一致性怎么一起解决

截止前十分钟：页面能打开，后台却对不上数

一份内部满意度问卷发放给一万两千名员工，回收窗口两周。前十三天每天的提交量都很平，看板上的 CPU、内存、带宽全在低位运行，没人觉得这套系统有什么隐患。截止日当天下午五点五十到六点，提交量突然冲到平时的几十倍——不是因为首页被大量访问，而是绝大多数人把填写动作压到了最后十分钟。

接下来出现的现象很典型。页面始终能打开，没有 5xx 报错，监控里的响应时间只是略微上抬；但后台显示的已回收份数与数据库里统计出来的行数不一致，导出任务跑到一半超时，重跑一次后导出的行数又和上一次不同；人工核对时发现同一名员工留下两份答卷，内容略有差异。三个问题同时冒出来，看上去彼此毫无关联。

把它们当成三个独立故障分别排查，会白白消耗一整夜。它们共享同一个根因：这套系统的容量是按访问量规划的，而故障全部发生在写入上，并且发生在三种性质完全不同的写入上。把性质不同的写入当成同一种写入来做规划，是问卷类系统在集中提交时对不上数的根本原因。

这个问题在自建问卷与表单类系统里格外集中。LimeSurvey、Formbricks 这一类工具都可以自托管，部署门槛并不高，真正的差别出现在回收方式上：问卷是有截止时间的，而有截止时间就意味着写入不是均匀发生的。

把「访问量」和「提交量」拆开看，瓶颈的位置立刻变了

普通内容站点的读写比例在时间上是稳定的：有人访问就有一次读，偶尔写一条评论或一条日志。问卷系统不是这个形状。它在两周里可能被访问五万次，但真正产生业务价值的写入次数等于有效答卷数，中间隔着大量"打开又关掉""填了一半走掉"的行为。

更关键的是，这两类行为在时间轴上完全错位。访问量在问卷发布后的头两天达到峰值，随后缓慢衰减；提交量则在截止时间前形成一个陡峭的尖峰。如果你按发布首日的访问峰值来估算容量，算出来的资源量会远远大于集中提交那一刻真正需要的写入能力；反过来，如果你按总人数除以总天数得到的日均提交量来估，又会在最后十分钟被瞬间击穿。

所以第一步不是加机器，而是把两个指标在监控上彻底分开：页面与题目的加载请求数，和落到数据库上的写入请求数，必须是两条独立的曲线，各自有自己的峰值、均值和告警阈值。很多问卷系统上线后只配了请求量告警，结果尖峰期间告警一直很安静，直到有人发现导出的数字不对，问题才暴露。

拆开之后还会看到一个容易被忽略的事实：提交尖峰期间，页面加载请求反而可能不高。因为绝大多数人早已打开过页面，留在最后十分钟的动作只有点提交。也就是说，这一刻系统的读压力在下降、写压力在暴涨，而你的容量模型如果建立在"读压倒一切"的假设上，缓存命中率再高也帮不上忙。

四个写入点各自的形状：加载、自动保存、最终提交、导出统计

把问卷系统的数据流动拆开，可以分成四个性质完全不同的写入点。它们写的数据不同、并发形状不同、失败时的表现也不同，理应分别设计。

第一个是页面与题目加载。这是典型的读多写少，题目结构、问卷文案、跳转逻辑都可以在服务端或边缘缓存，写入部分可能只有一条访问记录。它扛得住高并发，也正因为扛得住，常常给人"系统很健康"的错觉。

第二个是部分作答的自动保存。为了防止用户填到一半丢失，前端通常每隔几十秒或者每次翻页就把当前作答回传。它的特点是高频小写入，并且在反复写同一份作答的同一批字段。一个用户填十分钟，可能产生十几次自动保存，但最后只有一次提交。这部分写入量在总量上往往比最终提交大一个量级，而它对一致性的要求却最低——丢了最后一次自动保存，通常只是让用户少填几道题。

第三个是最终提交。它的频率低，但瞬时高度集中，且必须幂等。最终提交一旦重复写入，就变成两份答卷，直接污染统计结果；一旦写入失败而前端又显示了成功，用户不会再来一次，这份数据就永久丢失。这是四个写入点里唯一一个既要求不丢、又要求不重的。

第四个是导出与统计。它读的是大结果集，通常伴随长事务、排序与聚合，而且导出文件本身要占用内存、磁盘和网络上行。它与在线写入争抢的是同一批数据库资源：连接、缓冲、锁。很多时候问卷系统在截止后立刻崩掉，不是因为还有人提交，而是因为所有人都在截止后同一分钟点了导出。

下面这张表把四个写入点连同最容易混淆的两种相邻情况放在一起对照，作为后面所有设计讨论的基础。

请求排队、连接复用与提交体的位置：网络与架构层要处理的三件事

把写入点分层之后，网络与架构层要解决的问题也跟着变了。集中提交时段真正稀缺的不是出口带宽，而是"同时能被处理的请求数"。

第一件事是请求排队的位置。如果排队发生在应用服务器内部，队列长度就是内存，排得太久会把进程拖垮，表现为大面积超时；如果排队发生在反向代理层，超出部分的请求会被快速拒绝，前端拿到明确的失败提示，用户重试一次可能就成功了。后者比前者好判断得多：宁可让一部分人在尖峰里看到"请稍后再试"，也不要让所有人一起卡住然后在前端自动重试三轮，把尖峰再放大三倍。

第二件事是连接复用。最终提交这一步要写入多张表——答卷主表、逐题答案表、状态记录表，如果每一条语句都单独取连接、单独提交事务，尖峰时段的连接需求量会成倍上升。把一次提交收敛在一个事务里，用完立刻归还连接，比加大连接池上限更有效。连接池上限本身也是一个需要谨慎对待的变量：调大之后数据库侧的并发事务变多，锁等待与上下文切换的开销会上升，达到某个点之后吞吐不升反降。

第三件事是提交体的位置。一份几十道题的答卷，序列化之后通常只有几十 KB，并不大；但如果问卷允许上传附件、图片或长文本，上行流量会在尖峰时段被放大。这类大字段应当与结构化答案分表存放，甚至分库存放，避免大字段的写入把整张答卷表的缓冲和索引维护一起拖慢。前端也需要对附件做大小与格式限制，否则一个几十 MB 的附件会在最不该出现的时候占满上行。

还有一层是超时与重试的对齐。前端的重试间隔、反向代理的超时时间、应用层的超时时间、数据库侧的锁等待超时，这四者如果互不匹配，就会出现"前端以为失败又发了一次，服务端其实已经写成功"的经典场景。下一次重试在语义上是否安全，取决于后面的幂等设计是否到位。

提交令牌、唯一约束与重复返回：重复答卷要挡在数据库之前

重复答卷有三个来源：用户连点提交按钮、网络超时后前端自动重试、用户提交后按浏览器后退键回到表单再提交一次。这三种行为在服务端看到的请求形状几乎完全相同，无法靠流量特征区分，只能靠标识区分。

可行的做法是三段式。进入表单时服务端下发一个提交令牌，令牌与答卷标识绑定，令牌本身带有效期；提交时前端携带令牌，服务端先查这个令牌是否已被消费；真正的兜底放在数据库层——用答卷标识加问卷标识建唯一约束，让并发下的两次写入必然有一次失败。

唯一约束必须放在数据库层，不能只放在应用层。应用层的检查与写入之间存在时间窗口，两个请求同时通过检查、同时写入，唯一约束是唯一能挡住这种情况的机制。挡住之后的处理也很重要：捕获唯一约束冲突之后，应当返回已经存在的那份答卷，而不是返回错误。用户点了两次提交，看到的是同一份"提交成功"的结果，而不是第二次被告知失败。

还有一个容易漏掉的分支：用户在两台设备上填写同一份问卷。如果问卷允许匿名填写，这件事在技术上无法阻止，只能在统计口径上约定；如果问卷要求登录，那么"用户标识加问卷标识"本身就是天然的唯一约束，不需要额外的令牌机制。设计之前先确认问卷是记名还是匿名，会省掉很多无谓的复杂度。

最后，提交成功之后应当立刻让当前表单失效。后端返回成功的同时把答卷状态置为已提交，前端接收到成功响应后跳转到一个明确的结果页，并清掉本地的草稿缓存与令牌。这一步不做，用户刷新页面时前端可能会带着旧令牌再发一次。

草稿、已提交、已作废：半途作答与最终提交需要一个明确的状态机

自动保存和最终提交写的是同一份数据的两个状态，不是两份数据。这一点如果没有在建模时讲清楚，后面所有的统计口径都会出问题。

建议显式定义至少三个状态：草稿（部分作答已保存但未提交）、已提交（最终提交成功且通过校验）、已作废（被管理员或规则判定无效，但数据仍需保留）。状态之间的转换要有明确条件，并且要禁止跨状态跳跃——已提交不能直接回到草稿，已作废不能直接变成已提交，需要修正时应当走一条显式的"作废后重新作答"路径。

状态机解决的第一个问题是"以哪次写入为准"。自动保存每次都在覆盖同一份作答，最终提交则是把草稿一次性定稿。如果两者写不同的表、由不同的代码路径维护，就会出现"草稿里是最新版，正式表里是旧版"的分叉。把两者统一到同一份主记录上，用状态字段区分阶段，是一条更省事的路。

状态机解决的第二个问题是导出口径。统计有效答卷时应该只算已提交状态，导出明细时可能需要带上草稿与已作废供人工复核。这两件事如果是两套互不相干的查询，早晚会算出两个数字。把口径写在状态定义里，让所有导出与统计都从同一个状态条件出发，是避免两份报告打架的最低要求。

还要处理一个边界：自动保存与最终提交在尖峰时段撞在一起。用户点了提交的同时，前端的定时心跳又发了一次自动保存。如果没有状态机，后到的自动保存可能把已经定稿的作答覆盖回旧版本。有了状态机，处理规则就很简单——状态一旦变为已提交，自动保存直接拒绝写入并返回当前状态。

导出为什么必须异步化，以及在哪个时间点上取快照

导出和统计在问卷系统里是一个被严重低估的风险点。它读的数据量大、占用连接时间长，而且往往在截止时间刚过、所有人都想第一时间看结果时被集中触发。

同步导出的第一个问题是超时。一份上万份答卷、几十道题的明细导出，涉及多表关联与排序，十几秒到几分钟都很常见，远超 Web 请求的合理响应时间。请求超时之后用户会重试，重试又启动一个新的长查询，几次之后数据库连接被占满，正在进行的在线提交跟着一起超时。

第二个问题是结果不稳定。如果导出是边写边读的，那么在导出执行的这段时间里，新提交的答卷可能落进结果，也可能没落进；更微妙的是多行关联时的部分可见——主记录已写入而答案明细尚未写入，导出读到的就是一份残缺的答卷。这就是两次导出行数不一致最常见的成因，它和数据库是否"有问题"毫无关系，纯粹是读取时机造成的。

解决方式是两个：异步化和取快照。异步化意味着导出请求只创建一个任务记录并立刻返回，真正的查询在独立的任务队列里跑，跑完生成文件，用户可以下载或者收到通知；取快照意味着导出任务开始时先确定一个时间点或确定版本的数据边界，整个导出过程只在这份边界上读，不受后续写入影响。

取快照有两条实现路径，各有取舍。一条是数据库的事务快照或一致性读，实现成本低，但长事务本身会占用资源、阻碍清理，时间久了会影响在线写入；另一条是在截止后把结果物化到一张独立的统计表或独立库里，导出只读物化结果，代价是引入一份需要维护同步的副本。对问卷这种有明确截止时间的场景，第二条的性价比通常更高——因为截止之后数据基本不再变化，物化一次可以服务后续所有导出。

统计查询与在线写入争抢的是什么：长事务、锁等待与索引

统计查询拖慢在线写入，不是因为统计"很耗 CPU"，而是因为它长时间持有资源。一次全表聚合会长时间占用连接、持续读缓冲、在某些隔离级别下还会持有读锁或阻碍版本清理。在线写入排队等的是这些资源，不是 CPU 时间。

长事务是这里的头号问题。一个跑了三分钟的统计查询，在数据库看来就是一个活了三分钟的事务。事务活着的期间，它可能需要保留旧版本数据以维持一致性视图，这些旧版本无法被清理，表与索引持续膨胀，写入路径上的维护成本随之上升。表现是：统计跑完之后，在线提交并没有立刻恢复，而是要缓一阵。

锁等待的成因通常是更新与统计撞在同一批行上。状态变更、作废标记、计数器自增这类写操作，如果和统计读取的是同一个热点区间，就会互相阻塞。把计数器这类高频更新从主表拆出去单独维护，或者改为异步累加，能明显降低撞锁的概率。

索引是典型的双刃剑。统计查询需要索引来避免全表扫描，但每多一个索引，每次写入就要多维护一棵树。问卷系统里最容易踩的坑是"为了临时做一次分析加一个索引"，索引建完之后长期留着，平时写入量小看不出问题，等到截止前十分钟写入暴涨，索引维护的开销才集中爆发。合理的做法是：为固定的统计口径保留少量必要索引，临时分析走物化结果或只读副本，不给在线库临时加索引。

如果确实需要频繁统计，把查询放到只读副本上是更干净的选择。副本与在线库之间存在复制延迟，这在问卷场景下通常可以接受——统计看板晚几秒刷新不影响决策。需要严格一致的场景（比如确认某人是否已提交）单独走主库，这类查询是单行的、走唯一索引的，成本极低。

按提交尖峰而不是按日活估算：连接池、排队长度与写入窗口怎么换算

容量估算的第一步是把尖峰的形状写出来。假设一份问卷面向 N 人，历史经验或同类问卷的规律是最后十分钟完成比例落在某个区间，那么峰值写入速率大致等于这个人数除以时间窗口，再乘上一个不均匀系数——因为尖峰内部也不是均匀的，最后一分钟往往比前十分钟的均值更陡。这个数字不需要精确到个位数，需要的是量级正确。

有了峰值写入速率，再去反推三个变量。连接池上限：单次提交的事务时长乘以峰值速率，就是同时活跃事务数的期望值，连接池至少要覆盖它，还要留一点余量给统计查询与运维操作。排队长度：峰值速率减去系统能处理的速率，差值乘以尖峰持续时长，就是需要排队等待的请求数，这些请求要么在内存队列里等待，要么被快速拒绝。写入窗口：从队列排空那一刻算起，系统需要多久才能把所有积压写完，这个时间决定了"截止之后多久数据才完整"。

这三个变量里，第二个最容易被忽略。很多人只看"每秒能处理多少"，不看"处理不完的怎么办"。而问卷场景恰好有一个天然优势：截止时间之后几乎没有新请求，积压可以被慢慢消化。因此这里的设计取向应当是接受排队、明确拒绝、而不是强行横向扩展去硬扛一个只会存在十分钟的尖峰。

硬件侧的变量要按这个口径去看，顺序大致是内存、数据盘、CPU、带宽。内存决定排队能排多长、缓存能放多少、导出任务能不能不落盘完成；数据盘的随机写入能力决定自动保存与最终提交会不会堆积；CPU 在问卷这类逻辑简单的系统里通常最后才成为瓶颈；带宽只在提交体含附件、或者导出文件需要外发时才重要。按这个顺序做取舍，比按"并发数"拍脑袋配置有效得多。

容量口径明确之后，再看具体选型才有意义。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；如果你的问卷系统面向的用户集中在某一个区域，把应用与数据库放在离用户更近的一侧，能减少提交请求在公网上的往返不确定性。作为服务器配置参考时，真正要对齐的是峰值写入窗口内的内存余量与数据盘写入能力，而不是首页能扛多少并发；具体机型、内存与带宽的当期价格以官网实时报价为准。

写入与统计是否分离、备份与留存期：四个绕不开的配置取舍

第一个取舍是写入与统计是否分离。规模小、问卷频次低时，放在同一个库里最省事，代价是统计查询会干扰在线写入；规模上来之后，把统计查询放到只读副本、把导出放到独立任务节点，是投入产出比最高的一次分离。判断标准很简单：如果截止时间后的半小时内，有人跑导出就会影响到还有人在提交，那就该分离了。

第二个取舍是导出是否异步化以及结果留存多久。异步化几乎没有反对理由，真正要想的是留存：导出文件放在哪里、保留多少天、过期是否自动清理。问卷数据往往涉及个人信息，导出明细文件的留存期不宜长于答卷数据本身的留存期，否则清理了库却留着一份完整明细在磁盘上，等于没清理。这个口径最好在上线前与数据管理方确认，而不是事后补。

第三个取舍是备份窗口。定时备份会持续占用磁盘与网络，如果它和提交尖峰重叠，会直接吃掉写入能力。问卷的截止时间通常是整点或半点，把备份窗口挪到尖峰之外是很低成本的规避。同样要确认的是备份方式：逻辑备份会长时间持有一致性视图，物理备份或快照对在线写入的干扰通常更小，具体采用哪种要看你的恢复目标与可用工具。

第四个取舍是日志与审计字段。问卷系统里的审计不只是安全需求，也是数据对账的依据：每一份答卷应当记录创建时间、最后保存时间、提交时间、提交来源标识、状态变更记录。缺少这些字段，一旦出现"后台数字对不上"，你就没有任何手段还原发生了什么，只能对着两份不一致的报告猜测。这些字段平时不显眼，出事时是唯一能定位问题的东西。

扩容顺序：先分离导出，再扩连接，最后才加机器

扩容的顺序比扩容的数量更重要。同样是加两台机器，加在错误的位置上，尖峰期间的表现可能几乎不变。

第一步是把导出与统计从在线写入路径上摘出去。这一步通常不需要增加硬件，只需要把导出改成异步任务、让它跑在独立的节点或者只读副本上。它解决的是"最重的那个读"和"最关键的那个写"争抢同一批资源的问题，也是四项措施里唯一一项能同时改善超时、不一致和拖慢三个现象的措施。

第二步是调整连接与排队策略。包括确定连接池上限、设置反向代理层的排队与快速拒绝、对齐各级超时时间、把一次提交收敛进单个事务。这一步的目标不是提高吞吐上限，而是让系统在超过上限时表现出可预测的降级——拒绝一部分请求，而不是让所有人一起变慢。

第三步才是增加机器。加应用服务器可以扩大排队与处理的容量，加内存可以让队列排得更长，换更快的存储可以降低自动保存与提交的写延迟。只有在前两步完成之后，加机器带来的收益才是线性可预期的；否则新加的机器会一起涌向同一个数据库，把瓶颈从应用层原封不动地推到数据库层，甚至因为连接数增加而让情况更糟。

需要一套可以直接对标的标准化服务器方案作为扩容基线时，可以参考一万网络的标准化配置思路：先按层次拆开应用、数据库与导出任务，让每一层都能独立扩容，再按峰值提交窗口选择内存与数据盘规格，最后才考虑整体横向扩容的台数；具体机型、内存与带宽的当期报价以官网实时信息或咨询确认为准。

这个顺序背后是一个更一般的判断：问卷系统的尖峰是短暂的、可预期的、且尖峰之后有充足的消化时间。因此最优策略不是把峰值处理能力堆到峰值之上，而是让系统在峰值期间体面地降级、在峰值之后完整地把数据补齐。按这个思路规划，同样的硬件能支撑的问卷规模往往比硬扛方案大得多。

本文不展开的三件事：问卷题目设计方法、统计口径的学术定义、具体软件的部署安装步骤

第一，问卷题目怎么设计、题目顺序怎么排、怎样提高回收率，属于调研方法范畴，与本文讨论的写入与一致性问题无关，不做展开。

第二，统计口径的学术定义，例如有效问卷的判定标准、缺失值处理、加权方法，属于统计学与研究设计范畴。本文只讨论"两次导出为什么会不一致"这个工程问题，不讨论哪个统计口径更正确。

第三，具体软件的安装与部署步骤。LimeSurvey、Formbricks 等工具各有自己的安装文档与版本要求，本文不复制任何安装流程，也不对具体版本的功能差异做比较，只讨论它们共同面对的写入与一致性问题。涉及具体版本的配置项名称与行为，请以对应软件的官方文档为准。

五类集中提交风险：现象、成因、判断依据与规避动作

风险一，用前端置灰按钮来防重复提交。问题：统计里出现同一人的两份答卷。原因：按钮置灰只能挡住最外层的一次点击，挡不住网络超时后的自动重试、浏览器后退再提交、以及多设备同时提交。判断：只要防重逻辑写在前端，就一定存在绕过路径。规避：服务端下发提交令牌，数据库层建唯一约束，唯一约束冲突时返回已有答卷而非报错。

风险二，每次自动保存都整份覆盖写库。问题：尖峰时段写入量暴涨，提交被拖慢。原因：自动保存的频率远高于提交，且反复写同一批字段，把写入能力消耗在没有业务价值的覆盖上。判断：如果自动保存的写入次数是最终提交的十倍以上，这部分就是主要写入来源。规避：客户端做本地暂存与合并，服务端按时间窗口批量落盘，并接受最后一次自动保存可能丢失。

风险三，导出任务直接跑在在线库上。问题：导出超时、两次导出结果不同、导出期间提交变慢。原因：大结果集的长事务长时间占用连接并读取变动中的数据，既抢资源又读不到确定边界。判断：截止后同一分钟内多人点导出，是这个风险最典型的触发条件。规避：导出异步化，跑在独立节点或只读副本上，并基于确定的时间点或物化快照执行。

风险四，备份窗口与提交尖峰重叠。问题：截止前十分钟写入异常缓慢。原因：定时备份持续占用磁盘与网络，与集中提交争抢同一份写入能力。判断：问卷截止时间通常设在整点，而默认备份窗口也常设在整点附近，重叠概率很高。规避：明确问卷截止时间后，把备份窗口挪开，并确认备份方式对在线写入的干扰程度。

风险五，按日活或总人数估算配置。问题：平时一切正常，最后一刻崩掉。原因：按均值摊平算出来的容量，与集中在十分钟内的写入速率不是一个量级。判断：只要容量模型里没有"峰值写入速率"这个变量，就一定是按均值估的。规避：把峰值写入速率、同时活跃事务数、可接受排队长度三个数字写出来，再反推内存、存储与连接配置。

自建问卷系统时，六个绕不开的技术问题

问题一：重复答卷怎么才能彻底挡掉，前端把按钮置灰够不够？

不够，前端置灰只能挡住连点这一种情况。真正会产生重复的是三类：用户连点、网络超时后前端自动重试、提交成功后按后退键回到表单再提交一次。后两类在服务端看到的请求与正常提交完全一致，无法从流量特征上区分，只能靠标识。做法是三段：进入表单时服务端下发与答卷绑定的提交令牌，提交时校验令牌是否已被消费，最后由数据库层的唯一约束兜底并发场景。冲突发生时不要返回错误，而是返回已经存在的那份答卷，让用户看到同一个成功结果。问卷如果是记名的，用户标识加问卷标识本身就是唯一约束；匿名的场景才需要额外引入令牌机制。

问题二：半途作答要不要每次触发自动保存都写库？

不建议。自动保存的频率远高于最终提交，一个填十分钟的用户可能产生十几次回传，这些写入在业务上只服务于"别丢了用户填的内容"，对一致性要求很低，却消耗了尖峰时段最稀缺的写入能力。更合理的做法是客户端先本地暂存并合并多次改动，服务端按时间窗口批量落盘，允许最后一次自动保存丢失，但要能明确提示用户。要注意的是，自动保存和最终提交写的是同一份数据的不同状态，不是两份数据，自动保存必须受状态机约束——状态一旦变成已提交，自动保存就应该被拒绝，否则后到的心跳会把定稿覆盖回旧版本。

问题三：导出两次结果不一致，问题出在哪一层？

绝大多数情况下不是数据库出错，而是读取时机的问题。同步导出是边写边读的，执行期间新提交的答卷可能落进结果也可能没落进；多表关联时还会出现部分可见，主记录已写入而答案明细尚未写入，读到的就是一份残缺答卷。这个现象在截止前十分钟最容易出现，因为那一刻写入最密集。解决要分两步：把导出改成异步任务，避免长事务占用在线连接；再为导出确定一个数据边界，用事务快照或截止后物化的结果表都可以。物化方案对问卷场景性价比更高，因为截止后数据基本不再变化，物化一次可以服务之后所有的导出请求。

问题四：按日活估算配置为什么总是不够用？

因为问卷的写入在时间上极不均匀。总人数除以回收天数得到的是日均提交量，而真实压力出现在截止时间前的最后几分钟，两者往往相差一个到两个数量级。用均值配出来的系统，在日常时段看起来资源严重过剩，在尖峰时段又立刻不够。正确的估算变量是峰值写入速率：先估计最后时间窗口内会完成多少份，再除以窗口长度并乘上不均匀系数。有了它才能反推同时活跃事务数、连接池上限、可接受排队长度，进而决定内存与存储规格。问卷场景还有一个有利条件：截止之后不再有新请求，积压可以慢慢消化，所以策略上应当接受排队与明确拒绝，而不是硬扛峰值。

问题五：统计库要不要单独拆出去？

取决于截止后的那半小时里会不会互相干扰。如果有人跑导出时，还有人在提交并明显变慢，那就该拆。拆分不必一步到位，性价比最高的顺序是：先把导出异步化到独立任务节点，再把统计查询放到只读副本，最后才考虑独立统计库。只读副本会引入复制延迟，对统计看板通常可以接受，但对"确认某人是否已提交"这类需要严格一致的查询，应当单独走主库——这类查询是单行、走唯一索引的，成本很低。无论拆到哪一步，统计口径都要从同一份状态定义出发，否则两份报告迟早会算出两个数字。

问题六：备份与留存期怎么定才不影响在线写入？

两个要点：错开窗口，明确留存。备份窗口要避开提交尖峰，问卷截止时间通常设在整点，而默认备份窗口也常在整点附近，重叠概率很高，挪开是零成本的规避。同时要确认备份方式，逻辑备份会长时间持有一致性视图，对在线写入的干扰通常大于快照类方案。留存期则要同时覆盖数据库和导出文件——导出明细是完整数据的副本，如果清理了库却留着一份明细在磁盘上，等于没清理。问卷数据常涉及个人信息，留存期最好在上线前与数据管理方确认并形成书面口径，而不是事后补。

数据来源与参考口径说明

本文的机制性分析基于数据库应用设计中的通用模式，参考了以下方面的公开资料：关系型数据库事务隔离与一致性读的通用原理，可见于各主流数据库官方文档中关于事务与隔离级别的章节；幂等设计与分布式系统中重复请求处理的常见实践，可见于公开的系统设计文献；大规模在线表单与问卷系统在集中提交场景下的容量规划讨论，属于行业工程经验的公开共识。

关于队列与降级，参考的是公开的可伸缩性设计文献中关于排队、背压与快速失败的通用论述；关于长事务对在线写入的影响，参考的是各主流数据库官方文档中关于事务管理、版本清理与锁等待的说明。以上资料均为通用技术文档，不含任何具体产品的性能测试结论。

文中涉及的服务器与机房层面的选型讨论，属于行业部署角度的通用分析，不引用任何具体报价；所有配置与价格相关表述，均以官网实时报价或实际咨询结果为准。文中不引用任何未经公开的测试数据、客户案例或市场调研数字。

把四个写入点分开算，问卷系统的尖峰就不再神秘

回到开头那个场景。后台数字对不上、出现重复答卷、导出超时这三者，不是三个故障，而是同一个设计缺陷的三个投影：把页面加载、自动保存、最终提交、导出统计这四种形状完全不同的写入当成同一种写入来规划。

分开算之后，每一类问题都有明确的落点。重复答卷归提交令牌与唯一约束，自动保存的压力归批量合并与状态机，导出的超时与不一致归异步化与快照，容量不够归峰值写入速率而不是日活。它们之间没有耦合，可以按顺序解决，也可以分别验证。

落地顺序建议是：先补状态机与提交令牌，因为这两项改动最小却决定了数据是否正确；再把导出异步化并确定快照边界，这一步能同时消掉超时和不一致；然后调整连接与排队策略，让系统在超过上限时明确降级；最后才按峰值写入速率反推内存与存储，必要时扩容。按这个顺序走，大部分问卷系统不需要加机器就能扛过截止前十分钟。

本文的技术口径与需要你自己验证的部分

本文讨论的是自托管问卷与表单类系统在集中提交场景下的写入分层与一致性设计，属于工程机制与取舍层面的通用分析，不针对任何具体软件版本，也不构成对具体产品功能或性能的结论。

文中出现的四个写入点、提交令牌与唯一约束、状态机、导出快照等做法，是数据库应用设计中的常见模式，具体实现路径受你使用的软件、数据库类型与部署方式影响，需要结合实际情况确认。文中没有引用任何实测数据、压力测试结果或客户案例，所有关于形状与量级的描述都是定性判断。

需要你自己验证的部分包括：你的问卷在截止时间前的真实提交分布（可以从历史问卷的提交时间戳统计得到）、单次提交的事务时长、连接池在当前负载下的表现、导出任务的实际执行时间与资源占用，以及备份窗口与提交窗口是否重叠。这些数字因环境而异，用你自己的监控数据得出的结论，比任何通用建议都可靠。

涉及个人信息处理、数据留存期与跨境存储的合规要求，请以适用的法律法规和你所在机构的数据管理制度为准，本文不做合规性判断。涉及具体软件的配置项名称、行为与版本差异，请以对应软件的官方文档为准。