我的学习空间

Nginx 负载均衡常见调度算法与参数详解

一、调度算法对比表

算法关键字工作原理优点缺点是否Nginx原生适用场景
轮询默认（无关键字）按时间顺序逐一分配到不同服务器简单公平，无需配置不考虑服务器性能差异✅ 是服务器配置相同的场景
加权轮询weight按权重比例分配，权重越高分配越多能根据服务器性能调整负载需要手动配置权重✅ 是服务器性能不均
IP哈希ip_hash根据客户端IP的hash结果分配，同一IP固定到同一台解决session共享问题负载可能不均✅ 是需要会话保持的应用
最少连接least_conn分配给当前连接数最少的服务器动态平衡，考虑实时负载需要维护连接状态✅ 是请求处理时间差异大的场景
URI哈希hash $uri根据请求URI的hash结果分配相同URI始终到同一台，提高缓存命中率可能负载不均✅ 是缓存服务器
参数哈希hash $arg_xxx根据请求参数的hash结果分配可根据业务维度分流需选择合适的参数✅ 是多租户系统
公平调度fair根据后端响应时间分配，响应短的优先智能动态调整Nginx本身不支持，需第三方模块❌ 否对响应时间敏感的场景
URL哈希url_hash按访问URL的hash结果分配提高缓存效率Nginx本身不支持，需安装hash包❌ 否缓存服务器集群

二、调度算法配置示例

# 轮询（默认）
upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

# 加权轮询
upstream backend {
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080 weight=2;
    server 192.168.1.12:8080 weight=1;
}

# IP哈希
upstream backend {
    ip_hash;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

# 最少连接
upstream backend {
    least_conn;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

# URI哈希
upstream backend {
    hash $request_uri consistent;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

# fair（需安装第三方模块）
upstream backend {
    fair;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

# url_hash（需安装hash包）
upstream backend {
    hash $request_uri;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

三、服务器状态参数表

状态参数作用默认值配置示例说明
down标记服务器永久下线–server 192.168.1.10:8080 down;手动维护时使用，不参与负载均衡
backup标记为备用服务器–server 192.168.1.10:8080 backup;其他服务器都故障时才启用
weight设置服务器权重1server 192.168.1.10:8080 weight=5;值越大，分配请求越多
max_fails允许的最大失败次数1server 192.168.1.10:8080 max_fails=3;连续失败多少次后认为宕机
fail_timeout失败后的暂停时间10sserver 192.168.1.10:8080 fail_timeout=30s;在fail_timeout内失败max_fails次，标记为宕机

四、状态参数配置示例

upstream backend {
    # 主服务器组
    server 192.168.1.10:8080 weight=5 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 weight=5 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 weight=3 max_fails=3 fail_timeout=30s;

    # 备用服务器（当主服务器都宕机时启用）
    server 192.168.1.13:8080 backup;

    # 临时下线的服务器（维护中）
    server 192.168.1.14:8080 down;
}

五、算法与参数的兼容性表

算法支持 weight支持 backup支持 down支持 max_fails支持 fail_timeout说明
轮询✅✅✅✅✅所有参数都支持
加权轮询✅✅✅✅✅weight是核心参数
最少连接✅✅✅✅✅所有参数都支持
IP哈希❌❌✅✅✅不能设置weight和backup
URI哈希❌❌✅✅✅不能设置weight和backup
参数哈希❌❌✅✅✅不能设置weight和backup
fair✅✅✅✅✅需第三方模块
url_hash❌❌✅✅✅需安装hash包

六、常见问题及解决方案

问题原因解决方案
ip_hash 时某个服务器压力过大某些IP段的客户端特别多使用一致性哈希(hash $remote_addr consistent)
后端服务器响应慢但仍在服务健康检查只检查端口，不检查响应时间使用第三方模块如nginx_upstream_check_module
session丢失轮询导致请求到不同服务器改用ip_hash或使用集中式session存储（Redis）
备份服务器从未使用主服务器一直正常正常现象，backup就是备用的
max_fails设置太小网络波动导致误判适当调大max_fails和fail_timeout

七、完整配置示例

upstream backend {
    # 调度算法：IP哈希（解决session问题）
    ip_hash;

    # 主服务器
    server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 max_fails=3 fail_timeout=30s;

    # 注意：ip_hash 下不能使用 weight 和 backup
}

upstream api_backend {
    # 最少连接（适合API服务）
    least_conn;

    # 加权轮询
    server 192.168.1.20:8080 weight=5 max_fails=3 fail_timeout=30s;
    server 192.168.1.21:8080 weight=5 max_fails=3 fail_timeout=30s;
    server 192.168.1.22:8080 weight=3 max_fails=3 fail_timeout=30s;

    # 备用
    server 192.168.1.23:8080 backup;
}

upstream static_backend {
    # URI哈希（提高缓存命中率）
    hash $request_uri consistent;

    server 192.168.1.30:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.31:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.32:8080 max_fails=3 fail_timeout=30s;
}

八、算法选择速查表

业务场景推荐算法原因
静态文件服务器轮询 或 加权轮询请求处理时间相近，简单均衡
API 服务最少连接接口处理时间差异大
需要登录的网站IP哈希保持会话，避免登录状态丢失
缓存服务器URI哈希相同资源始终到同一台，提高缓存命中率
多租户系统参数哈希确保同一租户数据在同一台
服务器配置差异大加权轮询按能力分配请求
对响应时间敏感fair智能选择响应快的服务器（需第三方模块）

xuankin
,

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注