考试之夜提供了证据，不是容量保证——NovaCommerce 第五篇

两场真实考试、一次缩容失误和一个规划模型。最后一篇把观察、外推、运维成本与尚欠测试分清楚。

作者

Anichur Rahaman

1 个月前6 分钟阅读223 次浏览

第 5 部分，共 5 部分

2026 年 10 月 7 日连续进行了两场考试。记录中第一场 661 人开始、638 人提交，第二场 439 人开始、425 人提交。随后有人调低池下限，一个服务节点未按预期排空便消失，两分钟约 360 次请求失败。正常工作的服务和这次故障都属于结果。

NovaCommerce 是课程与考试平台的匿名名称。终篇保留既有 9–10 月观察，重新核算已发布数字，并明确未被证明的部分。不是本次重新做的负载测试，也不是 StoreConsole 基准。

按实际覆盖范围解读测试

调查先在 9 月 25 日发现 IP 限流身份问题，又在 10 月 6 日测试发现 Valkey 连接故障，以及特定请求组合的后端 CPU 饱和。原因不同，需要的变更也不同。更多服务器能缓解部分容量压力，不能代替正确身份或健康共享服务。

记录包括前端约 356 requests/s、p95 0.05 s、报告错误为零；10 月 5 日 GET 扩容测试约 750 requests/s、无报告服务器错误/超时，但约 4% HTTP 429；另一个 25–500 测试应用错误为零，却有 143 次均衡器错误。组合和范围不同，不能把各自最好数字拼成一次成功吞吐承诺。

后续受控部署每两秒探测一次，共 219 次、零错误。这是有用的采样证据，不能证明每次请求、写入或长连接都存活。完整业务测试须验证认证答案接受、持久回执、安全重试与最终结果，而非只看 HTTP 状态或缓存首页。

真实运行暴露了另一种失败

638/661 四舍五入为 96.5%，425/439 为 96.8%。这是提交比例，不是可用性百分比。未提交可能有多种原因，计数不能把每次缺失都归为技术故障，也不能证明零数据丢失。

分钟日志记录后端峰值约 69 requests/s，供应商两分钟聚合为 63。报告的池平均 CPU 峰值 47%，某单节点一分钟达到 86%。MySQL CPU 最大 24.5%、平均 13.4%；工作节点最大 46%，记录失败任务为零。要保留聚合窗口与分母，零失败并不等于没有待处理或丢失工作。

原 CPU 估计约 59 ms/请求，63 requests/s 对应每秒 3.717 CPU 秒，除以八 vCPU 约 46.5%。接近 47% 是这些假设下的一致性检查，不证明因果或线性扩展。缩容事故说明就绪、单节点负载和退出应分别取证。考试时段手册是人工控制，不是强制禁止。

用模型选择下一次测试

历史模型假定每后端节点 50 requests/s，基础流量 30 requests/s，不均衡因子 1.3，每学生开场 15 次请求，持续在线时 0.025 requests/s。50 应视为同请求组合、约定延迟目标下的假设，不能作为通用安全上限。

N 个健康节点的学生预算为 N×50÷1.3−30 requests/s。600 秒加入窗口内，每学生 15÷600+0.025=0.05 requests/s；120 秒内为 0.15。四节点计算 (4×50÷1.3−30)÷0.05≈2,477，教学表向下取为 2,400。这是流体平均模型，突发、不均匀到达及停顿仍可能超过它。

除数 1.3 是规划因子，不代表保留 30% 空闲，也不自动覆盖失去一个节点。节点故障要另外建模。高于已观察少量节点的行是外推，不是认证学生容量。PDF 上传、工作队列、数据库争用和供应商限额均在此后端模型之外。数据库 CPU 低不能证明 450 requests/s 上限或六倍余量。

健康后端节点	模型预算 requests/s	600 秒加入：向下取整人数	120 秒加入：向下取整人数
2	≈77	900	300
4	≈154	2,400	800
6	≈231	4,000	1,300

描述架构时也写出未解决风险

历史设计采用独立前后端池，各最少两节点、最多十节点；主备 MySQL、共享 Valkey、独立 PostgreSQL/pgvector、对象存储和 OpenSearch 后端日志。单一固定工作节点运行队列、调度、WebSocket 与短信，仍是单点；前端日志外送和工作节点备用仍在计划中。

复制数据库、无状态 Web 与镜像改善特定恢复路径，不能让所有依赖冗余，也不单独防止区域故障、错误部署、未授权访问或误删除。写入隔离和恢复需分别测试。新写入之后，冻结旧数据不是最新回滚；镜像回退也依赖结构、会话和队列消息兼容。

比较之前先把账加对

历史 Web 月度列项共 $272：后端 $112 +前端 $56 +工作节点 $56 +双均衡器 $48。数据与日志 $709：MySQL $389 +Valkey $240 +PostgreSQL $60 +OpenSearch $20。再加快照 $5 和 Spaces 基础费 $5，变动用量之前为 $991。原“约 $990”是取整，不是精确发票。

此前 $416 仅指含关机恢复 Droplet 的 Web 层，不是旧全栈。确认相同范围与服务假设后，才可比较 $416 与 $272，不能直接与新组合 $991 比较。清单未含人员、支持、税、AI/短信、超额费和部署/高峰临时容量，因此不是完整总拥有成本或当前报价。

检查当前套餐与账户资格。第三篇的 MySQL Standard 政策变化意味着不能把历史双节点直接当作未核实的 2026 采购方案。增加可靠性预算可能合理，但节省主张需要同等服务和完整运营模型。

历史月度组别	列项小计	范围
Web 层	$272	2 后端 +2 前端 +工作节点 +2 均衡器
数据与日志	$709	MySQL +Valkey +PostgreSQL +OpenSearch
快照与存储基础费	$10	$5 +$5；用量另计
列项基础合计	$991	未计用量、人员、税及其他服务

下一道验收仍是实质工作

记录中的正式多小时浸泡与混合写入完整负载测试仍是计划。两小时真实考试观察不是受控浸泡。24 小时未观察到本地写入不能排除内存泄漏、连接增长或队列累积，不能悄悄改标为已通过。

扩大活动之前约定成功答案和延迟阈值，采用代表性身份与到达曲线，检查重复提交与截止行为，持续观察内存、连接、存储和最老任务年龄。覆盖节点故障、安全缩容、数据库重连/切换、工作节点恢复及备份还原。保存工具版本、脚本、资源配置、错误和已接受工作核对。破坏性测试应在隔离的代表环境，或有停止条件的批准窗口执行。

系列留下可复用循环：衡量业务结果，定位限制，修改相关层，再测试结果和恢复。最有价值的产物是证据台账，明确区分已观察、已建模和尚未测试。