如何利用 stream 模块的 least_time 算法优化数据库代理层面的响应延迟-Nginx-PHP中文网

nginx stream模块不支持least_time算法，因其工作在四层，无法获取应用层响应耗时；可用least_conn、一致性哈希、ip_hash或权重+健康检查等替代方案实现低延迟优化。

如何利用 stream 模块的 least_time 算法优化数据库代理层面的响应延迟

Nginx stream 模块不支持 least_time 算法——这是 HTTP 模块（http/upstream）中 ngx_http_upstream_module 提供的高级负载均衡策略，依赖于对 HTTP 响应头或完整响应体的时序测量，而 stream 模块工作在四层（TCP/UDP），不解析、不拦截、不等待应用层数据，因此无法获取 SQL 响应耗时、Redis 命令返回时间等指标。

所以，直接在 stream 的 upstream 块中写 least_time header 或 least_time last_byte 会导致配置加载失败（Nginx 启动报错：unknown directive "least_time"），或被静默忽略（取决于版本），起不到任何延迟优化作用。

真正适用于数据库 TCP 代理、能降低感知延迟的替代方案如下：

Upload audio to AIOZ Stream

快速上传音频至 AIOZ Stream API。支持默认或自定义编码配置创建音频对象，上传文件并完成处理后返回音频链接。

下载

least_conn
优先将新连接分发给当前活跃连接数最少的后端。对长连接密集型数据库（如 MySQL 连接池复用场景）非常有效，可避免某节点因连接堆积导致响应变慢。
hash $remote_addr consistent
对客户端 IP 做一致性哈希，使同一客户端长期固定连接到同一后端。减少连接抖动和 SSL/TLS 握手开销，提升复用率与稳定性；配合连接池使用，间接缩短首次查询延迟。
ip_hash（仅 IPv4）
简单哈希，适合小规模、IP 相对固定的内网环境，但扩容缩容时映射易失衡，不如 consistent 健壮。
手动权重 + 健康感知调度（需外部协同）
stream 本身不提供动态权重调整，但可通过以下方式近似实现“低延迟优先”：
- 使用 max_fails=1 fail_timeout=10s 快速剔除高延迟节点（表现为建连超时或握手失败）
- 配合外部健康检查脚本（如定期 mysqladmin ping + RTT 测量），自动重写 stream.conf 并 nginx -s reload
- 给性能更强的节点设更高 weight（如 server 10.0.1.10:3306 weight=3;）

关键配置示例（MySQL 场景）：

stream {
    upstream mysql_cluster {
        least_conn;
        zone tcp_mem 64k;

        server 10.0.1.10:3306 weight=2 max_fails=2 fail_timeout=5s;
        server 10.0.1.11:3306 weight=1 max_fails=2 fail_timeout=5s;
        server 10.0.1.12:3306 backup;
    }

    server {
        listen 3306;
        proxy_pass mysql_cluster;
        proxy_connect_timeout 2s;
        proxy_timeout 1h;
        proxy_responses 1;   # 等待首个 MySQL 协议响应包再判定成功
        so_keepalive on;
    }
}

⚠️ 注意：proxy_responses 1 是关键——它让 Nginx 在转发连接后，等待后端发出第一个有效响应包（如 MySQL handshake 初始化包）才认为连接就绪，避免把流量打到已卡顿但 TCP 连接仍存活的节点上，比单纯 max_fails 更贴近“低延迟可用性”。

如果业务对端到端查询延迟极其敏感（如金融交易类），建议在客户端侧做连接级路由（如使用 ProxySQL、MaxScale）或在应用层集成延迟感知逻辑，stream 模块更适合承担稳定、轻量、连接级的流量分发角色。