字节一面经典场景题：业务系统QPS突然提升100倍，怎么办？
这道题在字节跳动（尤其是后端/架构方向）面试中超级高频，考察你对高并发系统设计、应急处理和架构演进的全面理解。别直接说“加机器扩容”，那只会得基本分——面试官想听的是系统性思维：从监控发现、原因分析，到短期应急、中期优化、长期预防的全链路方案。
标准回答框架（建议按这个结构说，逻辑清晰、加分多）
第一时间：监控报警 + 快速定位
- 系统有完善监控（Prometheus + Grafana 或字节内部工具），QPS/CPU/延迟/错误率等指标实时报警。
- 登录系统查看日志、链路追踪（Zipkin/Jaeger），定位是全局流量还是单个接口？是正常爆发（活动/热点）还是异常（攻击/爬虫/BUG）？
原因分析（区分场景）
- 正常业务增长：如大促、热点事件、病毒传播。
- 异常流量：DDoS/CC攻击、恶意刷接口、代码BUG导致重试风暴。
- 如果是攻击，先上报安全团队，启用云WAF/CDN高防。
短期应急（保核心可用，分钟级响应）
- 限流 + 熔断 + 降级：网关层（Nginx/Sentinel/Hystrix）限流，超阈值直接返回429或友好提示；非核心功能降级（如推荐降级为默认）。
- 流量清洗：用CDN隐藏源站，拦截异常IP/User-Agent。
- 快速扩容：云环境（阿里云/腾讯云/K8s）自动/手动弹性扩容实例、读从库。
- 缓存应急：热点数据快速上Redis本地缓存，防DB崩。
中期优化（小时/天级，扛住高峰）
- 缓存：热点数据上多级缓存（本地Heap + Redis），防雪崩（随机过期 + 降级）。
- 异步化：非核心逻辑（如日志、通知、积分）投MQ（Kafka/RocketMQ）削峰。
- 分库分表 + 读写分离：水平扩展DB，ShardingSphere/Canal同步。
- 静态化/CDN：前端资源全静态，动静分离。
长期预防（架构演进）
- 压测：定期全链路压测（JMeter/Gatling），模拟100倍流量，找瓶颈。
- 分布式 + 无状态：微服务、集群部署，负载均衡（LVS/Nginx）。
- 监控 + 演练：全链路监控 + 混沌工程（Chaos Monkey）演练故障。
- 自动扩缩容：K8s HPA + 云监控规则。
高并发应对“9字真经”表格（字节爱考，背下来）
很多面经提到这个，面试甩出来超加分：
| 字 | 含义 | 具体措施 | 场景示例 |
|---|---|---|---|
| 压 | 压力测试 | JMeter全链路压测，找瓶颈 | 上线前模拟高峰 |
| 分 | 分片/拆分 | 分库分表、微服务拆分 | DB/单表瓶颈 |
| 缓 | 缓存 | Redis + 本地缓存 + CDN | 热点读 |
| 异 | 异步 | MQ削峰、异步写 | 非核心逻辑 |
| 限 | 限流 | Token Bucket/Leaky Bucket + Sentinel | 防刷/攻击 |
| 降 | 降级 | 熔断、非核心关闭 | 系统过载时保核心 |
| 扩 | 扩容 | 水平/垂直扩容 + 自动弹性 | 短期扛流量 |
| 监 | 监控 | 全链路指标 + 报警 | 实时发现问题 |
| 演 | 演练 | 混沌工程 + 故障演练 | 提升系统韧性 |
面试Tips
- 别只说扩容：那是最低级答案，面试官会追问“如果机器不够/扩容慢/DB扛不住呢？”
- 结合字节业务：字节流量大（如抖音热点），可以说“类似抖音视频爆火，流量100倍，用缓存+异步+限流扛住”。
- 数据化：说“原QPS 1k → 100k，目标RT<200ms，错误率<0.1%”。
- 反问：如果面试官追问细节，可以说“取决于业务类型，是读重还是写重？”
这个答案结构化+全面，字节面试官爱听（面经反馈过率高）。如果你面过字节，分享下真实经历？下一个问题是“10万QPS怎么设计”😂 加油，冲！
)