这份 高性能系统知识体系 面向后端学习、系统设计和面试复习，围绕“减少延迟、提升吞吐、削峰填谷、降低数据库压力、优化数据访问路径”整理本站高性能相关文章。

什么是 CDN ？

CDN 全称是 Content Delivery Network/Content Distribution Network，翻译过的意思是 内容分发网络 。

我们可以将内容分发网络拆开来看：

• 内容：指的是静态资源，包括图片、视频、文档、JS、CSS、HTML 等。
• 分发网络：指的是将这些静态资源分发到位于多个不同地理位置机房中的服务器上，从而实现就近访问——例如北京的用户直接访问北京机房的数据。

什么是数据冷热分离？

数据冷热分离是指根据数据的访问频率和业务重要性，将数据划分为冷数据和热数据，并分别存储在不同性能和成本的存储介质中的架构策略。

这种架构的核心目标有三个：

1. 提升查询性能：热数据存储在高性能介质（如 SSD、内存）中，保障核心业务的响应速度。
2. 降低存储成本：冷数据迁移至低成本介质（如 HDD、对象存储），大幅削减存储开支。
3. 满足合规要求：部分行业（如金融、医疗）要求数据长期归档，冷热分离可兼顾合规与成本。

什么是深度分页？怎么导致的？

查询偏移量过大的场景我们称为深度分页，这会导致查询性能较低，例如：

# MySQL 在无法利用索引的情况下跳过1000000条记录后，再获取10条记录
SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10

高性能系统面试不是问你会不会背几个优化手段，而是看你能不能把请求链路拆开：用户请求进来后，哪里可能慢，哪里可能扛不住，哪里需要削峰，哪里需要减少数据库压力，哪里需要用监控和压测验证效果。

这篇文章把 JavaGuide 现有高性能相关文章串成一条面试复习路线，适合准备后端开发、系统设计和架构设计相关面试。

高性能系统设计面试怎么准备？

高性能问题通常可以按请求链路拆成 4 层：

1. 入口层：CDN、负载均衡、网关。
2. 应用层：限流、异步化、线程池、批处理。
3. 数据层：索引、SQL 优化、读写分离、分库分表、冷热分离。
4. 削峰层：消息队列、延迟处理、重试和补偿。

这部分内容摘自 JavaGuide 高性能专题的重点文章，适合在系统复习之后用来查漏补缺。

高性能面试题通常不会只考一个概念。面试官更关心你能不能把问题放回真实链路里：请求从入口进来，经过负载均衡、应用服务、缓存、数据库、消息队列之后，哪个环节慢了，哪个环节扛不住，哪个方案能解决，方案又会带来什么新问题。

建议按“是什么 -> 解决什么问题 -> 核心原理 -> 适用边界 -> 生产落地”这 5 个角度准备答案。这样既能回答基础概念，也能应对继续追问。

什么是负载均衡？

负载均衡 指的是将用户请求分摊到不同的服务器上处理，以提高系统整体的并发处理能力以及可靠性。负载均衡服务可以有由专门的软件或者硬件来完成，一般情况下，硬件的性能更好，软件的价格更便宜（后文会详细介绍到）。

下图是《Java 面试指北》 「高并发篇」中的一篇文章的配图，从图中可以看出，系统的商品服务部署了多份在不同的服务器上，为了实现访问商品服务请求的分流，我们用到了负载均衡。

读写分离

什么是读写分离？

读写分离主要是为了将数据库的读操作和写操作分散到不同的数据库节点上。 写请求仍然进入主库，读请求分摊到一个或多个只读副本，因此它主要提升的是数据库读扩展能力。只有当主库原本被大量读请求拖慢时，读流量迁出后，写入链路才可能间接受益。

我简单画了一张图来帮助不太清楚读写分离的小伙伴理解。

SQL 慢了，不要一上来就套“加索引”“不要 SELECT *”这类规则。先把慢 SQL 找出来，看它慢在扫描行数、排序、回表、锁等待，还是调用频次太高。执行计划和业务访问方式对上之后，再决定是改索引、改 SQL、改表结构，还是把查询挪到缓存、搜索引擎或离线报表里。

排查时可以按这个顺序来：

1. 先确认慢的是平均耗时、P99，还是偶发超时；是某条 SQL 慢，还是数据库整体负载高。
2. 通过慢查询日志、APM、数据库监控定位高频慢 SQL。
3. 看执行计划里的 type、key、rows、filtered、Extra，确认有没有全表扫描、回表过多、临时表或文件排序。
4. 再结合业务访问方式处理：少查字段、补索引、改 SQL、拆大事务、限制分页深度。
5. 最后用相同数据量和相同条件复测，别只在小数据集上验证。

消息队列是高性能和高可用系统里都非常常见的中间件，主要用于异步处理、应用解耦、削峰填谷和流量缓冲。学习消息队列时，不能只背 Kafka、RocketMQ、RabbitMQ 的特性，更要理解消息可靠性、顺序性、幂等性、积压处理和技术选型。

如果你准备面试，可以把 MQ 问题拆成一条链路：生产者怎么保证发出去，Broker 怎么保证存得住，消费者怎么保证处理成功，失败后怎么重试和补偿。这样比单独背“消息不丢失、重复消费、顺序消费”更容易讲清楚。

适合谁看

• 想系统学习消息队列的后端开发者。
• 准备 Kafka、RocketMQ、RabbitMQ、消息可靠性相关面试题的同学。
• 已经在项目中使用 MQ，但对消息丢失、重复消费、顺序消费、消息积压处理不够熟的读者。
• 需要在 Kafka、RocketMQ、RabbitMQ、Disruptor 之间做技术选型的工程师。