Nginx原生不支持按内存占用动态负载均衡，但可通过least_conn近似、外部控制器动态更新upstream配置，或OpenResty+Lua运行时调度三种方式实现；其中动态upstream方案兼容性好、运维可控，为生产推荐做法。
Nginx 本身不直接感知后端节点的内存占用情况，它无法主动读取 free -m 或 /proc/meminfo 等系统指标来动态调整流量分发。它的标准负载均衡策略（如轮询、least_conn、ip_hash、weight）均基于请求层面或连接状态，而非实时资源指标。
但你可以通过“外部反馈 + Nginx 动态配置更新”的方式，间接实现“按内存占用均衡”的效果。核心思路是：让内存使用率成为调度决策的输入，再驱动 Nginx 的 upstream 配置变更。
以下是可行且生产中较成熟的实现路径：
✅ 1. 使用 least_conn 作为基础代理策略（轻量近似）
least_conn 虽不等于“低内存”，但在多数计算密集型服务中，内存压力常伴随高并发连接（如长任务、缓存堆积、GC 频繁）。因此：
- 它能天然规避已过载的节点（连接数多 → 往往内存/负载也高）
- 无需额外组件，开箱即用
upstream compute_nodes {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}⚠️ 注意：该策略仅适用于后端服务真实反映连接负载（如 HTTP Keep-Alive 长连接、WebSocket、异步计算 API），对短平快的无状态请求效果有限。
✅ 2. 构建内存感知的动态 upstream（推荐）
这是真正实现“按内存均衡”的主流做法，分三步：
▪ 后端暴露内存健康端点
每个计算节点提供 /health/metrics 接口，返回 JSON，例如：
{ "memory_used_percent": 72.3, "load_avg": 4.1, "status": "healthy" }可用轻量脚本（Python/Shell）定时采集并写入本地文件，或由应用直接暴露（如 Spring Boot Actuator + Prometheus Exporter）。
▪ 外部控制器定期评估并生成 upstream 配置
用 Python/Go 写一个简单控制器（每 10–30 秒执行一次）：
- 请求所有节点的
/health/metrics - 按
memory_used_percent反向加权（内存越低，权重越高） - 生成新的
upstream块（例如upstream dynamic_compute { server ... weight=...; }） - 写入临时配置文件（如
/etc/nginx/conf.d/dynamic-upstream.conf）
示例权重逻辑（Python 伪代码）：
weights = {}
for node in nodes:
p = node["memory_used_percent"]
# 内存 30% → 权重 10；80% → 权重 2；超 95% 则设为 down
w = max(1, int(100 / (p + 10)))
weights[node["addr"]] = w if p < 95 else 0▪ Nginx 加载动态配置并热重载
确保你的 nginx.conf 包含该动态文件：
http {
include /etc/nginx/conf.d/dynamic-upstream.conf;
server {
location /compute {
proxy_pass http://dynamic_compute;
# 其他 proxy_* 设置...
}
}
}控制器在写完新配置后，执行：
nginx -t && nginx -s reload
✅ 优势：完全自主可控，不依赖第三方模块；兼容所有 Nginx 版本（1.9.0+ 支持
include动态加载）
⚠️ 注意：避免高频 reload（建议最小间隔 ≥5s），可配合nginx -s reload的原子性与proxy_next_upstream error timeout提升容错。
✅ 3. 结合 OpenResty + Lua 实现运行时决策（高级）
如果你使用 OpenResty（Nginx + Lua），可在 balancer_by_lua_block 中实时调用后端指标接口，并基于内存数据选择目标节点：
upstream compute_backend {
server 0.0.0.0:1; # 占位，实际由 Lua 分配
}
server {
location /compute {
balancer_by_lua_block {
local balancer = require "ngx.balancer"
local http = require "resty.http"
local httpc = http:new()
-- 查询各节点内存（可缓存结果减少延迟）
local nodes = {"192.168.1.10", "192.168.1.11"}
local best_node = nodes[1]
local min_mem = 100
for _, ip in ipairs(nodes) do
local res, err = httpc:request_uri("http://"..ip..":8080/health/metrics")
if res and res.body then
local data = cjson.decode(res.body)
if data.memory_used_percent and data.memory_used_percent < min_mem then
min_mem = data.memory_used_percent
best_node = ip
end
end
end
local ok, err = balancer.set_current_peer(best_node, 8080)
}
proxy_pass http://compute_backend;
}
}✅ 优势：毫秒级响应、无 reload 开销、支持复杂策略（如内存+CPU+延迟加权）
⚠️ 注意：需启用 OpenResty，Lua 脚本需严格控制超时与错误处理，避免阻塞 worker 进程。
Nginx 无法原生按内存做负载均衡，但通过 least_conn 近似、外部控制器动态重写 upstream、或 OpenResty 运行时调度，都能有效达成目标。选哪种取决于你对实时性、运维复杂度和基础设施成熟度的要求。
