Nginx四层负载均衡是突破跨机房中间件同步瓶颈的关键，基于TCP/UDP的IP和端口转发，不解析应用层协议，通过stream模块实现高性能、低延迟的连接透传，支持least_conn调度、直连健康检查与长连接保活，专用于MySQL、Redis、Kafka等中间件跨机房流量调度。
四层负载均衡是突破跨机房中间件同步瓶颈的关键一环，它不解析应用层协议，只基于 TCP/UDP 的 IP 和端口做转发，天然适合数据库、消息队列、缓存等中间件的跨机房流量调度。Nginx 从 1.9.0 开始通过 stream 模块原生支持四层代理，性能高、延迟低、配置轻量，特别适合作为中间件跨机房通信的“通道控制器”。
用 stream 模块直连中间件，绕过七层解析开销
中间件（如 MySQL 从库集群、Redis Sentinel、Kafka broker）通常使用自定义二进制协议或简单文本协议，七层代理会引入不必要的解析、重写和连接池管理，反而成为瓶颈。Nginx 四层代理仅做连接透传，全程零协议解析：
- 在主配置中启用
stream上下文，与http块并列，避免模块冲突 - 监听中间件端口（如
listen 3306或listen 6379 ssl），不走 HTTP 流程 - 后端地址必须使用内网直连 IP + 端口，禁止走公网或经其他代理中转，否则放大 RTT 和丢包影响
- 对 SSL 类中间件（如 Redis TLS、Kafka SASL_SSL），需配置
ssl_preread on提前读取 SNI，实现多租户复用同一端口
按网络拓扑选算法：least_conn 是跨机房首选
跨机房链路 RTT 高、波动大，轮询容易把请求打到已堆积连接的慢节点上。least_conn 动态感知后端活跃连接数，更适合长连接型中间件：
- 在
upstream中明确声明least_conn，而非依赖默认轮询 - 搭配
max_fails=2 fail_timeout=15s，快速剔除因网络抖动暂时不可达的节点 - 若需读写分离（如 MySQL 主从），可拆分为两个 upstream：
mysql_master和mysql_slave，由上游业务按 SQL 类型路由 - 避免使用
ip_hash：NAT 环境下用户 IP 高度集中，极易导致某台后端过载
健康检查必须直连、宽限、双模式
中间件端口健康状态不能靠被动失败推断——一次超时可能只是瞬时丢包。主动检查必须真实反映链路与服务可用性：
- 主动检查路径应直连后端内网地址（如
192.168.10.5:3306），禁用 DNS 解析或代理跳转 - 超时参数按实测 P99 RTT 设置：例如跨城链路 P99 RTT 为 40ms，则
timeout=60ms，interval=5s，fails=3 - 开启双模式：主动检查用于快速恢复，被动检查（
proxy_next_upstream error timeout）兜底防漏判 - 对 MySQL 可用性检查，建议用
tcp_check（需编译 stream-upstream-check-module）或自定义 TCP 探针，比 HTTP 健康接口更贴近真实连接行为
连接复用与保活：降低跨机房握手损耗
跨机房建连成本远高于同机房，频繁 SYN/SYN-ACK 会显著抬高首包延迟。必须启用并调优长连接：
- 在 upstream 中配置
keepalive 64（建议值为单 worker 并发连接数的 1/3～1/2） - 设置
proxy_timeout 30s和proxy_responses 1，防止空闲连接被中间设备（如防火墙）静默断开 - 客户端侧需配合开启连接复用（如 JDBC 的
useSSL=false&cachePrepStmts=true），否则 Nginx 的 keepalive 无法生效 - 对 Kafka 等长连接场景，建议关闭
proxy_buffering off，避免缓冲区阻塞消息流
