从抢票系统说起
每年春节一到，12306的抢票高峰就像一场全民压力测试。成千上万的人在同一秒点下“提交订单”，如果系统没有合理的调度策略，服务器早就瘫了。这背后，其实是高并发场景调度在起作用。
什么是高并发调度
高并发不是简单地“人多”，而是短时间内大量请求涌入，系统资源（CPU、内存、数据库连接等）面临瞬间耗尽的风险。调度策略的作用，就是合理分配这些资源，让系统不崩、响应不慢。
比如电商大促，用户同时下单，库存扣减如果直接操作数据库，可能引发锁竞争，导致大量请求排队超时。这时候，靠的是任务拆解和异步处理。
常见的调度手段
限流是最基础的一招。像令牌桶算法，给每个接口设定每秒处理能力上限。超过的部分直接拒绝，避免雪崩。
public class TokenBucket {
private long tokens;
private final long capacity;
private final long rate;
private long lastRefillTimestamp;
public boolean tryConsume() {
refill();
if (tokens > 0) {
tokens--;
return true;
}
return false;
}
private void refill() {
long now = System.currentTimeMillis();
long elapsed = now - lastRefillTimestamp;
long fillAmount = elapsed * rate / 1000;
if (fillAmount > 0) {
tokens = Math.min(capacity, tokens + fillAmount);
lastRefillTimestamp = now;
}
}
}除了限流，还有任务队列。把即时请求转为异步处理，比如用户下单后，先返回“已提交”，后续再走消息队列扣库存、发通知。这样前端不卡，后端有条不紊。
负载均衡不只是分摊流量
很多人以为负载均衡就是把请求平均打到多台机器上，其实它还能根据服务器状态动态调整。比如某台机器CPU飙到90%，调度器会自动减少它的权重，甚至暂时摘除，等恢复后再加回来。
实际部署中，Nginx 或 Kubernetes 的 Service 都能实现这种智能转发，配合健康检查，系统稳定性提升明显。
本地缓存+分布式缓存组合拳
高频读取的数据，比如商品信息，每次都查数据库太慢。引入 Redis 做一级缓存，本地 HashMap 做二级缓存，能大幅降低数据库压力。
但要注意数据一致性。缓存更新时，采用“先更新数据库，再删除缓存”的策略，避免脏读。虽然短暂可能读到旧值，但比系统崩溃强得多。
降级预案：该放手时就放手
极端情况下，非核心功能可以临时关闭。比如评论、推荐、积分计算这些，优先保障下单和支付流程。
就像地铁早高峰，安检口只放行通勤乘客，旅游观光的建议错峰——系统也得学会“挑重点”。通过配置中心动态开关，运维人员能在控制台一键降级，快速恢复主链路。
真实场景中的组合应用
某次双十一预热，一个直播带货链接被疯狂转发。运营预计流量会涨十倍，提前做了几件事：增加Redis集群节点、设置接口限流阈值、把用户抽奖逻辑移到MQ后处理、关闭首页非必要动效。
结果流量真的冲上来时，系统平稳接住，只有抽奖结果延迟了几分钟返回，其他功能几乎无感。这就是调度策略的实战价值。