审核解析结果

返回队列

任务 ID: job_e9402415170742de9fd22ee8b0b84215
任务类型: 提取面经
状态: 已确认
尝试次数: 1

来源上下文

知识笔记来源已确认任务已确认

Java八股（分布式）.md

src_f57693654e8a4aabbf27b8f72ee86e85

创建于 2026/03/29 15:34，最近更新时间 2026/04/07 12:16

公司岗位轮次标签

摘要原文

## 分布式基础
### <font style="color:rgb(44, 62, 80);">CAP 理论</font>
C：一致性，是指所有节点访问的都是同一份最新的数据

A：可用性，指的是集群部分节点发生故障后，集群仍然可以正常响应

P：分区容错性，指的是分布式系统出现网络分区时候，仍然能够提供服务

CAP理论呢在一个系统当中他只能保证其中的两个，通常来说我们会选择CP或则AP作为系统的架构，因为使用CA的时候，如果你的网络分区出现了故障，这样为了保证一致性，我们就会禁止其他节点的读写操作，这就和A发生了冲突。

CP一般来说适用于要求强一致性的场景，像比如银行业务，而AP更适合需要保证高可用性的场景，也是现在大部分场景的一个选择。

### BASE理论
base就是基本可用、软状态和最终一致性的缩写。

base理论它的基本思想就是希望牺牲一部分的系统数据的一致性来保证系统的可用性，他希望各个应用根据自身特点选择合适的方式来达到一个最终一致性。它相当于是ap理论的一个延申，就是我们再分区错误修复了之后，系统应该能够达到一个一致性的状态。

这里面的三个基本概念，基本可用指的就是我们允许系统损失一部分的可用性，比如时间上的延迟，或者部分非核心功能的无法使用。软状态指的就是数据在系统当中存在的一个中间状态，就是我们允许数据在结点之间同步传输存在时延，他认为这种时延是不会影响系统的整体可用性的。至于最终一致性就是指系统在经过一段时间的同步后，需要达到一个一致的状态，而不要求实时的这种强一致性。

### 最终一致性实现方式
读时修复：读取数据时，如果发现不同节点之间的副本不一致，则进行修复

写时修复：写入数据时，如果节点之间写入失败，则将失败数据进行缓存，定时重传

异步修复：定时对账，检测副本数据的一致性，并修复

### 什么是网关
网关是外部请求进入我们的系统之前的一道关卡，它主要做两件事，请求转发和请求过滤，在这两件事的基础上，我们可以实现请求转发、鉴权、负载均衡、日志记录等待功能。常用的网关比如netflix 的zuul网关和spring cloud 的gateway。

### 为什么选择Gateway?
网关的选择一般集中再zuul和gateway之间，gateway相比zuul来说，它使用异步非阻塞模型，性能比起使用阻塞式模型的zuul1.x来说更好，而且spring cloud集成了gateway，使用起来更加便捷。

### 介绍一下gateway
gateway是springcloud推出的一个网关，它能够实现请求转发、负载均衡、过滤等多种操作。它主要三个核心概念，就是路由、断言和过滤。断言指的就是当请求路径匹配该断言时，就会被转发到路由地址，而过滤则是在请求转发前或转发后对它进行一个处理。在项目当中我们主要使用gateway来进行负载均衡、转发和请求过滤。（前端发来的请求一般会带上api，这里利用gateway的路径重写进行一个过滤）

### 网关和nginx有什么区别？
+ <font style="color:rgb(18, 18, 18);">实际在使用中两者是都可以实现对api接口的拦截，负载均衡、反向代理、请求过滤等功能。</font>
+ <font style="color:rgb(18, 18, 18);">不同点：编写的语言是不一样的，Nginx采用C语言编写，而Gateway采用Java编写的，能够更好对微服务实现拓展功能，而Nginx想要实现拓展功能需要结合Lua语言等。</font>
+ <font style="color:rgb(18, 18, 18);">还有一点是Nginx实现负载均衡原理是属于服务器端负载均衡器，而Gateway则是采用本地负载均衡的形式。</font>

### 什么是负载均衡？
负载均衡主要就是让用户请求平均的分配到各个服务器上，从而使得系统达到一个高可用的效果，而不至于许多请求都打到同一个服务器上，使得该服务器压力大而其他服务器却没什么压力。

负载均衡主要分为客户端的负载均衡和服务端的负载均衡。 像Ribbon就是客户端的负载均衡，它会在注册中心上获取注册信息服务列表后缓存到本地，然后再发送时从这些地址中选择一个进行发送。然后服务端的比如Nginx，就是用户请求先会来到Nginx，它根据指定的策略将请求转发到不同的服务器上。

（Spring cloud gateway是客户端负载均衡）

### 有哪些负载均衡算法？
轮询、随机、响应时间加权

以下内容来自chatgpt：

1.  **轮询（Round Robin）**：
    - 每个请求按顺序分配到每个服务器。
    - 如果所有服务器的性能都相同，此方法效果很好，但如果一个服务器的性能比其他服务器更强，这可能不是最佳选择。
2.  **加权轮询（Weighted Round Robin）**：
    - 与轮询类似，但每个服务器都有一个权重，根据其性能或其他标准来指定。
    - 权重较高的服务器会得到更多的请求。
3.  **最少连接（Least Connections）**：
    - 服务器上的连接数最少的将获得新的请求。
    - 这考虑了服务器的实时负载。
4.  **加权最少连接（Weighted Least Connections）**：
    - 类似于最少连接，但考虑到每个服务器的权重。
    - 一个高性能的服务器可能会有更高的权重，因此即使其上的连接数多于其他服务器，它仍可能接收新的请求。
5.  **IP哈希（IP Hash）**：
    - 请求的IP地址决定分配给哪个服务器。
    - 这确保特定的用户（IP地址）始终连接到同一个服务器。
6.  **最短响应时间（Least Response Time）**：
    - 将新请求发送到响应时间最短的服务器。
7.  **源地址散列（Source IP Hash）**：
    - 基于来源IP地址进行哈希操作，然后选择一个服务器。这确保特定IP地址的客户端总是被发送到同一台服务器。
8.  **URL散列**：
    - 基于请求URL进行哈希运算来决定将请求发送到哪台服务器，这样确保特定的URL或资源始终由同一台服务器处理。
9.  **Sticky Session（粘性会话）**：
    - 一旦客户端的请求被分配到某个服务器，该客户端的所有后续请求都将被路由到同一服务器。
10.  **自定义负载均衡**：
    - 在某些复杂的场景下，可能需要自定义算法来满足特定的业务需求。

当选择一个负载均衡策略时，应该考虑到后端服务器的特性、应用的需求以及预期的用户行为。有时，组合使用多种策略可能是最佳选择。

### 介绍一下注册中心、配置中心
注册中心主要就是让各个微服务模块注册到注册中心服务器上，并且维持心跳连接，这样做可以实时监控各个微服务模块的性能情况，而且各个模块可以把自己的通讯信息写到注册中心当中，这样消费者可以通过注册中心获得模块信息来执行远程调用。

注册中心主要有eureka、zookeeper、consul和nacos。eureka、nacos实现的是AP模式，而zookeeper和consul实现的都是CP模式。在项目当中我们选择的是nacos来作为注册中心，主要考虑到我们项目更应该去保证系统的可用性而不是数据的强一致性。而且nacos集成了注册中心和配置中心，更加方便。

配置中心主要用于为各个微服务模块提供一个中心化的外部配置，能够实现统一配置管理，配置的动态更新以及分环境部署。项目中使用nacos来作为配置中心。

### 分布式ID
分布式ID主要是考虑在分布式的场景下，如何为不同的节点数据分配一个全局唯一的ID。

常用的分布式ID算法包括数据库号段模式、UUID、雪花算法

号段模式：号段模式主要就是从数据库中批量获得一组ID，存储在内存当中，然后需要用的适合直接进行分配，分配完了再去批量获取一组。像比如滴滴的tinyid。号段模式的优点是id有序递增，且占用空间较小；缺点是依赖于数据库，存在单点问题，且id递增是有规律的，有安全问题。

此外，也可以使用redis来获得自增主键。

UUID：jdk就提供了生成UUID的算法，uuid使用起来更加轻便，但是缺点是它不是递增的，而且消耗空间大，可能产生重复id

雪花算法：主要使用雪花算法来生产分布式id，它可以根据时间、机器id来生产一个有序的id，生成速度快，且id有序，它的缺点是在机器时间不对的情况下可能产生重复id

## 服务限流
### 常见的限流算法
1. 固定窗口限流：思路是固定单位时间内处理的请求数量，超过该数量的请求直接丢弃。但是这种方法不能应对突然激增的流量，比如我们固定1s处理10个请求，在第一秒的前0.5秒没有请求，后0.5秒进来了十个请求，第二秒的前0.5秒又进来了十个请求，相当于在中间这一秒处理了二十个请求，这可能就导致服务器被瞬时的大量请求击垮。
2. 滑动窗口限流：相当于固定窗口的升级版，它对时间进行分片，窗口根据分片后的时间单位进行移动，保证窗口内的请求数量是符合要求的，如果超出要求则直接丢弃。例如1s处理十个请求，以0.1s进行划分，则会统计1s这个时间窗口内的流量，每经过0.1s，窗口向右滑动一格，这样就能保证应对激增流量，比如0.9s来了10个请求，如果是固定窗口，第二秒内仍然能够进来请求，而在滑动窗口下，包含了0.9s的窗口内都不能进来请求。
3. 漏桶算法：漏桶算法将请求处理的过程比喻成漏桶漏水，也就是我们以任意的速率向漏桶当中加水，漏桶会以一个固定的速率进行漏水，放到请求处理上来说就是以任意速率接收请求，漏桶在以固定速率释放请求，从而限制了请求的流量。我们可以使用一个队列来作为漏桶，请求先缓存在队列当中，然后服务器按照指定的速率去队列中拿取请求进行处理，当队列满的时候则直接拒绝新的请求。对于滑动窗口来说，一旦请求超出阈值则直接拒绝，而漏桶算法则相对没那么粗暴，他用队列缓存请求，只有当请求堆积，队列满的时候才会拒绝请求。
4. 令牌桶算法：令牌桶算法则是按照一定的速率生成令牌，放入桶中，当请求进来时，需要先获得一个令牌，获得令牌的请求就能够被处理。更适合于流量突增的场景，因为对于漏桶算法，即使流量突增，仍然是以固定的速率处理请求，而对于令牌桶，如果流量突增，则可以拿完存的所有令牌，快速处理。

## 分布式锁
### zookeeper如何实现分布式锁？
[图解Redis和Zookeeper分布式锁 | 京东云技术团队 - 掘金](https://juejin.cn/post/7239058077273620536#heading-10)

1：首先在Zookeeper上创建临时顺序节点Node01、Node02等

2：第二步客户端拿到加锁路径下所有创建的节点

3：判断自己的序号是否最小，如果最小的话，代表加锁成功，如果不是最小的话，就对前一个节点创建监听器

4：如果前一个节点删除，监听器就会通知客户端来准备重新获取锁

<!-- 这是一张图片，ocr 内容为： -->
![](https://cdn.nlark.com/yuque/0/2023/webp/34998771/1693731972403-9cf17648-64db-442d-b932-d64b6f5a4548.webp)

**<font style="color:rgb(37, 41, 51);">解锁的步骤如下：</font>**

<font style="color:rgb(37, 41, 51);">（1）判断锁是不是自己的</font>

<font style="color:rgb(37, 41, 51);">（2）如果是则减少加锁次数</font>

<font style="color:rgb(37, 41, 51);">（3）如果加锁次数等于0，则释放锁，删除掉创建的临时节点，下一个监听这个节点的客户端会感知到节点删除事件，从而重新去获取锁</font>

<!-- 这是一张图片，ocr 内容为： -->
![](https://cdn.nlark.com/yuque/0/2023/webp/34998771/1693732058431-461c8b83-c0c4-4b91-8080-d304d374ca2e.webp)

### 为什么zookeeper使用临时顺序节点？
<font style="color:rgb(37, 41, 51);">1：使用临时节点可以在</font>**<font style="color:rgb(37, 41, 51);">客户端程序崩溃时自动释放锁，避免死锁问题</font>**

<font style="color:rgb(37, 41, 51);">2：使用顺序节点的好处是，可以利用锁释放的事件监听机制，来实现</font>_**<font style="color:rgb(37, 41, 51);">阻塞监听式的分布式锁</font>**_

_**<font style="color:rgb(37, 41, 51);"></font>**_

### <font style="color:rgb(37, 41, 51);">zookeeper和redis分布式锁的区别？</font>
|  | Redis | Zookeeper |
| :---: | --- | --- |
| <font style="color:rgb(37, 41, 51);">读性能</font> | <font style="color:rgb(37, 41, 51);">基于内存</font> | <font style="color:rgb(37, 41, 51);">基于内存</font> |
| 加锁性能 | <font style="color:rgb(37, 41, 51);background-color:rgb(252, 252, 252);">直接写内存加锁</font> | <font style="color:rgb(37, 41, 51);background-color:rgb(252, 252, 252);">Master节点创建好后与其他Follower节点进行同步,半数成功后才能返回写入成功</font> |
| <font style="color:rgb(37, 41, 51);">数据一致性</font> | <font style="color:rgb(37, 41, 51);">AP架构Redis集群之间的数据同步是存在一定的延迟的，当主节点宕机后，数据如果还没有同步到从节点上，就会导致分布式锁失效，会造成数据的不一致（redlock解决？）</font> | <font style="color:rgb(37, 41, 51);">CP架构当Leader节点宕机后，会进行集群重新选举，如果此时只有一部分节点收到了数据的话，会在集群内进行数据同步，保证集群数据的一致性</font> |

<font style="color:rgb(37, 41, 51);">（1）如果业务并发量很大，Redis分布式锁高效的读写性能更能支持高并发</font>

<font style="color:rgb(37, 41, 51);">（2）如果业务要求锁的强一致性，那么使用Zookeeper可能是更好的选择</font>

### <font style="color:rgb(37, 41, 51);">Zookeeper如何实现可重入锁？</font>
Zookeeper实现可重入分布式锁的机制是_**在本地维护一个Map记录**_，因为如果在Zookeeper节点维护数据的话，***Zookeeper的写操作是很慢，集群内部需要进行投票同步数据，** *所以在本地维护一个Map记录来记录当前加锁的次数和加锁状态，在释放锁的时候减少加锁的次数，原理如下图所示：

<!-- 这是一张图片，ocr 内容为： -->
![](https://cdn.nlark.com/yuque/0/2023/webp/34998771/1693732108520-09ad8899-01a4-4561-8b42-9ecba5929278.webp)

候选题（17）

候选 1新建

什么是CAP理论？为什么通常选择CP或AP？

置信度 0.99

题目答案

分类标签

处理方式目标题目 ID

填写已有 canonical 题目 ID。当前正式题库 ID 也使用 q_ 前缀，不是临时占位。

候选 2新建

什么是BASE理论？

置信度 0.98

分类: 分布式系统标签: 1

候选 3新建

最终一致性有哪些实现方式？

置信度 0.95

分类: 分布式系统标签: 1

候选 4新建

什么是网关？

置信度 0.95

分类: 网络协议标签: 2

候选 5新建

为什么选择Gateway而不是Zuul？

置信度 0.93

分类: 网络协议标签: 2

候选 6新建

介绍一下Gateway。

置信度 0.96

分类: 网络协议标签: 2

候选 7新建

网关和Nginx有什么区别？

置信度 0.92

分类: 网络协议标签: 2

候选 8新建

什么是负载均衡？客户端负载均衡和服务端负载均衡有什么区别？

置信度 0.97

分类: 网络协议标签: 2

候选 9新建

常见的负载均衡算法有哪些？

置信度 0.82

分类: 网络协议标签: 2

候选 10新建

介绍一下注册中心和配置中心。

置信度 0.96

分类: 分布式系统标签: 1

候选 11新建

为什么注册中心选择Nacos？

置信度 0.94

分类: 分布式系统标签: 1

候选 12新建

常见的分布式ID方案有哪些？

置信度 0.97

分类: 分布式系统标签: 3

候选 13新建

常见的限流算法有哪些？

置信度 0.97

分类: 分布式系统标签: 1

候选 14新建

Zookeeper如何实现分布式锁？

置信度 0.98

分类: 分布式系统标签: 2

候选 15新建

为什么Zookeeper分布式锁使用临时顺序节点？

置信度 0.98

分类: 分布式系统标签: 2

候选 16新建

Zookeeper和Redis分布式锁有什么区别？

置信度 0.97

分类: 分布式系统标签: 4

候选 17新建

Zookeeper如何实现可重入锁？

置信度 0.95

分类: 分布式系统标签: 3

导入预览

新建预览

什么是CAP理论？为什么通常选择CP或AP？

分类: 分布式系统

标签: 系统设计, 网络

答案预览

C：一致性，是指所有节点访问的都是同一份最新的数据 A：可用性，指的是集群部分节点发生故障后，集群仍然可以正常响应 P：分区容错性，指的是分布式系统出现网络分区时候，仍然能够提供服务 CAP理论呢在一个系统当中他只能保证其中的两个，通常来说我们会选择CP或则AP作为系统的架构，因为使用CA的时候，如果你的网络分区出现了故障，这样为了保证一致性，我们就会禁止其他节点的读写操作，这就和A发生了冲突。 CP一般来说适用于要求强一致性的场景，像比如银行业务，而AP更适合需要保证高可用性的场景，也是现在大部分场景的一个选择。

批量摘要

新建

合并

跳过

解析提示

来源是知识笔记而非真实面经，缺少公司、岗位、轮次等面试元数据。
“有哪些负载均衡算法”部分包含“以下内容来自chatgpt”，该段权威性相对较弱，已适当降低置信度。
分布式ID中关于UUID“可能产生重复id”的表述存在争议，已尽量做保守归纳。
Redis分布式锁处提到“redlock解决？”带有不确定语气，未将其纳入标准答案。

这个任务已经确认过了，不会再次写入 canonical。

返回队列

创建时间: 2026/03/29 15:34

开始时间: 2026/03/29 15:34

完成时间: 2026/03/29 15:40