Nginx算法最全详解(5大主流算法)

Nginx是大型架构的必备中间件，也是大厂经常考察的内容，下面我就全面来详解Nginx算法@mikechen

轮询（Round Robin）

✅ 原理图解

轮询算法会将请求依次分发给各个后端服务器，不考虑服务器当前负载：

upstream backend {
    server 192.168.1.101;
    server 192.168.1.102;
    server 192.168.1.103;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

Nginx默认使用轮询算法，按顺序分发请求。

请求1 → 后端A
请求2 → 后端B
请求3 → 后端C
请求4 → 后端A
……

✅ 优点与缺点

优点：

• 实现简单
• 默认启用，无需额外配置

缺点：

• 忽略后端服务器的实际负载
• 不适合性能差异明显的服务器集群

✅ 应用场景

• 后端服务器性能相近
• 请求处理时间差异不大

 

加权轮询（Weighted Round Robin）

加权轮询是对轮询的改进，通过为每台服务器分配权重来决定请求分发的频率，权重高的服务器会接收更多请求。

逻辑：假设服务器A权重为3，B为2，C为1，则请求分配比例为3:2:1。

A(权重5), B(权重1), C(权重1)

请求分发顺序示意：

A A A A A B C A A A A A B C …

✅ 动态权重调整技巧

可基于：

• 健康检查结果
• 后端负载实时反馈（需配合第三方模块）

例如：

server 192.168.1.101 weight=5;
server 192.168.1.102 weight=1;


✅ 配置示例

upstream backend {
    server backend1.example.com weight=3;
    server backend2.example.com weight=2;
    server backend3.example.com weight=1;
}
server {
    location / {
        proxy_pass http://backend;
    }
}

这里服务器1处理50%的请求，服务器2处理33%，服务器3处理17%。

 

最少连接数（Least Connections）

应用场景：

• 后端服务器性能差异较大。
• 应用中存在长连接或连接保持时间不确定的情况。
• 需要根据服务器的实际负载进行动态调整的场景。

✅ 和RR对比分析

特性	Round Robin	Least Connections
实现复杂度	简单	略高
是否考虑负载	❌	✅
适用于	均衡场景	动态请求耗时场景

✅ 配置示例

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
    }
}

 

源地址哈希（IP Hash）

✅ 请求分发图

IP Hash基于客户端IP地址进行哈希计算，分发请求：

hash(IP) % N（N为后端数量）

相同IP → 相同后端

✅ 保持会话的典型场景

• 登录状态保持（Session粘性）
• Cookie依赖于后端一致性时

✅ 配置示例

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
    }
}

 

一致性哈希（Consistent Hash）

【需第三方模块 nginx-upstream-consistent-hash】

✅ 哈希环图解

使用一致性哈希将请求映射到“环”上的节点上：

• 节点少量变化 → 映射关系局部变化，缓存命中率高
• 增减节点对已有请求影响小

✅ 缓存一致性保障

适用于：

• 分布式缓存系统（如 Memcached, Redis 集群）
• 长连接保持会话粘性

✅ 典型使用场景（如动态节点）

• 微服务节点频繁变更
• 高并发、缓存敏感场景