Nginx 实战指南：如何利用四层代理技术解决跨机房数据库同步难题-Nginx-PHP中文网

nginx四层代理不负责数据库同步，仅透明转发tcp连接；它为已配置好的跨机房同步架构（如mysql主从、redis cluster）提供无感路由，支持按策略将读写请求分发至本地或异地节点，并依赖健康检查与外部监控联动保障可用性。

nginx 实战指南：如何利用四层代理技术解决跨机房数据库同步难题

四层代理本身不解决数据库同步问题，它只负责TCP连接的透明转发。跨机房数据库同步是数据复制层面的事，Nginx四层代理能做的是让应用无感地访问异地数据库节点，为同步架构提供网络层支撑。

明确角色分工：代理 ≠ 同步

Nginx stream模块不读取、不解析、不修改数据库协议内容（如MySQL的binlog、Redis的RESP），它只做端口级流量搬运。真正的数据同步需依赖数据库自身机制：

MySQL：主从复制（GTID/半同步）、MHA、Orchestrator 或云厂商的DTS服务
Redis：主从+哨兵、Cluster模式、或RedisShake等第三方同步工具
PostgreSQL：逻辑复制、BDR、pglogical

四层代理的作用，是在这些同步机制已就绪的前提下，把客户端请求智能路由到“当前最优”的数据库实例上，比如读流量走从库、写流量走主库、故障时自动切到备用机房。

典型跨机房代理架构配置

假设华东（sh）和华南（gz）两个机房各有一套MySQL主从集群，且已通过异步复制完成数据同步。你希望应用统一连接db-proxy.example.com:3306，由Nginx按策略分发：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

正常情况下，读请求打到本地从库（低延迟）
本地从库不可用时，自动降级到异地从库
写请求始终打到本机房主库（避免跨机房写放大）

关键配置示例（stream块内）：

upstream mysql_sh_master {
    server 10.1.1.10:3306 weight=10 max_fails=3 fail_timeout=30s;
}
upstream mysql_sh_slave {
    server 10.1.1.20:3306 weight=5;
    server 10.1.1.21:3306 backup; # 华南从库作为备选
}
upstream mysql_gz_master {
    server 10.2.1.10:3306 weight=10;
}
upstream mysql_gz_slave {
    server 10.2.1.20:3306 weight=5;
    server 10.1.1.20:3306 backup; # 华东从库作为备选
}
<p>server {
listen 3306;
proxy_pass mysql_sh_master; # 默认写入华东主库
proxy_timeout 1s;
proxy_responses 1;
}</p><p>server {
listen 3307;
proxy_pass mysql_sh_slave; # 读请求走华东从库，失败则用backup
}</p>