分布式 & 高性能 & 高可用 知识体系、学习重点、面试点

文章目录

一、总体系

• 三者之间的关系
• 整体分层视角

二、分布式：解决“扩展性”问题

• 简要说明
• 学习重点 & 面试点

三、高性能：解决“吞吐量/延迟”问题

• 简要说明
• 学习重点 & 面试点

四、高可用：解决“故障容错”问题

• 简要说明
• 学习重点 & 面试点

五、补充

• 消息队列
  • 概览
  • MQ 整体知识体系模块
  • 学习重点
  • MQ 高频面试点
• 学习顺序

最近在学 分布式、高性能、高可用这块内容，知识点比较多，特此简单梳理一下 相关知识体系、学习重点、常见面试点等。

一、总体系

“分布式、高性能、高可用”可以理解成后端架构能力的三根主线，他们不是三个独立模块，而是一套围绕规模与故障设计的系统体系，也是一套系统从“能拆开跑、跑得快、坏了还能跑”三个角度建立起来的能力体系：

分布式解决“单机装不下、扛不住”；高性能解决“处理得够不够快”；高可用解决“出故障还能不能服务”。

三者之间的关系

        分布式(基础能力)
       /              \
  高性能              高可用
(通过并发/缓存/异步    (通过冗余/容错/监控
 提升处理能力)          保证系统稳定)

• 分布式是"骨架"——先把系统拆开、能横向扩容
• 高性能是"肌肉"——在拆开的基础上让每个节点跑得更快
• 高可用是"免疫系统"——保证任何一个节点挂了整体不受影响。

三者互相支撑,不能孤立设计。

它们也存在冲突：

• 副本越多，可用性越高，但数据同步成本越高
• 强一致性越强，通常延迟越高、可用性越受影响
• 重试可以提高成功率，但可能放大流量并造成雪崩
• 缓存提高性能，但会产生缓存一致性问题
• 微服务方便独立扩容，却增加网络调用和运维复杂度

所以体系设计不是“技术堆得越多越好”，而是根据业务指标做取舍。

整体分层视角

一个典型的高性能高可用系统，可以按请求链路自上而下拆解：

客户端
 ↓
DNS / CDN
 ↓
负载均衡(LVS/Nginx)
 ↓
网关层API Gateway
 ├─ 鉴权
 ├─ 限流
 └─ 路由
 ↓
应用服务层
 ↓
无状态服务集群
 ├─ 缓存层：本地缓存 / Redis
 ├─ 消息队列 → 异步消费者
 └─ 数据库集群
      ├─ 主从复制
      ├─ 读写分离
      └─ 分库分表
 ↓
监控、日志、链路追踪、告警

每一层都要同时考虑三个维度：分布式(横向扩展能力)、高性能(单位时间处理量)、高可用(故障时依然可用)。

外围还要配套：

• 容器编排和自动扩缩容
• 配置中心、服务发现
• CI/CD、灰度发布和回滚
• SLI/SLO、容量规划
• 故障演练和灾难恢复

最终衡量它是否成立，不看用了多少中间件，而看能否回答这些问题：

• 峰值能承受多少 QPS？
• P99 延迟是多少？
• 单个实例、数据库或机房故障会怎样？
• 数据最多允许丢失多少，即 RPO？
• 故障后多久恢复，即 RTO？
• 系统过载时优先保住哪些核心功能？

这几个问题有明确答案，才算真正形成了分布式、高性能、高可用体系。

二、分布式：解决“扩展性”问题

分布式的重点是“多个服务、多个节点、多个数据副本之间如何协作”。

简要说明

核心思路:拆分 + 协同

1. 服务拆分
   • 垂直拆分：按业务模块拆(订单、用户、商品各自独立服务)
   • 水平拆分：同一服务多实例部署,通过负载均衡分流
2. 数据拆分
   • 分库分表（水平分片按 ID/哈希,垂直分表按业务字段）
   • 常用中间件：ShardingSphere、MyCAT
3. 分布式协同问题
   • 服务发现与注册：Nacos、Eureka、Zookeeper
   • 分布式事务：TCC、Saga、本地消息表、Seata
   • 分布式锁：Redis/Zookeeper 实现
   • 一致性协议：Paxos、Raft（用于选主、数据同步）
4. 微服务治理
   • RPC 框架:Dubbo、gRPC
   • API 网关:统一鉴权、限流、路由

常见拆分方式：

• 业务拆分：用户、订单、支付、消息等微服务
• 数据拆分：分库分表、读写分离、数据分区
• 计算拆分：任务并行、MapReduce、分布式计算
• 部署拆分：同一服务部署多个实例，由负载均衡分发请求

典型链路：

客户端
  ↓
CDN / DNS
  ↓
负载均衡 / API Gateway
  ↓
多个无状态服务实例
  ↓
缓存 / 消息队列 / 数据库

分布式会带来新的复杂性：

• 网络不可靠、请求超时
• 消息重复或乱序
• 节点状态不一致
• 跨服务事务困难
• 故障定位和链路追踪困难

因此通常还需要超时、重试、幂等、限流、熔断、分布式追踪和最终一致性等机制。

学习重点 & 面试点

需要掌握：

• 分布式理论：CAP、BASE、共识算法、Raft、Gossip、一致性哈希
• 服务拆分：单体拆成用户、订单、支付、消息、库存等服务。
• 服务通信：HTTP、RPC、gRPC、Dubbo、OpenFeign。
• 服务注册发现：Nacos、Eureka、Consul。
• 负载均衡：轮询、权重、最少连接、一致性哈希。
• 分布式事务：2PC、TCC、Saga、本地消息表、事务消息。
• 分布式锁：Redis、ZooKeeper、数据库锁。
• 数据一致性：强一致、最终一致、读写一致。
• 幂等设计：防止重复请求、重复消费、重复扣款。
• 链路追踪：TraceId、日志串联、调用链分析。

面试常问：

• 什么是 CAP？为什么三者不能同时满足？
• 分布式系统为什么需要幂等？
• Paxos、Raft、ZAB 有什么区别，分别用在什么地方？
• RPC和HTTP有什么区别与联系？各自适合什么场景？
• 分布式 ID 如何保证全局唯一、趋势递增和业务可读？
• Redis 分布式锁怎么实现？有什么坑？
• 分布式事务有哪些方案？你怎么选？
• 微服务如何拆分？调用失败怎么办？
• 服务注册发现原理是什么？
• 如何排查一次跨服务调用变慢？

三、高性能：解决“吞吐量/延迟”问题

高性能的核心是“减少等待、减少重复计算、提升并发处理能力”。

简要说明

性能主要看三个指标：

• 吞吐量：每秒处理多少请求，即 QPS/TPS
• 延迟：一次请求耗时多久，重点关注 P95、P99
• 资源效率：完成同等工作消耗多少 CPU、内存、网络和磁盘

常见优化顺序：

1. 减少不必要的工作，例如避免重复查询和重复计算
2. 缓存体系(最关键的一环)

• 本地缓存(Caffeine) + 分布式缓存(Redis) 多级缓存
• 缓存穿透/击穿/雪崩的应对方案（布隆过滤器、互斥锁、随机过期时间）

1. 异步化

• 消息队列削峰填谷：Kafka、RocketMQ、RabbitMQ
• 异步非阻塞 IO：Netty、Reactor 模式

1. 数据库优化

• 读写分离（主从复制）
• 索引优化、SQL 优化
• 连接池管理

1. 计算与存储优化

• 池化技术（线程池、连接池）
• 批量处理、预计算
• 压缩、序列化协议优化（Protobuf 代替 JSON）

1. 增加服务实例并做负载均衡；数据量继续增长后再分库分表

例如：

请求 → Redis 命中 → 直接返回
             ↓ 未命中
          查询数据库
             ↓
          写入缓存

高性能不等于无限加机器。系统可能卡在数据库锁、热点 Key、连接池、下游接口或网络带宽上，必须通过压测和监控找到真正瓶颈。

学习重点 & 面试点

需要掌握：

• 缓存：Redis、本地缓存、多级缓存。
• 数据库优化：索引、执行计划、慢 SQL、分页优化、读写分离。
• 异步化：消息队列、事件驱动、异步任务。
• 批处理：批量写入、批量查询、合并请求。
• 并发模型：线程池、协程、异步 IO、连接池。
• 水平扩展：多实例部署、负载均衡。
• 分库分表：按用户、订单、时间、Hash 分片。
• 限流：令牌桶、漏桶、滑动窗口。
• CDN 和静态资源优化：前端性能常见方向。
• 性能指标：QPS、TPS、RT、P95、P99、吞吐量。

面试常问：

• 优化高性能系统时，应该先定位哪些指标？
• Redis 为什么快？
• 缓存穿透、击穿、雪崩怎么解决？
• MySQL 索引为什么能提升查询性能？
• 慢 SQL 怎么排查？
• 深分页为什么慢？如何优化？
• 接口响应慢怎么优化？
• 线程池参数怎么设置？
• 四层负载均衡、七层负载均衡分别是什么，有什么区别？
• MQ 如何削峰填谷？
• Kafka/RocketMQ/RabbitMQ 如何保证消息不丢失、不重复、不乱序
• 读写分离解决什么问题，主从延迟会造成哪些业务问题？
• 分库分表后分页、排序、事务怎么处理？
• 综合系统设计：如何设计一个高性能订单系统

四、高可用：解决“故障容错”问题

高可用的核心是“故障一定会发生，系统要能扛住”。

简要说明

高可用的核心是：

消除单点故障，并控制故障传播范围。

常见手段包括：

1. 冗余部署

• 多机房、多可用区部署，避免单点故障(SPOF)【即多实例：一个实例挂掉，由其他实例接管】
• 主从/多副本(数据库、缓存都要有副本)【即多副本：数据库主从、Redis Cluster、消息队列副本】
• 灰度发布、快速回滚

1. 容错机制

• 熔断：Sentinel、Hystrix,防止雪崩
• 限流：令牌桶/漏桶算法，控制流量
• 降级：核心链路优先，非核心功能可关闭
• 超时与重试：避免请求堆积

1. 监控与自愈

• 全链路监控：Prometheus + Grafana、SkyWalking
• 日志体系：ELK(Elasticsearch + Logstash + Kibana)
• 自动故障转移(Failover)、健康检查、自动摘除故障节点

1. 容灾

• 数据备份与恢复、容灾切换
• 异地多活架构(最高等级高可用方案)

例如商品推荐服务发生故障时，主链路不应该一起失败：

商品详情请求
 ├─ 商品信息：必须成功
 ├─ 库存信息：必须成功
 └─ 推荐服务：失败时返回空推荐

这就是降级：牺牲非核心功能，保住核心业务。

学习重点 & 面试点

需要掌握：

• 高可用基础：SLA、可用性指标、单点故障、灰度发布
• 多副本部署：服务多实例、数据库主从、Redis 哨兵/集群。
• 健康检查：服务是否存活、是否可处理请求。
• 故障转移：主从切换、节点摘除、自动恢复。
• 超时控制：避免请求无限等待。
• 重试机制：失败重试，但要防止重试放大。
• 幂等：避免重复写入
• 熔断：下游故障时快速失败。
• 降级：非核心功能临时关闭。
• 限流：保护系统不被流量打垮。
• 隔离：线程池隔离、资源隔离、服务隔离。
• 灰度发布：小流量验证。
• 回滚机制：发布异常快速恢复。
• 监控告警：指标、日志、链路追踪。
• 容灾备份：RTO、RPO、同城双活、异地多活、备份恢复。

面试常问：

• 高可用系统如何定义可用性？几个 9 分别意味着什么？
• 什么是服务雪崩？如何解决？
• 熔断和降级有什么区别，分别解决什么问题？
• 限流有哪些算法？
• Redis 宕机怎么办？
• MySQL 主库挂了怎么办？
• 如何设计一个高可用服务？
• 发布失败如何快速回滚？
• 什么是 RTO、RPO？
• 什么是幂等？HTTP 幂等语义和业务幂等有什么区别？
• 幂等键、唯一索引、Redis、乐观锁和状态机各适合什么场景？

五、补充

消息队列

消息队列属于以上哪一类？消息队列整个体系是怎样的，包括哪些模块？学习重点是什么，面试相关是怎样的

概览

核心结论先说：

消息队列不属于单一类别，它横跨三个体系——本质上是高性能的手段（异步处理、削峰填谷、解耦系统、提升吞吐量)，依托分布式架构部署（集群化的中间件），同时又反过来支撑高可用（解耦故障、消息不丢）。这也是 MQ 在面试和实际架构中总被反复提到的原因：它是连接三个体系的枢纽型组件。更准确地说：

所以面试里不要只说“MQ 属于高性能”。更好的回答是：

消息队列本质上是分布式系统里的异步通信中间件，主要用于提升系统性能和吞吐，同时也承担服务解耦、削峰填谷、最终一致性和故障恢复能力。

MQ 是实现"高性能"的手段（异步/削峰），依托"分布式"架构部署（集群），并反过来增强系统的"高可用"能力（解耦、隔离故障）。

MQ 整体知识体系模块

消息队列体系
├── 基础概念层
│   ├── 生产者/消费者/Broker/Topic/Partition
│   ├── 点对点模式 vs 发布订阅模式
│   └── 消息模型(队列模型 vs 发布订阅模型)
│
├── 核心机制层
│   ├── 消息发送:同步/异步/单向发送
│   ├── 消息存储:顺序写磁盘、页缓存、零拷贝(Kafka)
│   ├── 消息消费:拉模式(Pull) vs 推模式(Push)
│   ├── 消费位移(Offset)管理
│   └── 分区与负载均衡(Consumer Group 再均衡)
│
├── 可靠性保障层
│   ├── 消息丢失场景与应对(生产端确认、Broker 持久化、消费端 ACK)
│   ├── 消息重复消费与幂等性设计
│   ├── 消息顺序性保证(单分区顺序、全局顺序代价)
│   └── 事务消息(半消息机制,RocketMQ 事务消息)
│
├── 高可用与集群层
│   ├── 副本机制(Leader/Follower,ISR 机制 - Kafka)
│   ├── 主从切换与选举
│   ├── 消息堆积处理
│   └── 死信队列(DLQ)、延迟队列
│
├── 性能优化层
│   ├── 批量发送、压缩
│   ├── 顺序 IO、PageCache、零拷贝
│   └── 分区数设计与吞吐量关系
│
└── 主流产品对比
    ├── Kafka(高吞吐、大数据场景)
    ├── RocketMQ(金融级、事务消息强)
    ├── RabbitMQ(轻量、路由灵活、AMQP 协议)
    └── Pulsar(存算分离新一代架构)

消息队列整体可以分成这些模块：

常见产品：

• Kafka：高吞吐、日志流模型，适合大数据、日志、事件流。
• RabbitMQ：传统队列模型强，路由灵活，适合业务系统。
• RocketMQ：事务消息、顺序消息支持好，电商金融场景常见。
• ActiveMQ：老牌 MQ，现在新项目较少用。

学习重点

1. 先理解模型,再学 API：搞懂 Topic/Partition/Consumer Group 的关系，再去看具体客户端怎么用。
2. 可靠性三个环节要拆开学：

• 生产端不丢(ack=all / 事务消息)
• Broker 不丢(持久化 + 多副本)
• 消费端不丢(手动 ACK + 幂等处理，而不是自动 ACK)

1. 顺序性是有代价的：只有单分区内保证顺序，全局顺序会牺牲并发度，要理解这个 trade-off。
2. Kafka 的高性能原理要吃透（面试高频）：顺序写、PageCache、零拷贝(sendfile)、批量发送 + 压缩。
3. 动手实践：至少本地跑一遍 Kafka/RocketMQ，手写一个生产者-消费者 Demo，体会 offset 提交时机对消息丢失/重复的影响。

MQ 核心问题

学习 MQ 时，重点不是只会用 API，而是要理解这些问题：

1）为什么用 MQ？

核心场景：

• 异步：下单后发短信、发邮件、同步积分，不必阻塞主流程。
• 解耦：订单服务不直接调用库存、积分、通知服务。
• 削峰：秒杀流量先进 MQ，消费者按能力慢慢处理。
• 最终一致性：本地操作成功后，通过消息驱动其他系统补齐状态。

2）MQ 会带来什么问题？

引入 MQ 后，系统复杂度会上升：

• 消息可能丢失。
• 消息可能重复。
• 消息可能乱序。
• 消费可能失败。
• 消息可能积压。
• 生产者、Broker、消费者都可能宕机。
• 数据不再是强一致，而是最终一致。

3）如何保证消息不丢？

从三段看：

• 生产者到 Broker：发送确认、失败重试、事务消息。
• Broker 内部：消息持久化、副本同步。
• Broker 到消费者：手动 ACK，处理成功后再确认。

4）如何处理重复消费？

靠幂等，不要指望 MQ 永远只投递一次。

常见方案：

• 业务唯一键去重。
• 数据库唯一索引。
• Redis setnx 去重。
• 消费记录表。
• 状态机判断，例如订单已支付就不要重复扣款。

5）如何保证顺序消费？

常见方案：

• 同一业务 key 发到同一个队列或分区。
• 单队列单消费者消费。
• 消费端按业务 key 串行处理。

代价是吞吐量会下降，所以顺序消息只应该用于真正需要有序的场景。

6）消息积压怎么办？

排查方向：

• 消费者是否异常。
• 消费速度是否太慢。
• 是否下游数据库、接口变慢。
• 是否消息量突然暴涨。
• 是否消费者实例太少。
• 是否单条消息处理太重。

解决方式：

• 扩容消费者。
• 批量消费。
• 优化消费逻辑。
• 临时跳过非核心逻辑。
• 拆分 Topic 或队列。
• 对异常消息进入死信队列。

MQ 高频面试点

基础类

• MQ 的作用（解耦、异步、削峰）分别举例说明
• MQ 如何实现异步、应用解耦和削峰填谷
• Kafka/RocketMQ/RabbitMQ 的区别和选型依据
• 什么是消费者组？什么是 offset？ACK 机制是什么
• 你们为什么使用MQ

可靠性类(重灾区)

• 如何保证消息不丢失？（生产端、Broker、消费端三层分别怎么做）
• 如何保证消息不被重复消费？（幂等性设计：唯一键 + 状态判断 / 数据库唯一约束 / Redis setnx）
• 如何保证消息的顺序性？为什么全局顺序很难做？
• MQ 消息积压怎么排查？怎样区分生产流量突增、消费者变慢、分区不足和下游故障？

高可用/集群类

• Kafka 的 ISR 机制是什么？Leader 挂了之后如何选举？
• 消息积压了怎么办？（临时扩容消费者、批量消费、跳过非核心消息等应急方案）
• MQ 宕机怎么办？
• 死信队列的作用和使用场景

深入原理类(中高级面试)

• Kafka 为什么这么快？（顺序写磁盘 + 零拷贝 + PageCache + 批量压缩）
• Kafka 的 rebalance 机制及其可能引发的问题（消费暂停）
• RocketMQ 的事务消息（半消息）实现原理

场景设计类

• 秒杀系统中 MQ 怎么用来削峰?
• 订单超时未支付自动取消,如何用 MQ 的延迟队列实现?
• 如何设计一个可靠的消息系统？

一个比较完整的面试回答模板是：

我们使用 MQ 主要是为了解耦、异步和削峰。生产者发送消息后由 Broker 持久化，消费者异步消费。为了保证可靠性，生产端需要发送确认和失败重试，Broker 需要持久化和副本机制，消费端使用手动 ACK。由于 MQ 通常只能保证至少一次投递，所以业务侧必须做幂等。对于顺序消息，会按业务 key 路由到同一个队列或分区。对于消费失败，会通过重试和死信队列兜底。监控上重点看消息积压、消费延迟、失败率和 Broker 可用性。

学习顺序

学习顺序建议是：

1. 先学分布式基础：服务拆分、RPC、注册发现、CAP、幂等。
2. 再学高性能：缓存、数据库优化、异步化、限流、线程池。
3. 然后学 MQ：异步、削峰、可靠投递、重复消费、顺序消息。
4. 最后学高可用：熔断、降级、容灾、监控、故障恢复。

MQ 是连接这三块知识的典型中间件，面试价值很高。重点不是背概念，而是能围绕“为什么用、解决什么问题、引入什么风险、怎么兜底”讲清楚。

• 如果目标是校招/初级面试：重点吃透”基础概念层 + 可靠性保障层“，能讲清楚不丢不重不乱即可。
• 如果目标是中高级/架构面试：需要补齐”高可用与集群层 + 性能优化层“的原理，最好能画出 Kafka 副本同步、ISR 机制的图。
• 建议按上面"总览表"和"MQ 体系图"做成自己的知识卡片，面试前对着标题自测能否讲清楚每一项。

参考：JavaGuide消息队列面试题