第2章 高并发系统设计原则与分层架构
本章焦点：掌握高并发系统的核心设计原则（缓存、异步、池化、分库分表）与分层架构（接入层、服务层、数据层）。面试中常被要求“一句话讲清楚你的系统如何支撑10万QPS”，重点考察对“取舍”的理解与抽象表达能力。
面试问答卡片
1. 请说说高并发系统的设计思路有哪些？
面试官考察点：系统设计广度、分层思维、是否理解“成本与效果”平衡。
回答框架：
- 点明核心原则：缓存、异步、池化、读写分离、分库分表
- 按分层阐述：接入层（限流/降级）→ 服务层（异步/熔断）→ 数据层（缓存/分片）
- 强调取舍：根据业务场景权衡一致性、可用性、延迟
简短示例回答：
我会从三个层次设计：接入层用Nginx限流+CDN降级；服务层引入MQ异步解耦，关键接口设置熔断；数据层用Redis缓存热点数据，MySQL按用户ID分库，写入先落缓存再异步刷库。最终在延迟增加20%的情况下，承载了10万QPS。
可能追问：“如果数据一致性要求极高，你的缓存方案怎么调整？” “分库分表后跨库查询怎么处理？”
避坑提醒：不要只背技术名词，一定要给出“取舍”结果；避免说“全都用”而不提代价。
2. 你们系统采用什么分层架构？每个层的作用和挑战是什么？
面试官考察点：实际项目分层经验、底层原理理解、对分层边界和问题的认知。
回答框架：
- 给出典型三层：接入层、服务层、数据层
- 说明每层核心职责：接入层负责路由、限流；服务层负责业务编排、降级；数据层负责缓存和持久化
- 指出每层常见挑战：接入层如何做到无状态？服务层如何避免雪崩？数据层如何保障一致性？
简短示例回答：
我们使用典型的“网关+微服务+分库DB”三层。网关层做全局限流和动态路由；服务层用Hystrix做熔断，把依赖强隔离；数据层MySQL按用户ID哈希分32库，每库主从同步。挑战是服务层超时重试导致雪崩，我们通过线程池隔离+快速失败解决。
可能追问：“网关层做限流用固定窗口还是令牌桶？为什么？” “数据层主从延迟怎么解决？”
避坑提醒：不要只画架构图堆砌组件，要说出每个组件解决了什么具体问题，以及你遇到的真实故障。
3. 假设给你一个系统需要支撑100万QPS读取，你会怎么做？
面试官考察点：极端场景设计能力、容量评估、对成本的理解。
回答框架：
- 先反问业务特征：读多写少？实时性要求？数据量级？
- 给出分层缓存方案：CDN → 本地缓存 → 分布式缓存（Redis集群）→ DB
- 考虑降级：热key探测、二级缓存、限流保护DB
简短示例回答：
假设是读多写少的商品详情页。我会用三层缓存：CDN缓存静态资源，本地Caffeine缓存热门商品（过期时间1秒），Redis集群做全局缓存。预估单个Redis节点约8万QPS，用12个节点分片扛96万，剩余4万靠本地缓存兜底，DB只做兜底fallback。
可能追问：“如果所有流量打到一个热key上怎么办？” “缓存击穿怎么防止？”
避坑提醒：不要一上来就列出所有缓存技术，先通过反问确认场景边界；避免忽略冷数据穿透问题。
知识结构：高并发系统设计原则对比表
| 原则 | 核心手段 | 常见实现 | 适用场景 | 典型代价 |
|---|---|---|---|---|
| 缓存 | 空间换时间 | Redis、Caffeine、CDN | 读多写少、数据变化不频繁 | 一致性维护、缓存雪崩 |
| 异步 | 时间换削峰 | MQ（Kafka/RocketMQ） | 写请求延时敏感度低、消息可靠性要求高 | 系统复杂度增加、数据最终一致 |
| 池化 | 复用连接/线程 | 连接池（Druid）、线程池 | 高并发下资源创建开销大的场景 | 池大小调优、资源耗尽 |
| 读写分离 | 横向扩展读能力 | MySQL主从、Proxy | 读远大于写的场景 | 主从延迟、路由成本 |
| 分库分表 | 水平拆分数据 | ShardingSphere、MyCat | 数据量巨大、单库瓶颈 | 跨库查询、分布式事务 |
面试高频提示：回答设计题时，务必先做“容量估算”（如单机QPS、带宽、内存），再给出分治策略。面试官往往期待你展示“从问题→拆解→解法→风险”的完整闭环，而不是直接背诵方案。