每年九月初那一周对高校信息中心来说就是渡劫。新生报到老生返校选课系统开放各种迎新活动同时进行WiFi系统的并发在线数可能在三到五天内从暑假底值直接翻三四倍。如果你的计费系统和认证架构没有针对这个场景做过专门设计和测试出事是迟早的事。

先搞清楚"开学并发"到底长什么样

很多人以为开学高峰就是"人多了而已"多买几台AP加几条带宽不就行了？但实际数据特征远比这个复杂。

时间分布上不是均匀的。报到当天上午9-11点是第一个峰值——大量新生和家长同时到校每个人都在用手机连网查信息加微信群发朋友圈；下午2-4点可能是第二个峰值——宿舍分配完毕后所有人同时在房间里配置网络；晚上8-10点是第三个也是最猛的峰值——所有人在宿舍同时使用WiFi而且行为包括高清视频大文件下载在线游戏等重流量应用。这三个峰值形态完全不同应对策略也不应该一样。

空间分布上同样极端不均。报到现场（体育馆或广场）报到时段终端密度可以达到每平方米两三个设备这已经超出普通AP高密度模式下的服务能力上限。宿舍区晚间是另一个热点区域一个六人间宿舍每人两部就是十二个终端挤在小空间里争抢同一个AP空口资源。

更麻烦的是认证行为模式的突变。暑假期间在线的基本都是留校学生和教职工认证方式相对稳定。开学季突然涌入几千个新用户每个都要走首次注册绑定手机号下载证书选择套餐等流程。这些操作的数据库IO远高于日常简单认证请求很容易把认证服务打满。

Radius服务器要提前做压力评估

开学季最大瓶颈往往不在无线侧而在认证侧。一台中等规模Radius（比如4核8G配置）每秒能处理的认证请求数大概在几百到一两千听起来很多对吧？但如果一万个人一小时内集中上线平均每秒就有接近三个新增认证请求加上大量续约请求再加上计费报文处理实际负载可能比平时高出一个数量级。

建议在开学前至少两周做一次完整压力测试。用测试工具模拟预期高峰并发量（建议按历史数据1.2倍来设目标值）观察Radius服务的CPU利用率内存占用响应延迟和错误率四个关键指标任何一个指标接近危险阈值就需要扩容或者优化。

扩容可以是纵向（升级硬件配置）也可以是横向（增加节点做集群）。横向扩展的好处是可以做负载均衡但要注意Session同步问题——如果用户在节点A完成认证但后续计费请求分到了节点B节点B必须能拿到会话信息。大部分商用Radius产品都支持这种场景但配置比较复杂需要仔细读文档并且充分测试。

数据库往往是隐形的短板

计费核心数据存在数据库里——用户信息套餐余额在线记录认证日志等等。日常运行时数据库负载可能只有百分之十几看起来绰绰有余。但开学季高并发写入（大量新用户注册+在线状态更新+计费报文频繁写库）会让数据库TPS瞬间飙升。

最容易出问题的是认证日志表。每次成功或失败都写一条记录高峰期一天可能产生几十万甚至上百万条日志。这张表没做好分区或索引优化查询和写入都会越来越慢最终拖垮整个数据库性能。

实践经验：认证日志表按月分区是最低要求大数据量的学校建议按周分区。超过三个月的历史日志归档到冷存储或者导出到数据分析平台不要一直堆在生产库里。索引方面用户ID和时间戳复合索引必须有其他查询字段根据实际报表需求选择性添加。另外把实时性要求不高的统计类操作（"今日总认证次数""当前在线用户数"）从主库剥离出去用从库或者缓存承担。

前端体验也要为开学季做特殊设计

后端满负荷运转的时候前端如果能帮着减轻一点负担也是好的。有几个可操作的做法：

第一，认证页面静态资源（JSCSS图片）全部上CDN或者在本地做充分缓存策略。不要让每个新用户认证时都从你的服务器加载几百KB的前端资源。这点看起来小事但在万人并发下节省的总带宽相当可观。

第二，认证成功后的跳转页尽量精简。有些系统喜欢在认证成功后展示一大段广告通知问卷调查之类的内容开学季统统砍掉或者异步加载让学生尽快完成认证释放连接资源。

第三，准备降级方案。检测到系统负载超过阈值时自动切换到极简版认证页面——只保留核心的用户名密码输入框和认证按钮其他功能暂时关闭。虽然体验差一点但至少保证能用总比整个挂掉强。这种降级开关建议做成手动的也支持自动触发给运维保留最终决策权。

开学周结束后的收尾工作

别以为熬过开学周就完事了。高峰过后几天有一堆收尾：检查有没有因为高并发产生的脏数据（重复扣费状态不一致等）；分析这次高峰性能数据跟之前压力测试结果对比看差距在哪；整理学生反馈问题清单按优先级排修复计划；更新容量规划文档为明年做准备。

尤其重要的一点：把今年开学季实际峰值数据（最大在线数最高认证TPS出口带宽峰值利用率）记录存档。这些真实数据比任何理论估算都有价值明年规划和预算申请全靠它。我们见过太多学校每年凭感觉估算容量年年不够用本质上就是因为没认真记录和分析历史数据。