健康检查与会话保持

约 726 字大约 2 分钟

布欧-Lewyon

2026-05-15

被动健康检查

Nginx 开源版支持被动健康检查——根据实际请求的响应情况判断后端是否可用。

upstream backend {
    server 10.0.0.1:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:3000 max_fails=3 fail_timeout=30s;
}

参数	默认值	说明
`max_fails`	1	在 `fail_timeout` 内最多失败次数
`fail_timeout`	10s	该时间内达到 `max_fails` 则标记为不可用

# 检测逻辑
# 1. 30 秒内有 3 次请求失败 → 标记后端不可用
# 2. 标记不可用后 30 秒内不转发请求给该后端
# 3. 30 秒后尝试转发一个请求——成功了则恢复，失败则再等 30 秒

失败条件

# 默认只检测网络错误（超时、连接拒绝等）
# 可用 proxy_next_upstream 扩展检测条件
location / {
    proxy_pass http://backend;
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
}

条件	含义
`error`	与后端建立连接/发送/读取错误
`timeout`	与后端的通信超时
`invalid_header`	后端返回了空的或无效的响应头
`http_500`	后端返回 500 状态码
`http_502`	后端返回 502 状态码
`http_503`	后端返回 503 状态码
`non_idempotent`	对 POST/PUT 等非幂等方法也尝试其他后端

主动健康检查（Nginx Plus）

Nginx Plus 商业版支持主动健康检查，定期向后端发送探测请求：

# Nginx Plus 配置示例
upstream backend {
    zone backend 64k;

    server 10.0.0.1:3000;
    server 10.0.0.2:3000;

    health_check interval=5s fails=3 passes=2 uri=/health;
}

开源版可以通过第三方模块（nginx_upstream_check_module）或外部工具实现类似功能。

会话保持方案

方案一：ip_hash

upstream backend {
    ip_hash;                     # 同一源 IP 始终转发到同一后端
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
}

问题：客户端通过 NAT 时，多个用户共享同一 IP，流量不均匀。如果后端扩缩容，哈希重新分配导致 Session 失效。

# Nginx Plus
upstream backend {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

方案三：通用 Session 存储

推荐方案：各后端不存 Session，使用集中存储（Redis / Memcached）。

无论请求到哪个后端，Session 数据都从 Redis 读取，实现无状态后端。

重试与容错

location / {
    proxy_pass http://backend;

    # 请求失败后重试其他后端（最多 3 次）
    proxy_next_upstream error timeout invalid_header http_500;
    proxy_next_upstream_tries 3;
    proxy_next_upstream_timeout 10s;
}

小结

Nginx 开源版通过 max_fails + fail_timeout 实现被动健康检查。
proxy_next_upstream 扩展失败检测范围（包括 HTTP 500 等）。
ip_hash 是开源版唯一的会话保持手段，但有局限性。
生产推荐使用 Redis 集中 Session，后端实现无状态化。
Nginx Plus 提供主动健康检查和 sticky cookie 会话保持。

上一节：upstream 与负载均衡算法下一节：TCP/UDP 负载均衡