开学选课开放瞬间，流量峰值能冲到平时几十倍，直接横向扩容成本高且浪费，最划算的解法是“先接收、再排队、后放行”也就是削峰填谷，本文从轻量限流、消息队列到分布式排队，拆解一套开学选课秒杀链路的实操方案,帮你用最少的机器扛住最大的瞬时压力。
刚开学选课一瞬间高并发怎么解决
选课系统的高并发问题，和电商秒杀本质相似，但有个明显区别：教务系统往往没有弹性扩容的预算，服务器就那几台，还必须保证所有学生都能选上课，业内专家指出，削峰填谷的核心思路不是硬扛流量，而是把瞬间的压力“拉平”到更长的时间窗口去消化。
削峰针对的是请求进系统的入口不能让所有请求同时打到数据库上。填谷针对的是系统处理能力的释放高峰过去后，后台继续慢慢处理排队中的任务，两者配合,才能在有限的资源下完成全校选课。
高峰瞬间系统做的三件事：
- 客户端控制：限制单位时间内的请求次数，超出部分直接返回“排队中”
- 网关层拦截：在到达业务代码之前过滤掉无效请求，比如重复点击
- 服务端排队：真正有资格选课的请求先进队列，按顺序处理，而不是直接查库
这套链路的核心在于，先保证“请求被接收”，后面再慢慢消化，学生看到的是“等待中”,但实际上请求已经稳稳妥妥地躺在队列里。
请求削峰填谷是什么意思
一句话理解：削峰填谷就是把一瞬间集中的流量高峰削掉,把压力摊到后面的时间段慢慢处理。
以选课场景为例，上午10点选课开放，假设有2万名学生同时操作，峰值QPS可能冲到8000甚至更高，如果系统直接硬接，数据库几乎瞬间被打满，表现在用户端就是页面转圈、报错、甚至整个系统宕机。
有了削峰填谷,流程变成这样：
- 10:00:00，2万个请求同时在网关层被接收，但业务层只放行200个
- 剩余请求进入排队系统，按到达顺序排队
- 前台页面每3秒向后端问一次“轮到我了吗”
- 后端每秒钟处理200个排队用户，逐个释放
从2万并发变成每秒处理200个，系统压力直接降了一个数量级，学生们虽然多等了一会儿，但不会出现“选不了课”的恐慌。
行业共识认为，削峰填谷的边界取决于队列的吞吐能力和等待时长的平衡，队列处理太慢，学生等太久会反复刷新，进一步加剧压力；处理太快,又可能超出后端承载能力。
选课系统排队不掉线的轻量限流方案
如果你的学校没有复杂的基础设施，打算用Nginx加一台后端服务器扛住选课,可以参考下面的轻量方案。
Nginx层限制并发
Nginx自带的limit_req模块做请求速率限制,按IP或按统一入口限流：
limit_req_zone $binary_remote_addr zone=course_api:10m rate=50r/s;
server {
location /api/course/select {
limit_req zone=course_api burst=200 nodelay;
proxy_pass http://backend_server;
}
}
这样配置后，每个IP每秒最多50个请求，超过部分直接返回503，学生按一次F5、两次F5没问题,连按十次就会被拦下来。
Redis做分布式令牌桶
多个后端实例场景下，Nginx的本地限流就不够用了，需要统一控制总量，用Redis存一个计数器，每秒钟重置,通过Lua脚本保证原子性：
local current = tonumber(redis.call('get', KEYS[1]) or "0")
if current < tonumber(ARGV[1]) then
redis.call('INCR', KEYS[1])
return 1
else
return 0
end
每次请求进来，先执行这段Lua脚本，返回1的放行，返回0的直接返回“系统繁忙”,把每秒放行数控制在后端能承受的安全水位上。
接入层排队页面
让学生直接看到“当前排队人数：xxx”而不是“系统错误”，能大幅减少无意义的刷新，前端轮询接口拿到排队序号，每几秒更新一次进度，这个页面本身是静态的,即使请求量大也比动态接口轻得多。
当排队人数动态变化时，轮询预热机制能进一步减轻压力：过期的排队序号不再处理，自动把新请求排到队尾,避免静态字段越滚越大。
开学选课秒杀链路的消息队列实战
请求进来只是第一道门槛，真正掏数据的动作在队列里完成，消息队列是目前实现削峰填谷最通用的方案，理由很简单：它可以暂存海量请求,并且让消费者按自己的节奏处理。
核心链路三步走：
- 用户发起选课请求，先校验基础信息（学号、选课资格）
- 校验通过后，把选课请求封装成一条消息，塞进消息队列
- 后台消费者按固定速率从队列取消息，真正执行写库动作
以RabbitMQ为例，消费者可以手动设置消费速率,比如每秒拉取200条消息：
@RabbitListener(queues = "course_select_queue", concurrency = "10")
public void handleCourseSelect(CourseSelectMessage message) {
// 执行数据库写入
courseSelectionService.select(message.getStudentId(), message.getCourseId());
}
并发数设置为10，每条消息处理耗时50毫秒，理论吞吐就是每秒200条，即使消息积压了1万条，队列也能兜住，不会丢数据,只会延后处理时间。
如果学生没有第一时间排到心仪课程，也可启动候补确认机制：课程名额占满后自动进入等位队列，有学生退课时，系统按候补顺序自动匹配补位,替代人工反复刷新捡漏的体验。
消息队列方案里有个细节值得注意：消息的幂等性，同一个选课请求，可能因为消费者失败重试而被重复消费，要解决这个问题，数据库里的选课记录要加唯一约束，学号+课程ID”做联合唯一索引,这样重复执行也不会插入两条记录。
选课系统后端改版的分布式排队怎么做
消息队列解决了“消息进来后怎么办”，但还有一个问题：队列满了怎么办？如果开放瞬间请求量远大于队列的承载量，消息队列本身也会被冲爆，这时候需要分布式排队,把排队动作提升到独立服务层。
一种比较成熟的模式是基于Redis的有序集合排队：
- 用户请求到达后，生成一个自增序号，写入Redis的ZSet中
- 后台采用异步预检查策略，在用户还在排队时提前校验资格条件，轮到用户时直接执行选课，缩短每一步操作的响应时间
- 轮询接口返回用户的排名位置
- 当用户的排名到达处理窗口时，把该请求从ZSet取出来，放入消息队列执行选课
这个方案的优点是排队状态在Redis中，多个后端实例都能读到，支持水平扩展，而且学生在页面上能看到“你前面还有xx人”,体验更友好。
更进阶的做法，是引入分布式选课网关：
| 功能 | 说明 | 实现方式 |
|---|---|---|
| 总闸限流 | 全校选课总控并发数 | Redis集群计数器 |
| 分闸排队 | 按学院/年级分队列 | ZSet + 定时器 |
| 流量整形 | 稳定消费速率 | 消息队列消费者并发控制 |
| 超时兜底 | 防止选中超时导致死锁 | 定时扫描释放超时请求 |
万级用户同时抢课的参考答案：
- 选课请求提交后先进入“待处理池”
- 后台每1秒从待处理池捞取一批用户，放入消息队列
- 消费者完成选课，写库后更新状态
- 用户端轮询状态变更，轮询间隔建议2-5秒，避免频繁请求
还要预留一个兜底逃生通道：如果Redis不可用，降到本地内存队列；如果消息队列堆积超过阈值，启动熔断，只保留查询功能，关闭选课入口，绝大多数高并发系统出问题，不是入口扛不住,而是链路上某一环先崩了。
Q&A：开学选课系统高并发常见疑问
问：选课系统高并发和电商秒杀方案有什么区别？
答：电商秒杀追求的是“极致的快”，几秒内完成库存扣减，选课系统更看重“每个人都处理完”，对延迟的要求反而没那么高，选课可以让学生等5秒、甚至30秒，只要最终能选上就行，所以相比之下，选课系统更适合用排队方案，因为排队时长可控,对用户体验的伤害也更小。
问：请求削峰填谷适合什么样的学校场景？
答：适合选课人数多但服务器预算有限的高校、职业院校和培训机构的教务管理系统，如果学校本身有完整的弹性云资源，直接扩容扛住峰值也没问题，但用削峰填谷能把成本控制在扩容方案的零头，效果差别不大。如果峰值QPS在2000以上，机器只有两到三台，那削峰填谷基本是唯一可行的方案。
问：学生端显示排队顺序但不掉线怎么做？
答：页面用长轮询替代固定间隔的定时刷新，客户端发起请求后，服务端保持连接挂起一段时间，比如10秒，超时或状态变化才返回结果，连接挂起期间服务端不处理额外逻辑，数据库压力小，学生也不会因为页面跳表或丢失队列位置而疯狂刷新,后端收到的无效请求自然也少了。