Nginx Upstream 配置教程：从入门到精通

Nginx 是一款高性能的 HTTP 和反向代理服务器，而 upstream 模块则是 Nginx 实现负载均衡和高可用的关键组件。通过 upstream 模块，可以将客户端请求分发到多个后端服务器，从而提高网站的并发处理能力和可用性。本教程将带你深入了解 Nginx upstream 的配置，从基础概念到高级技巧，助你成为 Nginx upstream 配置高手。

一、 认识 Upstream：负载均衡的基石

1.1 什么是 Upstream？

Upstream 模块定义了一组后端服务器，Nginx 可以将请求代理到这些服务器。这组服务器可以提供相同的服务，也可以根据配置提供不同的服务。Upstream 的核心作用是实现负载均衡，将请求分发到不同的服务器，避免单点故障，提高整体性能和可用性。

1.2 为什么需要 Upstream？

• 负载均衡： 将请求分发到多个服务器，避免单个服务器过载，提高系统整体吞吐量。
• 高可用性： 当某个后端服务器宕机时，Nginx 可以自动将请求转发到其他健康的服务器，确保服务的持续可用。
• 可扩展性： 可以方便地添加或删除后端服务器，根据业务需求灵活调整系统规模。
• 灰度发布： 通过配置不同服务器的权重，可以实现灰度发布，逐步将流量切换到新版本的服务器。

二、 Upstream 基础配置：快速上手

2.1 Upstream 指令块

upstream 配置位于 http 指令块内，基本语法如下：

```nginx
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
}

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

}
```

• upstream backend: 定义一个名为 backend 的 upstream 组。
• server backend1.example.com: 指定后端服务器的地址，可以是域名或 IP 地址。
• proxy_pass http://backend: 将请求代理到名为 backend 的 upstream 组。

2.2 常用服务器参数

在 server 指令中，可以使用以下参数来配置后端服务器：

• weight=number: 设置服务器的权重，默认为 1。权重越高，被分配到的请求越多。
• max_fails=number: 失败尝试次数，默认为 1。当对该服务器的请求在一定时间内失败次数达到 max_fails 时，认为该服务器不可用。
• fail_timeout=time: 设置失败超时时间，默认为 10 秒。在该时间段内，当失败次数达到 max_fails 时，服务器被标记为不可用，并且在 fail_timeout 时间内不再被分配请求。
• down: 将服务器标记为永久不可用，用于手动维护。
• backup: 将服务器标记为备用服务器。只有当所有非备用服务器都不可用时，才会将请求转发到备用服务器。

示例：

nginx
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.100 backup;
}

这个例子配置了一个名为 backend 的 upstream 组，包含三个服务器：

• backend1.example.com 权重为 5。
• backend2.example.com:8080 端口为 8080，最大失败次数为 3，失败超时时间为 30 秒。
• 192.168.1.100 是一个备用服务器。

三、 负载均衡算法：请求分发的策略

Nginx 提供了多种负载均衡算法，可以根据不同的应用场景选择合适的算法。

3.1 轮询（Round Robin）

这是默认的负载均衡算法，将请求依次分配给每个后端服务器。简单高效，适用于后端服务器配置相近的场景。

3.2 加权轮询（Weighted Round Robin）

根据服务器的权重进行轮询，权重高的服务器会收到更多的请求。适用于后端服务器配置不同的场景。

3.3 IP 哈希（IP Hash）

根据客户端 IP 地址的哈希值将请求分配到固定的服务器。可以确保来自同一个 IP 的请求始终被转发到同一个后端服务器，适用于需要保持会话的场景。

配置示例：

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

3.4 最少连接（Least Connections）

将请求分配到当前连接数最少的服务器。适用于后端服务器处理请求的速度差异较大的场景。

配置示例：

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

3.5 通用哈希（Generic Hash）

根据指定的变量（如 URL、URI 等）的哈希值将请求分配到固定的服务器。

配置示例：

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

3.6 一致性哈希（Consistent Hashing）

该算法利用哈希环来分配请求。可以最大程度地减少服务器数量变化时导致的缓存失效问题。需要使用 hash 指令，并指定 consistent 参数。

配置示例：

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

四、 健康检查：保障服务可用性

Nginx 可以对后端服务器进行健康检查，及时发现并剔除故障服务器，确保服务的可用性。

4.1 被动健康检查

这是 Nginx 的默认健康检查方式，通过分析代理请求的响应状态来判断服务器是否健康。如果某个服务器连续多次返回错误状态码，则认为该服务器不健康，并在一段时间内不再将请求转发到该服务器。

4.2 主动健康检查 (Active Health Checks)

Nginx Plus 提供了主动健康检查功能，可以定期向后端服务器发送特定的请求，并根据响应结果判断服务器的健康状态。这需要使用 health_check 指令。

配置示例 (仅限 Nginx Plus)：

```nginx
http {
upstream backend {
zone backend 64k;
server backend1.example.com;
server backend2.example.com;
}

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

    location /status {
        # 启用健康检查状态页面
        health_check_status;
    }
}

}
```

health_check 指令的常用参数：

• interval=time: 设置健康检查的间隔时间，默认为 5 秒。
• fails=number: 连续失败多少次后认为服务器不健康，默认为 1。
• passes=number: 连续成功多少次后认为服务器健康，默认为 1。
• uri=uri: 指定健康检查请求的 URI，默认为 /。
• match=name: 指定一个 match 块，用于定义健康检查成功的条件。

match 块示例 (仅限 Nginx Plus)：

```nginx
match backend_status {
status 200;
header Content-Type = text/html;
body ~ "Server is up!";
}

server {
location / {
proxy_pass http://backend;
health_check match=backend_status;
}
}
```

这个例子定义了一个名为 backend_status 的 match 块，要求健康检查的响应状态码为 200，Content-Type 为 text/html，并且响应体中包含 "Server is up!" 字符串。

五、 高级配置技巧：精益求精

5.1 共享内存区域 (Shared Memory Zones)

使用 zone 指令可以定义一个共享内存区域，用于存储 upstream 组的配置和运行时状态信息。这可以提高配置的效率，并支持动态配置（如 Nginx Plus 的 API）。

配置示例：

nginx
upstream backend {
zone backend 64k;
server backend1.example.com;
server backend2.example.com;
}

5.2 慢启动 (Slow Start)

当一个服务器被标记为健康并重新加入 upstream 组时，慢启动功能可以逐渐增加该服务器的请求量，避免突然的流量冲击导致服务器过载。这需要使用 slow_start 参数。

配置示例 (仅限 Nginx Plus)：

nginx
upstream backend {
zone backend 64k;
server backend1.example.com slow_start=30s;
server backend2.example.com;
}

这个例子中，backend1.example.com 在重新加入 upstream 组后的 30 秒内，其权重会逐渐增加，直到达到配置的权重值。

5.3 队列 (Queues)

当所有后端服务器都处于忙碌状态时，队列功能可以将请求放入队列中，等待服务器空闲后再进行处理。这可以避免请求被拒绝，提高系统的可用性。这需要使用 queue 指令。

配置示例 (仅限 Nginx Plus)：

nginx
upstream backend {
zone backend 64k;
server backend1.example.com;
server backend2.example.com;
queue 100 timeout=30s;
}

这个例子中，当所有后端服务器都忙碌时，最多可以将 100 个请求放入队列中，等待时间最长为 30 秒。如果队列已满或等待超时，则返回错误。

5.4 会话持久性 (Session Persistence)

除了 IP 哈希之外，Nginx Plus 还提供了更高级的会话持久性方法，如基于 Cookie 的会话持久性。这需要使用 sticky 指令。

配置示例 (仅限 Nginx Plus)：

nginx
upstream backend {
zone backend 64k;
sticky cookie srv_id expires=1h domain=.example.com path=/;
server backend1.example.com;
server backend2.example.com;
}

这个例子中，Nginx 会根据名为 srv_id 的 Cookie 值将请求转发到固定的服务器。

六、 总结与展望

本教程详细介绍了 Nginx upstream 模块的配置，从基础概念到高级技巧，涵盖了负载均衡算法、健康检查、共享内存区域、慢启动、队列和会话持久性等方面。掌握这些知识，可以帮助你构建高性能、高可用、可扩展的 Web 应用。

随着云计算和微服务架构的普及，Nginx upstream 的应用场景越来越广泛。未来，Nginx upstream 还将继续发展，提供更强大的功能和更灵活的配置方式，以适应不断变化的业务需求。希望本教程能帮助你更好地理解和应用 Nginx upstream，构建更加稳定和高效的 Web 服务。

不断学习和实践，才能更好地掌握 Nginx upstream 的精髓。建议你结合实际场景，不断尝试不同的配置，并深入研究 Nginx 的官方文档，以便更深入地理解和应用 Nginx upstream。

希望这篇文章对你有所帮助！如果你有任何问题，欢迎随时提出。