TG咨询
香港服务器部署在线教育平台的并发容量规划，应先区分学生是在观看直播、播放录播，还是同时提交作业、参加测验。三类请求对带宽、计算和数据库的压力不同，不能只按注册用户数估算。容量方案应以预计同时在线人数为起点，并通过接近真实使用方式的压测校正。
先按课程场景拆分负载
直播课堂：优先算媒体带宽
如果直播由 Zoom 等会议服务承载，香港服务器通常主要处理登录、课程信息和互动数据，不承担全部音视频流量。若平台自行传输直播，需把编码、转发和观看流量纳入设计；使用 WebRTC 的实时互动对延迟较敏感，自建媒体服务的复杂度也更高。
录播与课程管理：分别看流量和请求
录播视频会形成持续出站流量，课程目录、签到、测验和作业提交则增加应用及数据库请求。以 500 人同时观看、每人平均码率 1.5 Mbps 粗算，若视频全由源站发送，出口带宽需求约为 750 Mbps，尚未计入波动和协议开销。实际码率、画质和并发观看比例会改变结果；视频经对象存储或 CDN 分发时，源站压力则主要转为回源请求和业务接口。
用可验证的方法估算起步容量
- 确定峰值并发：按同时上课的班级数、每班人数和课程重叠情况估算，而不是用总注册用户代替。区分平常高峰与考试、开学等集中时段。
- 拆出请求类型：记录登录、打开课程、提交答案等接口的大致访问频率，同时估算正在播放视频的人数、平均码率和峰值码率。
- 建立基线：先部署可观测的测试环境，逐步增加虚拟用户，检查响应时间、错误率、CPU、内存、网络出口、数据库连接数和任务队列长度。压测脚本应覆盖真实用户流程，不能只反复请求首页。
- 留出余量：将目标负载下的实测结果作为配置依据。生产环境可预留约 20%–30% 的资源余量作为初始缓冲，但促销、开学或统一考试等突发峰值需要单独评估。
香港服务器部署在线教育平台的并发容量规划，最终应以应用自身的压测数据为准。同一规格的主机在程序效率、数据库查询和网络条件不同的情况下，承载能力可能相差明显，不宜直接套用固定的“每台服务器支持多少人”。
扩展方式要匹配瓶颈
| 方式 | 适用情况 | 限制 |
|---|---|---|
| 纵向扩容 | 单台应用或数据库资源不足，且短期内需要快速增加CPU、内存。 | 受单机规格上限影响；升级或迁移可能需要维护安排。 |
| 横向扩容 | 应用能够多实例运行，登录和课程接口流量持续增长。 | 需要处理会话共享、任务重复执行和实例健康检查。 |
| 视频外置分发 | 点播流量占比高，源站出口带宽成为主要瓶颈。 | 会增加分发与存储环节，需验证缓存命中和内容更新流程。 |
应用层可将会话状态放入共享存储或使用无状态令牌，使负载均衡器能把请求分配到多个实例。视频文件与应用程序分开部署，避免大流量播放挤占课程接口带宽。数据库则应先检查慢查询、索引和连接池；单纯增加应用服务器，无法解决数据库已经饱和的问题。异步邮件、成绩汇总等非即时任务可进入队列，避免高峰时堵住用户请求。
上线前后的扩容步骤
- 按直播、录播和交互业务分别设定目标并发及可接受响应时间。
- 在与生产架构相近的环境压测，逐步加压并记录最先饱和的资源。
- 先处理明显瓶颈，再验证扩容是否带来改善；同时检查数据库连接、文件存储和网络出口。
- 为应用实例配置自动或人工扩容规则，并设置扩容冷却时间，避免短时波动导致实例频繁增减。
- 准备高峰值守和回退方案，监控错误率、接口延迟、出口带宽与队列积压；容量不足时优先保障登录、课堂进入和答题等核心功能。
如果用户主要分布在香港及周边，单区域部署可能更易管理；若用户分布跨多个地区，则应结合访问路径、数据同步延迟和故障恢复目标评估多区域方案。多区域能提升部分故障场景下的恢复能力，但会增加部署、同步和运维成本，并非所有平台上线初期都需要。
常见问题
问：在线人数等于并发请求数吗？
不等于。在线人数表示会话仍活跃，接口并发取决于用户操作频率；视频观看则会持续消耗带宽，应分别统计。
问：香港服务器只增加带宽能解决卡顿吗？
不能一概而论。若出口已饱和，增加带宽或分流视频可能有效；若瓶颈在数据库、应用计算或跨境链路，单加带宽帮助有限。
问：什么时候该增加应用实例？
当应用实例的CPU、内存或请求处理能力持续接近上限，并且数据库与网络仍有余量时，可先扩容少量实例，再用压测和生产监控确认效果。
把业务拆分、压测和瓶颈定位结合起来，香港服务器部署在线教育平台的并发容量规划才能从估算落到可执行配置；上线后还要依据真实峰值持续调整。