程序员面试手册
程序员面试手册

Appearance

Star

CDN 与负载均衡 ​

概念 ​

CDN（Content Delivery Network）和负载均衡是优化网络架构的两大核心技术。CDN 让用户就近获取内容，负载均衡将请求分发到多个后端服务器。两者经常配合使用。

CDN 原理 ​

什么是 CDN ​

CDN 是一组分布在各地的缓存服务器（边缘节点），将网站内容缓存到离用户最近的节点，减少延迟和源站压力。

CDN 访问流程 ​

用户请求 www.example.com/image.png
        ↓
1. DNS 解析：www.example.com CNAME → cdn.example.com
        ↓
2. CDN 智能 DNS：根据用户 IP 返回最近的边缘节点 IP
        ↓
3. 用户访问边缘节点
        ↓
4. 边缘节点有缓存？
   ├── 有（缓存命中）→ 直接返回内容
   └── 没有（缓存未命中）→ 回源请求 → 从源站获取 → 缓存到节点 → 返回给用户

回源 ​

当边缘节点没有缓存或缓存过期时，需要从源站获取最新内容：

场景说明
首次访问边缘节点还没有该资源的缓存
缓存过期TTL 到期，需要重新验证或获取
缓存被淘汰节点存储空间不足，LRU 淘汰旧缓存
主动刷新手动清除 CDN 缓存（发布新版本时）

回源率是衡量 CDN 效果的关键指标 — 越低越好。

CDN 缓存策略 ​

内容类型缓存策略TTL
静态资源（JS/CSS/图片）✅ 长期缓存天到月（配合文件名哈希）
HTML 页面短缓存或不缓存秒到分钟
API 响应一般不缓存不缓存或极短

最佳实践： 静态资源文件名加哈希（app.a1b2c3.js），设长 TTL。更新时文件名变了，自然获取新版本。

CDN 适用场景 ​

场景原因
静态资源加速图片、视频、CSS/JS 就近获取
全站加速动态请求也通过 CDN 优化路由
安全防护DDoS 防御、WAF
直播/点播视频流分发

负载均衡 ​

三层负载均衡 ​

层级实现工作层性能
DNS 负载均衡DNS 返回不同 IP应用层高（无额外设备）
四层负载均衡LVS / F5传输层（TCP/UDP）✅ 极高
七层负载均衡Nginx / HAProxy应用层（HTTP）中高

实际架构常用组合： DNS 负载均衡 → LVS（四层）→ Nginx（七层）→ 后端服务器

DNS 负载均衡 ​

同一域名配置多个 A 记录，DNS 轮询返回不同 IP：

example.com  A  192.168.1.1
example.com  A  192.168.1.2
example.com  A  192.168.1.3

优点： 简单，无需额外设备 缺点： DNS 缓存导致不够实时，无法感知服务器健康状态

四层负载均衡（LVS） ​

基于 IP 和端口转发，不解析 HTTP 内容，性能极高：

模式原理性能
NAT修改目标 IP（请求和响应都经过 LVS）一般
DR（Direct Routing）修改 MAC 地址（响应直接返回客户端）✅ 最高
TUN（IP Tunneling）IP 隧道封装高

DR 模式最常用 — 请求经过 LVS，响应直接从后端返回客户端，LVS 不成为瓶颈。

七层负载均衡（Nginx） ​

解析 HTTP 内容，可以根据 URL、Header 等做更精细的路由：

nginx
upstream backend {
    server 192.168.1.1:8080 weight=3;   # 权重 3
    server 192.168.1.2:8080 weight=1;   # 权重 1
    server 192.168.1.3:8080 backup;     # 备用节点
}

server {
    location /api/ {
        proxy_pass http://backend;
    }
    
    location /static/ {
        root /var/www/html;   # 静态资源直接返回
    }
}

七层的优势： 可以根据 URL 路由到不同后端、可以做 SSL 终端、可以修改 Header、可以做缓存。

负载均衡算法 ​

算法说明适用场景
轮询（Round Robin）依次分配服务器性能相同
加权轮询（Weighted RR）按权重分配服务器性能不同
最少连接（Least Connections）分配给连接数最少的请求处理时间差异大
加权最少连接结合权重和连接数综合考虑
IP 哈希根据客户端 IP 哈希选择需要会话保持
一致性哈希环形哈希空间缓存场景（加减节点influence小）
随机随机选择简单场景

算法深度对比与生产选型 ​

2025-2026 年面试要能讲出每种算法的：①底层数据结构、②时间复杂度、③真实生产坑、④适合 vs 不适合什么场景。下面是完整深度对比：

算法数据结构选节点复杂度关键坑用在哪
轮询自增计数器 % NO(1)节点新增/下线时计数器抖动 → 短暂分配不均Nginx 默认
加权轮询（WRR）平滑算法（Nginx 实现）O(N)朴素 WRR 会"先把权重高的连续打满" → Nginx 用平滑加权避免Nginx weight=N
最少连接（LC）最小堆 / 排序数组O(log N)统计有误差（计数滞后） → 高 QPS 下可能误判LVS / HAProxy
加权最少连接LC + 权重归一化O(log N)同上 + 权重失衡放大效应LVS wlc
IP Hashhash(IP) % NO(1)节点变化时大量会话漂移 → 退化版"伪一致性哈希"Nginx ip_hash
一致性哈希哈希环 + 虚拟节点O(log N) 二分虚拟节点少时分布不均（每物理节点 < 100 个虚拟节点会严重倾斜）Redis Cluster / 缓存代理
EWMA / 响应时间滑动窗口估计 P99 延迟O(N) 或 O(log N)冷启动慢、突变响应慢Envoy / Spring Cloud LB
P2C（Power of Two Choices）随机选 2 个比较O(1)无gRPC 默认 / Envoy / Finagle

P2C：现代负载均衡的"默认推荐" ​

Power of Two Choices（Mitzenmacher 2001）是近十年 LB 算法的最大突破：

传统最少连接（LC）: 维护全局最小堆 → 高并发下竞争锁
朴素随机:           可能选到最忙的
P2C 算法:
  1. 随机抽 2 个节点
  2. 比较两者的"负载"（连接数 / 延迟 / 队列长度）
  3. 把请求发给较空的那个

💡 为什么 P2C 这么神

数学上，纯随机的最大负载是 Θ(log n / log log n)；仅多选一次的 P2C 把最大负载降到 Θ(log log n) —— 几乎接近完美均衡。

代价：每次 O(1) + 一次比较，完全无锁，比 LC 更适合高并发。

生产采用：

  • gRPC 默认 LB
  • Envoy 的 LEAST_REQUEST（默认 choice_count=2）
  • Finagle（Twitter / X）
  • Spring Cloud LoadBalancer 2024 默认

朴素 WRR 的坑：为什么 Nginx 用平滑加权 ​

朴素 WRR (权重 5:1:1)：A A A A A B C   ← 突发打 A 5 次！
Nginx 平滑加权:        A B A C A A A   ← 均匀分散

Nginx 算法：每个节点维护"current_weight"，每次选 current 最大的，选完减去总权重 → 任何瞬间分布都接近期望比例，没有突发倾斜。

一致性哈希实战：虚拟节点数的工程经验 ​

物理节点数推荐虚拟节点数标准差
10 节点每节点 150< 10%
100 节点每节点 150< 5%
1000 节点每节点 150< 3%

⚠️ 虚拟节点 < 50 时一致性哈希就是个 "随机不均衡哈希"

很多自研一致性哈希实现把虚拟节点数写成 10-20 → 实际负载偏差可达 30%+。生产标配 150（Memcached / Redisson 默认）。

一致性哈希 ​

为什么需要一致性哈希？ 普通哈希（key % N）在增减节点时，几乎所有 key 都要重新映射。一致性哈希将节点和 key 映射到同一个环上，增减节点只影响相邻区间。

普通哈希：3 台变 4 台 → ~75% 的 key 需要重新映射
一致性哈希：3 台变 4 台 → ~25% 的 key 需要重新映射

虚拟节点： 为了解决节点在环上分布不均的问题，每个物理节点映射多个虚拟节点，使负载更均匀。

健康检查 ​

负载均衡器需要检测后端服务器的健康状态：

方式说明
TCP 检查尝试建立 TCP 连接
HTTP 检查发送 HTTP 请求检查响应状态码（如 /health 返回 200）
自定义脚本执行自定义检查逻辑
nginx
upstream backend {
    server 192.168.1.1:8080 max_fails=3 fail_timeout=30s;
    # 30 秒内失败 3 次则标记为不可用，30 秒后重新尝试
}

CDN + 负载均衡的典型架构 ​

用户 → CDN（边缘节点，缓存静态资源）
        ↓ 回源（动态请求）
      DNS 负载均衡（多机房）
        ↓
      LVS（四层负载均衡，高性能转发）
        ↓
      Nginx（七层负载均衡，URL 路由、SSL 终端）
        ↓
      后端服务集群（Spring Boot 应用）

面试常问 & 怎么答 ​

Q1: CDN 的工作原理？ ​

CDN 在全球各地部署边缘节点缓存内容。用户请求时，DNS 将域名解析到最近的节点。节点有缓存直接返回（缓存命中），没有则回源获取并缓存。核心价值是减少延迟和源站压力。

Q2: 四层和七层负载均衡的区别？ ​

四层（LVS）基于 IP 和端口转发，不解析 HTTP 内容，性能极高；七层（Nginx）解析 HTTP 内容，可以根据 URL、Header 做精细路由，还能做 SSL 终端和缓存。实际架构常组合使用：LVS 在前做高性能转发，Nginx 在后做精细路由。

Q3: 一致性哈希是什么？解决什么问题？ ​

普通哈希（key % N）在增减节点时大量 key 需要重新映射。一致性哈希将节点和 key 映射到环上，增减节点只影响相邻区间，大大减少数据迁移量。虚拟节点解决环上分布不均的问题。常用于分布式缓存。

Q4: 常见的负载均衡算法？ ​

轮询（平等分配）、加权轮询（按性能分配）、最少连接（分给最闲的）、IP 哈希（会话保持）、一致性哈希（缓存场景）。选择取决于场景：性能相同用轮询，需要会话保持用 IP 哈希，缓存场景用一致性哈希。

看到什么就先想到这类 ​

  • 出现 CDN、边缘节点、回源。
  • 出现负载均衡、LVS、Nginx 反向代理。
  • 出现轮询、加权轮询、最少连接。
  • 出现一致性哈希、虚拟节点。
  • 出现健康检查、故障转移。