挨踢而思

Menu

Administrator
Published on 2025-07-22 / 1 Visits
0

Nginx 负载均衡的几种方式和原理

#AI

Nginx 作为一款高性能的反向代理服务器，其负载均衡功能能够将客户端请求合理分发到多个后端服务器，从而提高系统的并发处理能力、可靠性和可用性。以下是 Nginx 常用的几种负载均衡方式及其原理：

一、轮询（Round Robin）

原理：轮询是 Nginx 负载均衡的默认方式。它按照请求的先后顺序，将每个新请求依次分配给后端服务器列表中的服务器，循环往复。

  • 例如：后端有服务器 A、B、C，第一个请求分配给 A，第二个给 B，第三个给 C，第四个又回到 A，以此类推。
  • 特点：无需额外配置，适用于后端服务器硬件配置相近、处理能力均衡的场景。
  • 注意：如果某台服务器宕机，Nginx 会自动将其从列表中剔除，不再分配请求；待服务器恢复后，会重新加入轮询队列。

二、权重（Weight）

原理：权重方式允许为不同的后端服务器设置不同的权重值（默认权重为 1），权重值越高，被分配到请求的概率越大。

  • 例如：服务器 A 权重为 3，服务器 B 权重为 1，则在 4 次请求中，A 会处理 3 次，B 处理 1 次。
  • 配置示例： 
    upstream backend {
    server 192.168.1.101 weight=3;  # 权重 3
    server 192.168.1.102 weight=1;  # 权重 1
}
  • 特点：适用于后端服务器硬件配置差异较大的场景，可通过权重调整资源利用率（如高性能服务器承担更多请求）。

三、IP 哈希（IP Hash）

原理：根据客户端的 IP 地址进行哈希计算，将同一 IP 地址的请求固定分配到同一台后端服务器。

  • 计算逻辑：对客户端 IP 进行哈希处理，得到一个数值，再与后端服务器数量取模，结果即为目标服务器的索引。
  • 配置示例： 
    upstream backend {
    ip_hash;  # 启用 IP 哈希
    server 192.168.1.101;
    server 192.168.1.102;
}
  • 特点：
    • 解决了“会话保持”问题（如用户登录状态、购物车数据等需在同一服务器上处理）。
    • 若某台服务器宕机，原分配到该服务器的请求会被重新哈希到其他服务器，可能导致会话丢失（需结合会话共享机制解决）。

四、最少连接（Least Connections）

原理：Nginx 会将新请求分配给当前活跃连接数最少的后端服务器，动态平衡服务器负载。

  • 例如：服务器 A 有 5 个活跃连接，服务器 B 有 2 个，则新请求会分配给 B。
  • 配置示例： 
    upstream backend {
    least_conn;  # 启用最少连接
    server 192.168.1.101;
    server 192.168.1.102;
}
  • 特点：适用于请求处理时间差异较大的场景（如部分请求需耗时计算），避免某台服务器因积累过多长连接而过载。

五、URL 哈希（URL Hash，第三方模块）

原理：根据请求 URL 的哈希值，将相同 URL 的请求分配到同一台后端服务器，适用于静态资源缓存场景（如同一图片请求固定到某台服务器，利用本地缓存提高效率）。

  • 注意：该方式不是 Nginx 原生支持，需通过第三方模块（如 ngx_http_upstream_hash_module）实现。
  • 配置示例： 
    upstream backend {
    hash $request_uri;  # 根据请求 URI 哈希
    server 192.168.1.101;
    server 192.168.1.102;
}

六、fair（第三方模块）

原理：根据后端服务器的响应时间来分配请求，响应时间越短（处理速度越快）的服务器，被分配到的请求越多。

  • 特点：动态根据服务器性能调整负载，更智能，但同样需要第三方模块（ngx_http_upstream_fair_module）支持，且兼容性较差。

总结

不同负载均衡方式适用于不同场景：

  • 轮询/权重：通用场景，简单易配置；
  • IP 哈希：需会话保持的场景（如登录系统）；
  • 最少连接：请求处理时间差异大的场景；
  • URL 哈希：静态资源缓存优化场景。

实际使用中，可结合后端服务器特性选择合适的方式，或通过组合配置（如权重 + 最少连接）进一步优化负载均衡效果。

原理

  1. 首次请求：客户端首次发送请求时，Nginx 按照预设的负载均衡策略（如轮询、权重等）将请求分配给某台后端服务器（例如服务器 A）。
  2. 设置 Cookie：服务器 A 处理请求后，Nginx 会在响应中插入一个特殊的 Cookie（通常包含服务器标识，如服务器 IP 或名称），告知客户端“后续请求请携带此 Cookie”。
  3. 后续请求：客户端再次发送请求时，会自动携带该 Cookie。Nginx 识别 Cookie 中的服务器标识后，直接将请求转发到对应的服务器 A，而非重新通过负载均衡策略分配。

配置示例（Nginx）

upstream backend {
    server 192.168.1.101;
    server 192.168.1.102;
    # 启用基于 Cookie 的会话黏连
    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        # 其他代理配置
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}
  • sticky cookie srv_id：指定 Cookie 名称为 srv_id，Nginx 会自动为该 Cookie 赋值（如后端服务器标识）。
  • expires=1h：设置 Cookie 有效期为 1 小时，过期后客户端会重新触发首次分配逻辑。
  • domain 和 path：限制 Cookie 的作用域，避免跨域或路径冲突。

特点

  1. 会话保持：解决了 IP 哈希无法应对的场景（如客户端通过 NAT 网关访问，导致多用户共用同一 IP），更精准地绑定客户端与服务器。
  2. 灵活性：Cookie 可配置有效期，过期后自动重新分配，避免某台服务器长期负载过高。
  3. 依赖客户端支持：需要客户端（浏览器等）支持 Cookie 功能，若客户端禁用 Cookie，该机制失效。
  4. 非原生模块：Nginx 原生不支持 sticky 指令，需通过第三方模块（如 ngx_http_sticky_module）或商业版 Nginx Plus 实现。

适用场景

  • 需保持会话状态的 Web 应用（如电商购物车、用户登录状态）。
  • 客户端 IP 不固定（如动态 IP、NAT 环境），IP 哈希策略失效的场景。

与 IP 哈希相比，Cookie 黏连更灵活，但依赖客户端 Cookie 支持；实际使用中需根据业务场景选择合适的会话保持方案。

国内 Docker 服务状态 & ...