第八节——NGINX HTTP负载均衡

最新推荐文章于 2025-09-10 23:01:16 发布

转载最新推荐文章于 2025-09-10 23:01:16 发布 · 78 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://my.oschina.net/leeck/blog/1630057

文章标签：

#运维

本文介绍如何使用NGINX进行负载均衡配置，包括定义服务器组、选择负载均衡方法、设置服务器权重及被动健康检查等内容。

为什么80%的码农都做不了架构师？>>>

1 概述

跨多个应用实例负载均衡是一种常用的优化资源利用、最大化吞吐量、减少延迟和确保故障容错的技术。

2 代理一组HTTP服务器

为了使用NGINX代理一组HTTP服务器，首先，需要使用upstream指令定义组。指令放在http上下文中。

组中的服务器使用server指令配置（不要与定义在NGINX中的虚拟服务器混淆）。例如，以下配置定义一个名为backend的组，由三个服务器组成（可能解析为三个真实服务器）：

http {
    upstream backend {
        server backend1.example.com weight=5;
        server backend2.example.com;
        server 192.0.0.1 backup;
    }
}

为了传递请求到一个服务器组，在proxy_pass指令中指定组名（或fastcgi_pass、memcached_pass、scgi_pass或uwsgi_pass指令。）下一个例子中，一个虚拟服务器传递所有请求到backend上游组：

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

以下例子总结上面两个例子，展示代理请求到backend服务器组，服务器组由三个服务器组成，其中两个运行两个相同的应用实例，另一个是备份服务器，NGINX应用HTTP负载均衡分发请求：

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        server 192.0.0.1 backup;
    }
    
    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

3 选择负载均衡方法

NGINX支持四种轮询方法：

轮询：请求在服务器上均匀分发，考虑服务器权重。默认使用该方法。（无需指令启用）：

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

最少连接数：请求发送到最少活跃连接数的服务器上，考虑服务器权重。

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

IP哈希：通过客户端IP地址决定请求发送到那台服务器。要么都是IPv4地址，要么都是IPv6地址。该方法保证来自相同地址的请求到达相同的服务器除非不可用。

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

如果服务器需要临时移除，为了保护当前哈希的客户端IP地址，可以使用down参数标记。请求准备处理该服务器自动发送到组中的下一个服务器：

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

通用哈希：通过用户定义的键决定请求发送到那台服务器。该键可以是文本字符串、变量或组合。键可以是一对源IP地址和端口或URI：

upstream backend {
    hash $request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}

hash指令可选的consistent参数启用一致性哈希负载均衡算法。请求跨所有上游服务器基于用户定义哈希键值平均分发。

4 服务器权重

默认，NGINX在服务器组中按照权重使用轮询方法分发请求。server指令的weight参数设置该服务器的权重；默认为1：

upstream backend {
    server backend1.example.com weight=5;
    server backend2.example.com;
    server 192.0.0.1 backup;
}

在例子中，backend1.example.com权重为5；其它两台服务器默认权重为1，但其中一台IP地址192.0.0.1的服务器标记为备用服务器，不接收请求，除非其它服务器不可用。使用该权重配置，每六个请求，五个发送到backend1.example.com，一个发送到backend2.example.com。

5 被动健康检查

当NGINX认为一台服务器不可用时，NGINX临时停止发送请求给该服务器，直到它认为该服务器再次可用。为server指令配置以下参数，告诉NGINX如何判断一台服务器不可用：

max_fails：设置连续尝试多少次之后，NGINX标记该服务器为不可用。
fail_timeout：在max_fails失败尝试后，NGINX标记该服务器为不可用，fail_timeout时间内，NGINX认为该服务器任然不可用，超过该时间，NGINX会再次检查可用性。

默认值分贝为尝试1次和10秒。因此，如果一台服务器不能接收或响应一个请求，NGINX立即认为服务器10秒之内不可用，以下例子显示如何设置这些参数：

6 多个Worker进程共享数据

如果upstream块不包含zone指令，每个worker进程保存一份服务器组配置和维护一份相关计数器。计数器包括组中每个服务器当前的连接数和传递请求到每台服务器的尝试失败次数。因此，服务器组配置不会动态修改。

当在upstream块中包括zone指令，上游组的配置保存在所有worker进程的内存区域。这种情况是动态可配置的，因为worker进程访问相同的组配置备份并使用相同的相关计数器。

例如，如果组配置不共享，每个worker进程维护自己的尝试失败次数（通过max_fails参数设置）。这种情况，每个请求请求的成功与否只有一个worker进程知道。当worker进程选择处理一个请求传输到一台服务器失败，其它worker进程不知道这台服务器不可用，这些worker会继续分配请求给这些服务器，这无非是浪费性能。对于一台被认为是不可用的服务器，在fail_timeout参数设置的时间段内，失败尝试次数必须小于等于max_fails乘以worker进程数。话句话说，zone指令可以保证该行为。

类似，没有zone指令最少连接数负载均衡方法可能不会按照预期工作。该方法传递请求到有最少活跃连接数的服务器。如果不共享组配置，每个worker进程使用自己的连接数计数器，可能多个worker进程同时发送请求到一台服务器。然而，你可以增加请求数来降低影响。在高负载情况下，请求均匀分发给多个worker，最少连接方法预期工作。

6.1 设置区域大小

没有理想的内存区域大小，因为使用模式差异太大。每个启用的特性，例如，健康检查或DNS重新解析都会影响需要的区域大小。

upstream backend {
    zone backend 32k;
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

转载于:https://my.oschina.net/leeck/blog/1630057