开课前一分钟，数百名学生同时进入课堂；课程结束前，许多人又在短时间内提交测验。两种流量的压力点不同：直播持续占用连接和媒体处理资源，测验则可能制造集中请求。非洲在线教育平台并发容量规划应把这两类负载分开估算，再通过联动测试验证。
先拆开计算直播与测验
直播看在线人数和媒体方式
先估算注册人数、预计到课比例和单场最大在线人数。不要把“观看者人数”直接等同于服务器处理量：采用实时音视频时，平台需要处理媒体流；采用教师单向播送、学生文字提问的课堂，媒体负载通常较低。Moodle 可承载课程与测验活动，BigBlueButton 常用于在线会议式课堂；具体部署方式和负载能力取决于版本、配置及服务器资源，不能仅凭产品名称推断容量。
为每种课堂模式记录在线人数、单人上下行带宽需求、连接持续时间及峰值发生时段。若学生网络条件差异较大，可提供低分辨率或仅音频选项，并在正式排课前确认播放器在常见手机浏览器上的表现。
测验看提交窗口有多窄
测验负载要估计提交集中度，而不只是题目数量。假设一次课程有 2,400 名注册学生，预计六成到课，则约有 1,440 人在线；若其中 70% 在 90 秒内提交，平均约为每秒 11 次提交。这个数字只是规划示例，实际峰值还会受自动保存、答案检查、重试和题目页面设计影响。可把登录、打开测验、保存答案与最终提交分别统计。
把容量规划变成可验证的步骤
- 建立负载清单：按课程时段列出预计在线人数、课堂类型、测验开始与截止时间，并标出多个班级是否会同时开课。
- 拆分请求路径：分别记录网页与接口请求、媒体连接、身份验证及数据库读写。测验提交应检查是否会触发大量重复写入或同步统计。
- 设计逐级压测：先以预计峰值的约 50%、75%、100%逐步增加虚拟用户，再测试短时间集中登录和集中交卷。负载工具应模拟真实页面操作；单纯增加 HTTP 请求，不能代表完整直播体验。
- 监控关键指标：观察应用服务器 CPU、内存、活动连接、请求错误率、响应时间，以及数据库连接池和写入延迟。直播还要关注加入课堂失败、音视频卡顿和重连情况。
- 验证扩容与恢复：若采用云主机或容器，确认扩容触发条件、启动耗时和扩容上限；同时模拟部分节点不可用，检查已有课堂是否中断、未完成答案能否恢复。
预留非洲网络环境下的弹性
学生可能通过手机网络、校园 Wi-Fi 或家庭宽带接入，时延、丢包和可用带宽并不一致。容量测试因此要包含弱网条件，并在不同设备上检查进入课堂、重新连接和提交答案的行为。若所有媒体都由同一组应用服务器转发，直播人数上升可能挤占测验请求资源；将媒体处理与课程应用分开部署，通常更便于独立扩容，但会增加运维和监控复杂度。
弹性扩容并非短时峰值的万能解法：数据库、账号服务或外部认证若先达到瓶颈，增加应用实例也不能解决问题。对课程开始和交卷时间可预先错峰；对测验结果汇总、非必要报表等非即时任务，可考虑排队处理，并明确学生端的保存状态和失败重试提示。
结论：用峰值场景校准容量
非洲在线教育平台并发容量规划应以“直播同时在线人数”和“测验提交速率”两套指标为核心，通过逐级压测、弱网验证和瓶颈监控确定安全容量。上线后按课程记录真实峰值与错误情况，持续修正到课比例、提交窗口和扩容阈值，避免只按平均流量配置资源。
常见问题
只按注册学生人数规划够吗？
不够。应估计实际到课人数，并单独计算测验集中提交和同时开课的叠加峰值。
测验截止时间需要错开吗？
如果多个大班共用数据库或应用资源，错开开始、截止时间能降低请求集中度；是否需要错峰，应由压测结果和课程安排决定。
压测达到预计人数就代表安全了吗？
不一定。还应检查弱网重连、错误率、数据库瓶颈及扩容恢复，并确认测试流程覆盖真实课堂操作。
