高并发与高可用

概览

面试权重：★★★ | 适用级别：P7/P8+ | 预计复习时间：1-2周

这一章不仅考“会不会缓存、限流、熔断”，更考“如何从零到一设计一个高并发系统，以及如何随着业务增长做架构演进”。

建议用法

先把正文里的“设计起手式、分层框架、稳定性组件、典型场景”串成一条完整回答链，再用后面的高频题做 30 秒口述训练。讲不顺时，优先回看对应正文，而不是继续堆题。

一、知识体系

1. 从零到一设计高并发系统 ★★★

1.1 设计起手式：先问目标，再谈技术 ★★★

核心结论
- 高并发题最容易失分的地方，不是方案不够花，而是没有先把业务目标、峰值流量、SLA 和成本约束讲清楚。
- 高级岗面试官通常先听你如何定义问题，再看你如何选技术，而不是反过来。
先澄清
- 核心业务链路是什么，哪一步最不能失败
- 峰值 QPS、日请求量、读写比例、峰值持续多久
- TP99、可用性、成本预算目标
- 是否允许排队、降级、最终一致
原理展开
- 技术方案永远是约束驱动的。比如同样是下单链路，如果要求强一致、秒级回执、预算充足，方案会明显不同于“允许异步、允许降级、追求低成本”的场景。
- 先问清“并发打在哪里”，才能决定是先挡入口、先拦数据库，还是先处理下游依赖抖动。
面试怎么答
- “我会先把题目收敛成四个输入：业务主链路、峰值流量、SLA 目标、成本和一致性边界。输入没定，后面的缓存、MQ、分库分表都只是空谈。”
易错点
- 一上来就说 Redis、MQ、分库分表，面试官通常会继续追问“为什么一定需要”。
面试表达顺序建议
1. 需求和约束
2. 容量估算
3. 高层架构
4. 核心链路
5. 稳定性与演进

1.2 容量规划与压测 ★★★

核心结论
- 容量规划不是算一个平均值，而是确定“系统在哪个量级开始不安全”，并为峰值和故障转移预留缓冲。
容量估算
- 并发数 ≈ QPS × 平均 RT
- 先估入口流量，再估数据库、缓存、MQ、下游服务
- 峰值容量要结合活动系数和冗余系数
压测怎么看才有价值
压测方法
- 基准压测：单接口、单依赖、单机能力
- 链路压测：核心下单、支付、查询链路
- 全链路压测：入口到存储的端到端验证
重点观察
- TP99、错误率、CPU、GC、线程池队列、Redis 命中率、DB 慢查询、MQ 积压
原理展开
- 真正有用的压测结果，一定能回答两个问题：当前主瓶颈在哪一层，以及扩容后是否还能线性提升。
- 如果单机 CPU 很空，但 TP99 仍然抖动，问题往往不在应用本身，而在数据库、网络、线程池排队或 GC。
面试怎么答
- “我会先做容量估算，再用基准压测和链路压测验证。压测不是为了拿一个极限 QPS，而是为了定位瓶颈层级和安全水位。”
易错点
- 只报平均 RT，不报 TP99、错误率和资源水位，结论通常不可信。

1.3 分层设计框架 ★★★

核心结论
- 高并发系统不是靠某一个中间件扛住，而是靠分层过滤流量，把真正贵的请求拦在尽量靠前的位置。
接入层
- CDN、Nginx、Gateway、WAF、限流、验证码、流量预热
服务层
- 无状态部署、池化、批处理、并行调用、超时预算、隔离舱
缓存层
- JVM 本地缓存 + Redis + CDN，多级缓存协同
异步层
- MQ 削峰、异步下单、延迟任务、补偿任务
数据层
- MySQL、读写分离、冷热分离、分库分表、索引优化
治理层
- 监控告警、链路追踪、开关、灰度、回滚、应急预案
原理展开
- 接入层解决“无效流量太多”，缓存层解决“热点读太贵”，异步层解决“峰值写太尖”，治理层解决“故障时能不能稳住并快速回滚”。
- 高级岗要能把这些层之间的职责边界说清楚，而不是把所有问题都交给 Redis 或 MQ。
面试怎么答
- “我的思路是分层消峰：入口先拦无效流量，缓存层先吃热点读，异步层把高峰写拉平，最后才让数据库承接核心状态。”

1.4 演进路线：按瓶颈逐步升级 ★★★

常见演进路径
- 单机应用
- 多副本 + 负载均衡
- 缓存 + 限流 + 异步
- 服务拆分
- 分库分表 + 多级缓存
- 同城双活 / 异地多活
原则
- 先解决当前主瓶颈
- 避免一开始就把分布式复杂度拉满
面试怎么答
- “我倾向阶段化演进。先用最小复杂度跑通主链路，等热点、单表、跨服务调用这些真实瓶颈出现，再逐步引入缓存、异步、拆分和容灾。”
易错点
- 用未来三年的假设规模，为当前系统一次性付清全部复杂度成本。

1.5 常见瓶颈与治理思路 ★★★

数据库顶不住
- 缓存、读写分离、批量化、分片、异步化
Redis 热点或大 Key
- 本地缓存、Key 打散、集群扩容、对象压缩
MQ 积压
- 扩容消费者、提升并发、临时旁路、降级非核心链路
下游接口不稳定
- 超时、重试、熔断、降级、隔离
突发流量打爆入口
- 排队、令牌桶、活动预热、静态化、验证码/风控
面试怎么答
- “我不会只给一个通用答案，而是先判断瓶颈位置。DB 不行就先减少落库次数，Redis 不行就先处理热点和大 Key，下游抖动就优先做超时、熔断和隔离。”

2. 高并发设计 ★★★

2.1 缓存策略 ★★★

核心结论
- 缓存的第一目标是减少高频读对数据库的直接冲击，第二目标才是降延迟。
多级缓存架构
- L1：JVM 本地缓存（Caffeine/Guava Cache）
- L2：分布式缓存（Redis）
- L3：CDN / Nginx 缓存
缓存模式
- Cache Aside（旁路缓存）★★★：最常用，业务可控性最好
- Read Through / Write Through
- Write Behind（异步写回）
缓存设计的面试重点
原理展开
- 本地缓存擅长拦极热点，Redis 擅长跨实例共享，CDN 擅长把静态或弱动态流量挡在源站外。
- 真正常见问题不是“要不要上缓存”，而是缓存穿透、击穿、雪崩和一致性如何控制。
缓存一致性（详见中间件篇 Redis 部分）
热点数据发现与本地缓存
面试怎么答
- “我会优先用 Cache Aside 做主模式，再按热点程度叠加本地缓存。核心不是只讲命中率，而是讲清失效策略、回源保护和一致性容忍度。”
易错点
- 把所有数据都塞进 Redis，而不区分热点、更新频率和容错边界。

2.2 异步化 ★★★

核心结论
- 异步化的价值在于把用户请求链路里的非核心步骤移出同步路径，换取更稳的 RT 和更高的吞吐。
消息队列异步解耦
CompletableFuture 异步编排
事件驱动架构（EDA）
线程池异步处理
异步的代价
- 一致性问题、排查复杂、链路更长
原理展开
- 适合异步的通常是通知、积分、日志、画像更新这类可延后动作；不适合异步的是“请求一返回就必须对用户可见”的核心交易状态。
面试怎么答
- “异步不是默认更高级，而是用同步确定核心状态，用异步延后非关键动作。每引入一次异步，就必须补上重试、幂等、补偿和监控。”
易错点
- 为了追求吞吐，把关键一致性步骤也异步化，最后靠人工补偿兜底。

2.3 池化技术 ★★

核心结论
- 池化的本质是复用昂贵资源，减少反复创建销毁的成本，但前提是边界清晰、容量可控。
线程池（ThreadPoolExecutor）
连接池（HikariCP/Druid）
对象池（Apache Commons Pool）
池化参数调优
面试怎么答
- “线程池重点看队列长度、拒绝策略和上下游超时匹配；连接池重点看连接创建成本、最大连接数和数据库承受上限。”
易错点
- 线程池和连接池都不是越大越好，配置过大只会把问题延后到更深层的依赖。

2.4 数据库层优化 ★★★

核心结论
- 高并发系统最终还是要回到数据库，因为核心状态要落地。前面所有优化，本质上都是为了减少数据库被无效或不必要请求打爆。
读写分离
分库分表（详见数据库篇）
数据冷热分离
查询优化与索引优化
数据库连接池配置
原理展开
- 先优化 SQL 和索引，再谈分片；先判断热点表和热点行，再决定拆法；先确认是否真的是数据库瓶颈，再决定是否加一层缓存。
面试怎么答
- “数据库优化我会按顺序做：慢 SQL 和索引治理、连接池和事务边界优化、读写分离、再考虑分库分表。分片是最后手段，不是起手式。”

2.5 接口性能优化 ★★★

减少 IO 次数：批量操作、Pipeline
减少序列化开销：Protobuf > JSON > XML
减少网络往返：合并请求、本地缓存
并行调用：CompletableFuture 并行调用多个下游
数据压缩：gzip / snappy
惰性加载与按需查询
面试怎么答
- “接口优化优先看调用链里最贵的远程 IO，再决定是合并、并行、缓存还是异步。只有在 IO 成本降下来后，序列化和压缩优化才真正有意义。”

3. 高可用设计 ★★★

3.1 限流 ★★★

核心结论
- 限流不是简单拒绝请求，而是在系统承载边界内，优先保住核心链路。
限流算法
- 固定窗口：简单但有边界突发问题
- 滑动窗口：精确但内存开销大
- 漏桶（Leaky Bucket）：匀速输出
- 令牌桶（Token Bucket）：允许突发 ★★★
限流粒度
- 接口级限流
- 用户级限流
- IP 级限流
- 全局限流 vs 单机限流
实现方式
- Sentinel（推荐，功能全面）
- Guava RateLimiter（单机）
- Nginx 限流（ngx_http_limit_req_module）
- 网关层限流（Spring Cloud Gateway）
面试怎么答
- “令牌桶更适合业务流量，因为能允许短时突发；固定窗口简单但容易抖；真正落地时还要讲限流位置、限流粒度和被限后返回什么。”
易错点
- 只讲算法，不讲限流命中后如何做友好降级、排队或快速失败。

3.2 熔断 ★★★

核心结论
- 熔断是为了在下游持续失败时，主动切断调用，避免把故障扩散成线程池耗尽和级联雪崩。
熔断器模式（Circuit Breaker）
- Closed → Open → Half-Open
- 滑动窗口统计失败率
快速失败（Fail Fast）
超时设置的艺术
- 连接超时 vs 读超时
- 超时传播与超时预算
面试怎么答
- “熔断不是单独用的，要和超时、隔离、降级一起说。没有超时预算的熔断配置，通常会误判或迟钝。”
易错点
- 把熔断等同于降级。熔断是触发机制，降级是兜底策略。

3.3 降级 ★★★

核心结论
- 降级是主动选择保核心、舍边缘，让系统在不完美状态下继续服务。
降级策略
- 返回默认值或缓存值
- 功能降级（关闭非核心功能）
- 人工降级开关
降级 vs 熔断的区别
- 熔断：被动触发，保护自身
- 降级：主动策略，保障核心
面试怎么答
- “降级要先区分核心功能和边缘功能。比如下单页必须活着，推荐、评论、画像刷新这些都可以临时牺牲。”

3.4 重试与幂等 ★★★

核心结论
- 重试解决的是临时失败，幂等解决的是重试或重复请求带来的重复执行风险，两者必须成对出现。
重试策略
- 固定间隔 / 指数退避（Exponential Backoff）
- 最大重试次数
- 可重试条件（超时 / 网络异常 vs 业务异常）
幂等设计 ★★★
- 唯一请求 ID + 去重表
- Token 机制（前端获取 token，后端校验消费）
- 数据库唯一约束
- 状态机控制
原理展开
- 只要系统有超时重试、消息重复投递、客户端重复提交，就一定会遇到幂等问题。面试里别把幂等只讲成“加个唯一索引”，要说明幂等键、去重窗口和状态机约束。
面试怎么答
- “我会先区分哪些错误可重试，再配合指数退避和抖动控制重试风暴；所有可重试链路都要补幂等，不然重试只是在放大事故。”
易错点
- 对业务异常也盲目重试，或者只做应用层幂等、不做数据库侧兜底。

3.5 容灾与冗余 ★★

多机房部署（同城双活 / 异地多活）
数据冗余与备份策略
故障转移（Failover）
故障演练（Chaos Engineering）
面试怎么答
- “容灾不是多加机器，而是明确故障域、切流策略和数据恢复方式。真正难的是切换后的数据一致性和回切策略。”

4. 性能优化方法论 ★★★

4.1 性能指标

QPS / TPS / RT
TP99 / TP999
吞吐量 vs 延迟的权衡
并发数 = QPS × 平均 RT
面试怎么答
- “我会同时看吞吐、延迟和错误率。只提高 QPS 但 TP99 崩掉，不算真正的性能优化。”

4.2 性能分析工具

JVM：JProfiler、Arthas、async-profiler
数据库：slow query log、EXPLAIN
全链路：SkyWalking、Pinpoint
压测：JMeter、wrk、Gatling
面试怎么答
- “工具只是定位手段，关键是形成从监控告警到代码热点、SQL、依赖调用的分层排查路径。”

4.3 性能优化思路 ★★★

找瓶颈：先观测再优化（不要盲目优化）
定位层级：网络 → 应用 → 数据库 → 中间件
优化方向
- 缓存：减少计算和 IO
- 异步：非关键路径异步化
- 并行：利用多核并行处理
- 批量：减少交互次数
- 压缩：减少传输量
- 预处理：提前计算

面试怎么答
- “优化方法论的核心是闭环：先测量，再定位，再优化，再回归验证。如果没有基线和回归数据，所谓优化只是感觉。”

5. 典型高并发场景 ★★★

5.1 秒杀系统 ★★★

核心结论
- 秒杀的本质是用层层过滤，把大部分无效流量挡在数据库之外，只让少量合法请求进入核心扣库存链路。
前端：静态化、CDN、按钮防重
网关：限流、过滤无效请求
服务层：内存预减库存、异步下单
数据层：Redis 原子扣减、队列串行化
超卖问题：Redis Lua + 数据库乐观锁兜底
面试怎么答
- “我会从入口、库存、下单、落库四层去讲。核心是两次过滤、一次原子扣减、一次数据库兜底，而不是只说 Redis 秒杀脚本。”

5.2 订单系统 ★★★

下单流程：创建订单 → 扣库存 → 扣款 → 通知
分布式事务保障
订单超时取消：延迟队列 / 时间轮
核心关注：幂等、状态机、对账、补偿
面试怎么答
- “订单系统重点不只在高并发，更在状态流转正确。下单成功但支付超时、重复支付、库存回补失败，都要用状态机和补偿链路兜住。”

5.3 Feed 流系统 ★★

推模式（Push） vs 拉模式（Pull） vs 推拉结合
大 V 问题的处理
Timeline 排序
面试怎么答
- “Feed 的关键不是背 Push/Pull 定义，而是说明不同粉丝规模下写扩散和读扩散的 trade-off，以及缓存如何配合时间线读取。”

二、高频面试题

基础级（P7必答）

从零到一设计一个高并发系统时，你会先确认哪些信息？

30秒答法
- “我会先确认四类输入：核心业务链路、峰值 QPS 和读写比例、TP99 与可用性目标、是否允许排队降级和最终一致。先把问题定义清楚，再决定是先上缓存、限流还是异步化。”
关键词
- 核心链路
- 峰值流量
- SLA
- 一致性边界
追问提醒
- 面试官常继续问：如果这些信息拿不到，你会如何保守估算并给阶段方案？

容量规划为什么不能只看平均 QPS？峰值和冗余怎么考虑？

30秒答法
- “平均 QPS 会掩盖促销、故障切流和瞬时尖峰。容量规划要按峰值流量设计，再乘活动系数和冗余系数，至少让核心链路在单点故障或节点摘除后还能稳定服务。”
关键词
- 峰值流量
- 冗余系数
- 故障切流
- 安全水位
追问提醒
- 可能追问：你会怎么估 Redis、DB、MQ 的容量，而不是只估 Web 层？

高并发系统常见的分层有哪些？每一层分别解决什么问题？

30秒答法
- “我一般拆成接入层、服务层、缓存层、异步层、数据层和治理层。入口先挡无效流量，缓存吃热点读，异步层削峰填谷，数据层承接核心状态，治理层负责监控、灰度和回滚。”
关键词
- 分层过滤
- 热点读
- 削峰填谷
- 治理闭环
追问提醒
- 常见追问是：某一层出问题时，哪些功能该降级，哪些不能动？

如何设计一个限流方案？令牌桶和漏桶的区别？

30秒答法
- “如果业务允许短时突发，我优先选令牌桶；如果追求匀速输出，可以考虑漏桶。真正设计时还要同时说明限流位置、粒度、是否分布式，以及被限后是排队、降级还是快速失败。”
关键词
- 令牌桶
- 漏桶
- 限流粒度
- 快速失败
追问提醒
- 可能追问：全局限流怎么做？Redis + Lua 和 Sentinel 集群限流各有什么特点？

什么是熔断？熔断器的三种状态？和降级的区别？

30秒答法
- “熔断是在下游持续失败时主动断开调用，避免拖垮自己。典型状态是 Closed、Open、Half-Open。熔断是触发机制，降级是兜底策略，通常还要和超时、隔离一起落地。”
关键词
- Circuit Breaker
- Closed/Open/Half-Open
- 超时预算
- 降级策略
追问提醒
- 常见追问：失败率阈值和半开探测流量如何设定？

接口幂等性怎么保证？有哪些实现方案？

30秒答法
- “幂等的核心是让同一个业务请求多次执行结果一致。常见做法是唯一请求 ID、去重表或唯一索引、状态机约束，再配合 Token 或乐观锁。只要链路里有重试或重复提交，就必须补幂等。”
关键词
- 唯一请求 ID
- 去重表
- 状态机
- 乐观锁
追问提醒
- 面试官常追问：幂等窗口多长、跨服务怎么传递幂等键、消息消费幂等怎么做？

多级缓存架构是什么？本地缓存和分布式缓存的一致性问题？

30秒答法
- “常见是 L1 本地缓存、L2 Redis、L3 CDN。热点读先在本地拦截，跨实例共享走 Redis。一致性通常靠失效通知、短 TTL 或版本号控制，不追求绝对实时，而是控制不一致窗口。”
关键词
- Caffeine
- Redis
- 失效通知
- 短 TTL
追问提醒
- 可能继续追问：热点 key、缓存击穿和雪崩时分别怎么处理？

重试策略有哪些？什么情况下不应该重试？

30秒答法
- “我会优先用指数退避加随机抖动，只对超时、瞬时网络异常这类可恢复错误重试。对业务异常、非幂等操作和下游明确过载场景，不应该盲目重试。”
关键词
- Exponential Backoff
- Jitter
- 可恢复错误
- 幂等前提
追问提醒
- 常见追问：客户端重试、网关重试、服务端重试三层叠加时怎么避免重试风暴？

如何排查一个接口响应慢的问题？

30秒答法
- “我会按链路分层排查：先看全链路追踪和监控确定慢在哪层，再看应用热点、线程池排队、SQL 和缓存命中率，最后再决定是扩容、优化 SQL、加缓存还是做异步化。”
关键词
- 链路追踪
- 线程池
- 慢 SQL
- 缓存命中率
追问提醒
- 面试官可能追问：如果 CPU 很低但 RT 很高，你最先怀疑什么？

线程池参数怎么设置？CPU 密集型和 IO 密集型的区别？

30秒答法
- “线程池参数要结合任务类型和下游延迟看。CPU 密集型更关注核数和上下文切换，IO 密集型要考虑等待时间和队列长度。生产上更重要的是有界队列、拒绝策略和动态观测，而不是死背一个公式。”
关键词
- 核数
- 有界队列
- 拒绝策略
- 动态调优
追问提醒
- 常见追问：为什么线程池开太大反而会让 RT 变差？

什么是指数退避？为什么要加随机抖动（jitter）？

30秒答法
- “指数退避是让重试间隔按倍数增长，避免错误发生时继续打爆下游；随机抖动是把多个客户端的重试时刻打散，防止惊群效应。”
关键词
- 指数退避
- Jitter
- 惊群
- 重试风暴
追问提醒
- 可能追问：退避上限怎么设？服务端返回 429/503 时要不要动态调整？

Reactor 线程模型是什么？在高并发中如何应用？

30秒答法
- “Reactor 是基于事件驱动和 IO 多路复用的模型。单 Reactor 适合简单场景，主从 Reactor 多线程更适合高并发网络服务。典型落地是 Netty、Spring WebFlux 和基于 Netty 的网关。”
关键词
- NIO
- 多路复用
- Boss/Worker
- Netty
追问提醒
- 常见追问：Reactor 和传统线程池阻塞模型的适用边界分别是什么？

进阶级（P8+深挖）

如何设计一个异地多活架构？数据一致性怎么解决？

30秒答法
- “异地多活的核心不是多部署几个机房，而是先划清故障域和数据归属。通常按用户或租户路由到归属机房，核心交易数据尽量单元化处理，跨机房数据走异步同步，并配冲突检测和回切策略。”
关键词
- 单元化
- 故障域
- 异步同步
- 冲突检测
追问提醒
- 面试官常追问：脑裂、双写冲突和切流回切怎么做？

你做过的性能优化中最有成效的是哪次？量化数据？

30秒答法
- “这类题不要堆概念，要按‘场景、瓶颈、动作、结果’说。先说明业务场景和瓶颈证据，再讲你做了哪些缓存、异步、SQL 或架构优化，最后给出 RT、QPS、成本的量化改善。”
关键词
- 场景
- 证据
- 动作
- 量化结果
追问提醒
- 常见追问：如果效果没有达到预期，你怎么继续定位？

高并发下如何做到热点数据的实时更新？

30秒答法
- “热点数据通常用本地缓存加 Redis 双层结构，再通过 MQ 或 Pub/Sub 广播失效。核心不是绝对实时，而是控制一致性窗口，并避免热点 key 把单个 Redis 节点打穿。”
关键词
- 本地缓存
- Pub/Sub
- 热点 key
- 一致性窗口
追问提醒
- 可能追问：极端热点下，如何做 key 打散和多副本读？

秒杀系统从流量入口到数据库的全链路设计？

30秒答法
- “我的思路是层层过滤：前端静态化和 CDN 先挡住大流量，网关限流和风控先筛掉无效请求，Redis Lua 原子扣减控制库存，MQ 异步下单拉平写峰值，数据库乐观锁做最终兜底。”
关键词
- 层层过滤
- Redis Lua
- MQ 削峰
- 乐观锁
追问提醒
- 常见追问：Redis 扣减成功但 MQ 发送失败，或者消费者失败时怎么办？

如何做故障演练（Chaos Engineering）？有什么工具和方法？

30秒答法
- “故障演练要从稳态指标出发，先定义预期，再小范围注入故障，观测系统是否还能保持核心能力，最后复盘并补监控和预案。没有回滚方案和观测指标的演练是危险的。”
关键词
- 稳态假说
- 故障注入
- 观测指标
- 回滚预案
追问提醒
- 可能追问：第一次演练你会挑哪个故障场景，为什么？

一个系统是该优先扩容、拆分还是异步化，你如何判断？

30秒答法
- “先看瓶颈性质。资源型瓶颈优先扩容，模块互相抢资源或边界混乱时考虑拆分，核心链路里存在非必要同步步骤时适合异步化。先定位再动作，不靠直觉选方案。”
关键词
- 资源瓶颈
- 边界拆分
- 非关键同步
- 先定位后动作
追问提醒
- 常见追问：扩容为什么有时几乎不提升吞吐？

如果预算有限，你会如何做高并发系统的分阶段演进？

30秒答法
- “我会优先做投入产出比最高的事情：先优化 SQL 和索引、加缓存、做限流和异步，等流量继续增长再拆分服务、分库分表和做容灾。目标是用最小复杂度解决当前主瓶颈。”
关键词
- ROI
- SQL/索引
- 缓存
- 阶段演进
追问提醒
- 面试官可能继续问：你会用什么指标定义‘该升级到下一阶段’？

设计一个日志收集系统？ELK + Kafka 架构？

30秒答法
- “典型链路是采集端 Filebeat、缓冲层 Kafka、处理层 Logstash 或 Flink、存储检索层 Elasticsearch、展示层 Kibana。关键不是背组件，而是讲清削峰、分区、索引生命周期和脱敏策略。”
关键词
- Filebeat
- Kafka
- Elasticsearch
- ILM
追问提醒
- 常见追问：TB 级日志如何做冷热分层、分片规划和写入吞吐优化？