为什么服务器会扛不住大量请求？
你有没有遇到过双十一抢购时页面卡死、APP直接转圈的情况？其实问题不在你的手机或网络，而是服务端被成千上万的请求“挤爆”了。就像一家小店突然来了几万人排队买限量商品，店员再快也忙不过来。
当大量用户同时访问一个服务，比如直播秒杀、抢票、热门文章发布，服务器如果没做好准备，轻则响应变慢，重则直接宕机。那服务端是怎么应对这种高压场面的？
用负载均衡把流量分摊出去
最简单的思路就是“人多分组”。一台服务器扛不住，那就上多台。通过负载均衡器（比如 Nginx、LVS），把 incoming 请求像发牌一样均匀分配到不同的后端服务器上。
比如你访问 taobao.com，背后可能是几百台服务器在轮流干活。用户无感知，但系统压力被大大稀释。常见的策略有轮询、IP哈希、最少连接数等，按实际场景选就行。
动静分离，让静态资源走高速通道
不是所有请求都需要后端计算。图片、CSS、JS 这类静态文件完全可以交给 CDN（内容分发网络）来处理。用户从离自己最近的节点获取资源，既快又省服务器力气。
比如你在北京刷一个广东的网站，CDN 会自动从北京的缓存节点返回图片，而不是每次都回源到广东的服务器。这样主服务就能专心处理登录、下单这类动态逻辑。
异步处理 + 消息队列削峰填谷
面对瞬时高峰，硬扛不如“缓一缓”。比如用户提交订单，系统不必立刻完成所有步骤，而是先把请求扔进消息队列（如 Kafka、RabbitMQ），然后由后台服务慢慢消费。
这就像餐厅高峰期取号排队，厨师按顺序做菜，不会因为一下子涌进50个人就乱套。用户看到“已提交”就行，实际处理可以延后。
数据库优化是关键防线
很多性能瓶颈其实在数据库。大量请求查同一张表，MySQL 很容易成为短板。常见做法包括读写分离——写操作走主库，读操作分给多个从库。
还可以加缓存层，比如用 Redis 存热门数据。比如微博热搜榜，每秒被查几万次，直接查数据库肯定崩，但放在 Redis 里，内存读取微秒级响应。
GET <key> // 从Redis快速取值限流和降级，主动控制损失范围
当流量实在太大，系统可以选择“自保”。限流就像地铁限流闸机，只放行一定数量的请求，超出的直接拒绝或排队。常用算法有令牌桶、漏桶。
降级则是牺牲非核心功能。比如大促时关掉商品评论、推荐列表，优先保障下单链路畅通。用户体验略有影响，但至少主流程能跑通。
代码层面也要高效
再好的架构也架不住低效代码。避免在循环里查数据库，减少不必要的序列化操作，合理使用连接池，都是基本功。
比如用连接池管理数据库连接，而不是每次请求都新建连接：
// 使用 HikariCP 管理数据库连接池
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/test");
config.setUsername("root");
config.setPassword("123456");
config.setMaximumPoolSize(20);
HikariDataSource dataSource = new HikariDataSource(config);这样既能复用连接，又能控制并发量，避免数据库被拖垮。
真实场景中的组合拳
没有哪一种技术能单挑全场。实际项目中，往往是负载均衡 + 缓存 + 队列 + 限流一起上。比如一个高并发 API 接口，前端走 CDN，入口用 Nginx 分流，中间加 Redis 缓存结果，数据库读写分离，超量请求直接限流返回提示。
系统设计就像搭积木，每一块都有它的位置。关键是提前预判流量规模，做好弹性扩容预案，别等到出事才临时救火。