大型系统的核心不是“堆技术名词”，而是：

• 识别瓶颈
• 用架构手段把瓶颈拆开、绕开、扩展掉

这篇按“性能瓶颈 -> 分层架构 -> 数据与缓存 -> 会话管理”的主线整理。

面试与工程都通用的一句话方法论：

• 先观测（指标/日志/链路追踪）定位瓶颈，再做架构优化；不要一上来就“加 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 更适合集群