Nginx加权轮询指南：配置weight实现数据库读写分离-Nginx-PHP中文网

Nginx 不能实现数据库读写分离，因其无 SQL 解析能力、不维护事务状态、仅支持连接级转发；真正读写分离需由应用层或 ProxySQL 等中间件完成。

nginx加权轮询指南：配置weight实现数据库读写分离

nginx 本身不直接参与数据库读写分离，它不能连接或转发数据库请求（如 MySQL、PostgreSQL 的 TCP 流量），因此 不能用 weight 配置实现真正的数据库读写分离。这是常见的误解。Nginx 的 upstream 模块支持 weight 的负载均衡策略，但仅适用于 HTTP/HTTPS 或 TCP/UDP 代理（需 stream 模块），且对象是后端应用服务器（如 Web API、Java 服务），不是数据库本身。

为什么 nginx 不能直接做数据库读写分离

数据库读写分离需满足几个关键条件：识别 SQL 类型（SELECT vs INSERT/UPDATE）、维护事务一致性、处理主从延迟、路由到不同实例。这些逻辑远超反向代理的能力范围。Nginx：

无 SQL 解析能力，无法判断请求是读还是写
不维护数据库连接状态，不理解事务边界
即使启用 stream 模块做 TCP 代理，也只是按连接转发，无法按语句拆分
weight 仅控制后端节点的流量分配比例，不涉及语义路由

真正可行的读写分离方案

应由应用层或专用中间件承担：

应用框架内置支持：如 Laravel 的 read/write connections、Spring Boot + AbstractRoutingDataSource、Django 多数据库路由
数据库中间件：MyCat、ShardingSphere-Proxy、MaxScale（MySQL 官方推荐）、ProxySQL（支持读写分离+自动故障转移）
客户端驱动增强：如 MySQL Connector/J 的 loadBalance 或 replication 连接模式，配合主从配置自动分发

nginx 可以辅助什么场景？

虽然不直接代理数据库，但 nginx 能在架构中起到间接支撑作用：

为读写分离后的应用服务做负载均衡（例如：把 Web 请求分发到多个读写分离网关实例）
用 weight 给不同性能的 API 服务节点分配流量（如主库对接的服务权重设高，从库对接的服务权重设低）
配合健康检查，自动剔除异常的读库服务节点
通过 stream 模块代理数据库管理端口（如 MySQL 的 3306），但必须搭配 ProxySQL 等中间件使用，而非直连 DB

一个典型部署示意

用户 → nginx（HTTP 负载）→ 应用集群 → ProxySQL（读写分离）→ MySQL 主库 + 多个从库

其中 nginx 的 upstream 可配置 weight：

upstream app_servers {
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080 weight=2;
    server 192.168.1.12:8080 weight=1;
}

这影响的是应用服务的流量分布，和数据库无关。真正的读写决策由 ProxySQL 根据 SQL 类型、权重、延迟等规则完成。