如何通过 stream 模块实现 TCP 协议下数据库集群的高效负载均衡转发机制？

本文共计898个文字，预计阅读时间需要4分钟。

Nginx 的 stream 模块是TCP层负载均衡的核心组件，特别适合数据库集群这类长连接、低延迟、高并发场景。它不解析应用层内容，仅基于五元组（源IP、源端口、目标IP、目标端口、协议）做连接转发，开启小、吞吐高，能稳定支持十万级并发连接。

明确启用 stream 模块并分离配置结构
Nginx 默认不加载 stream 模块，需确认编译时已启用（--with-stream）。主配置文件 nginx.conf 中必须显式声明 stream { ... } 块，且不能放在 http { ... } 内部。推荐将 TCP 相关配置独立为 stream.conf，再通过 include stream.conf; 引入：

# nginx.conf 末尾添加 stream { include /etc/nginx/stream.conf; }

注意：conf.d/ 目录默认只用于 http 上下文，直接放 stream 配置不会生效。

定义 upstream 组并合理设置后端节点
针对数据库集群（如 MySQL、PostgreSQL、Galera），upstream 需体现连接特性：

• 使用 least_conn 算法优先分配新连接到当前活跃连接数最少的节点，避免连接堆积
• 对性能差异大的节点，可加 weight 参数（如 server 10.0.1.5:3306 weight=2;）
• 关键节点故障时自动切换，用 backup 标记备用实例
• 长连接场景建议启用 zone 指令，为共享内存分配空间，支撑多 worker 进程状态同步

示例：

# stream.conf upstream mysql_cluster { least_conn; zone tcp_mem 64k; server 10.0.1.10:3306 max_fails=3 fail_timeout=30s; server 10.0.1.11:3306 max_fails=3 fail_timeout=30s; server 10.0.1.12:3306 backup; }

max_fails 和 fail_timeout 构成基础健康检查——连续失败指定次数后，在超时期间不再转发流量。

配置 server 块完成端口监听与代理转发
server 块负责对外暴露端口，并将连接透传给 upstream：

• listen 必须指定端口（如 3306），支持 ssl、so_keepalive 等优化选项
• proxy_pass 指向 upstream 名称，不可带协议头（如 tcp://）
• 设置 proxy_timeout 为业务最大等待时间（如 proxy_timeout 1h;），避免空闲连接被中间设备断连
• proxy_connect_timeout 建议设为 1s～3s，快速感知后端不可达

示例：

server { listen 3306; proxy_pass mysql_cluster; proxy_connect_timeout 2s; proxy_timeout 3600s; proxy_responses 1; # 仅用于 TCP，表示期待至少 1 次响应（可选） }

补充关键优化与验证要点

• 启用 so_keepalive 可减少因网络空闲导致的连接中断：listen 3306 so_keepalive=on;
• 若数据库客户端使用连接池（如 Java 的 HikariCP），确保池大小与后端节点数、单节点承载能力匹配，避免连接打满
• 验证时用 mysql -h <nginx-ip> -P 3306 -u user -p 测试连通性，再用 ss -tn | grep :3306 观察连接是否分发到不同后端 IP
• 日志需单独开启 log_format 和 access_log 在 stream 上下文中，便于排查连接异常

不复杂但容易忽略。