大型系统的核心不是"堆技术名词"，而是：
- 识别瓶颈
- 用架构手段把瓶颈拆开、绕开、扩展掉
这篇按"性能瓶颈 -> 分层架构 -> 数据与缓存 -> 会话管理"的主线整理。
面试与工程都通用的一句话方法论：
- 先观测（指标/日志/链路追踪）定位瓶颈，再做架构优化；不要一上来就"加 Redis/加机器"。
1. 性能瓶颈从哪来：内存 vs IO 的数量级差异
你可以用一句话抓住面试官：
- 内存访问是纳秒级，磁盘/数据库 IO 是毫秒级，差了 10^6 数量级。
所以高并发下最容易被打爆的是：
- 数据库（IO 密集）
2. 缓存（Redis）：为什么能提速，边界在哪里
2.1 Redis 的价值
- Redis 在内存里存取数据，速度远快于磁盘数据库
- 缓存命中时可显著降低 RT，减少数据库压力
2.2 Redis 的边界与注意点
- Redis 不等于"万能加速器"，跨网络 IO 会稀释优势
- 引入缓存会带来一致性、过期、击穿/雪崩/穿透等问题
把三大缓存问题（复习必背）记成一句话：
- 穿透：查不存在的东西一直打到 DB
- 击穿：热点 key 过期瞬间大量请求打到 DB
- 雪崩：大量 key 同时过期导致 DB 扛不住
应对方向（不展开实现细节，面试够用）：
- 穿透：布隆过滤器/空值缓存
- 击穿：互斥更新/热点不过期+异步刷新
- 雪崩：过期时间加随机、分批过期
面试可用一句话：
- 缓存解决读性能和数据库压力，但会引入一致性与缓存失效类问题。
3. 分层与集群：把流量拆开，把压力分散
3.1 前端：CDN + DNS
- CDN：静态资源就近分发，减轻源站压力
- DNS：入口分散，避免单点入口
3.2 后端：Nginx 负载均衡
- 把请求分发到多台应用实例（Tomcat/服务节点）
- 横向扩展：加机器解决并发
一句话：
- LB 的核心价值是把单点吞吐扩展成集群吞吐。
易错点提醒：
- 负载均衡不是万能的：如果下游 DB/缓存是瓶颈，LB 只能把请求"更快地打爆瓶颈"。
4. 数据层：海量数据与高可用
4.1 分库分表（解决容量与单表瓶颈）
- 数据量大：单表索引、IO、锁竞争都会变差
- 分库分表能把数据按规则拆开
4.2 高可用与扩展
- MySQL：主从、哨兵等（面试强调"读扩展 + 容灾"）
- Redis：集群化提高吞吐与容灾
5. 会话管理：为什么集群不推荐 Session
5.1 Session 的问题
- Session 放在单台机器内存 -> 集群下请求漂移会丢状态
- 粘滞会话会破坏负载均衡效果
5.2 推荐方案：Token + Redis
- Token 放客户端，每次请求携带
- 登录态/黑名单/续期信息放 Redis
一句话：
- 集群下用 Token 解耦状态，Redis 做集中存储，避免 session 粘滞。
常见误区提醒：
- Token 不是"绝对无状态"：你仍然可能需要 Redis 存黑名单、续期信息、踢下线等状态。
6. 高频面试题（速答）
-
Q：系统慢通常先看哪里？
- A：先看 IO/数据库瓶颈，再看缓存命中与下游响应。
-
Q：为什么加 Redis 能提速？
- A：内存访问比磁盘 IO 快很多，缓存命中可直接绕开数据库。
-
Q：为什么要负载均衡？
- A：把单机吞吐扩展为集群吞吐，提高可用性。
-
Q：为什么要分库分表？
- A：解决海量数据下的容量与单表性能瓶颈。
-
Q：集群为什么不用 Session？
- A：状态在单机内存会导致请求漂移丢登录态，推荐 Token + Redis。
-
Q：为什么 Redis 不建议放公网或跨地域当主缓存？
- A：网络 IO 与延迟会显著削弱优势，还会引入稳定性与安全风险；更常见是同机房/同地域部署。
-
Q：系统变慢你先怎么排查？
- A：先看 RT、QPS、错误率，再看 CPU/内存/GC，重点看下游 IO（DB/缓存）与慢查询/超时。
7. 30 秒背诵稿
- 系统优化先定位瓶颈：内存纳秒级、DB IO 毫秒级，所以高并发先关注 DB/IO。
- Redis 缓存用来提速与减压，但要考虑一致性与穿透/击穿/雪崩。
- 架构扩展靠分层与集群：CDN/DNS 分散入口，Nginx 负载均衡扩展后端。
- 数据量大做分库分表，高可用用主从/集群；会话用 Token + Redis 避免 session 粘滞。
8. 总结
- 性能优化先找瓶颈：IO > CPU
- 架构扩展靠分层与集群
- 缓存提速但引入一致性问题
- 会话管理：Token + Redis 更适合集群