前言
大家好，我是大华。今天我们来聊一个经典面试题：
"如果你负责的系统，流量突然提升100倍，你会怎么办？"
这个问题看似具有一定挑战性，但实际上考察的是候选人的系统设计能力、应急处理思维以及实战经验。
不管是开发、运维还是系统架构师，这类高并发场景的处理思路都是必须掌握的核心能力。
我们下面一步步分析这个问题的解决方案。
一、为什么会突然流量暴增？
系统流量不会无缘无故就突然暴涨，常见原因有：
热点事件驱动 ：如明星八卦、重大体育赛事等突发新闻 商业活动推动 ：电商大促（双十一、618等）、大型营销活动 安全攻击 ：DDoS攻击、恶意爬虫等 产品特性爆发：抽奖活动、红包功能、病毒式传播内容
说白了就一句话：流量远超系统原有设计的容量，如果不及时处理会导致系统崩溃。
二、怎么办？先抗住，再优化！
我的应对原则是：
先保命，再治病。
也就是先保证系统不挂，再逐步优化。
下面我分几步来说，配合Java代码示例。
第1步：快速限流，别让流量打垮系统
流量突然冲进来，第一反应一定是：先拦掉一部分，保证系统不崩溃。
常用的限流方式：
- 计数器限流（简单粗暴）
- 滑动窗口限流（更平滑）
- 令牌桶算法（常用）
- 漏桶算法（均匀输出）
举个Java代码例子（用Google Guava的RateLimiter）：
java
import com.google.common.util.concurrent.RateLimiter;
public class RateLimiterDemo {
// 每秒允许10个请求
private static final RateLimiter limiter = RateLimiter.create(10.0);
public void serveRequest() {
if (limiter.tryAcquire()) {
// 处理请求
doBusiness();
} else {
// 直接返回"系统繁忙"，别让请求积压
returnBusy();
}
}
}注意：限流策略要根据业务来。
比如核心业务可以限流少一点，非核心业务可以直接降级。
第2步：服务降级，保核心弃次要
流量太大时，必须牺牲部分功能，保证核心流程畅通。
比如一个电商系统，你可以：
- 关闭推荐服务
- 关闭积分计算
- 关闭非核心弹窗
但下单、支付流程必须保住。
Java中可以用Hystrix或Sentinel做降级，简单版可以自己写个开关：
java
@Service
public class OrderService {
@Autowired
private ServiceDegradeConfig degradeConfig;
public void createOrder(Order order) {
if (degradeConfig.isRecommendServiceClosed()) {
// 跳过推荐相关逻辑
skipRecommendationLogic();
}
// 继续处理核心业务流程
processCoreBusiness();
}
}第3步：缓存一切可以缓存的
缓存是抗高并发的神器。包括：
- Redis缓存：热点数据全部放
Redis，减少数据库压力 - 本地缓存：用
Caffeine/Guava Cache，抗极端热点 - 页面静态化：比如商品详情页生成静态HTML
Java代码示例（Redis + Spring Cache）：
java
@Cacheable(value = "userCache", key = "#userId", unless = "#result == null")
public User getUserById(String userId) {
return userRepository.findById(userId);
}记住：缓存一定要设过期时间，避免数据不一致问题。
第4步：数据库优化，避免被打穿
数据库是最容易挂的一环。优化方式：
- 读写分离：主库写，从库读
- 分库分表：流量太大时可以考虑（但紧急情况下可能来不及）
- SQL优化：避免慢查询
- 连接池调优：加大连接数（但别太大）
Druid连接池配置示例：
java
// 示例：Druid连接池配置
@Configuration
public class DataSourceConfig {
@Bean
public DataSource dataSource() {
DruidDataSource dataSource = new DruidDataSource();
dataSource.setMaxActive(100); // 最大连接数
dataSource.setMaxWait(1000); // 最大等待时间(ms)
dataSource.setTestWhileIdle(true);
return dataSource;
}
}第5步：异步化，削峰填谷
把同步操作改成异步，用MQ消峰。
比如：用户下单后，先快速返回成功，然后通过MQ慢慢处理库存、短信通知等。
Java + RabbitMQ示例：
java
@Service
public class OrderService {
@Autowired
private RabbitTemplate rabbitTemplate;
public void createOrder(Order order) {
// 同步处理核心业务
orderRepository.save(order);
// 异步处理后续操作
rabbitTemplate.convertAndSend("order.exchange",
"order.routingKey",
order);
}
}第6步：扩容！扩容！扩容！
硬件层面是最直接的：
- 加机器：水平扩展，快速提升系统容量
- 弹性伸缩：如果用云服务（如AWS、阿里云），可以设置自动扩容
注意：扩容之前要做好无状态服务设计，否则
Session等问题会麻烦。
三、长远来看：如何预防？
临时抗住之后，还得从根本上优化：
- 全链路压测：提前模拟大流量，找到瓶颈
- 熔断降级方案常态化：比如Sentinel配置自动规则
- 业务设计解耦：核心和非核心分离
- 监控报警：APM、日志监控、业务指标都要有
总结
- 限流、降级、缓存、异步、扩容是短期救急五大法宝。
- 系统设计、压测、监控是长期保障。
- 实际工作中要结合业务灵活运用。
希望下次碰到这种问题时，你能对答如流！
公众号：程序员刘大华，专注分享前后端开发的实战笔记。关注我，少走弯路，一起进步！
📌往期精彩
《Java8 都出这么多年了，Optional 还是没人用？到底卡在哪了？》
《90%的人不知道！Spring官方早已不推荐@Autowired？这3种注入方式你用对了吗？》