四层负载均衡不支持基于sql语义的读写分离，hash $remote_addr仅能实现客户端ip绑定的读请求会话保持；真正读写分离需由应用层、数据库中间件（如proxysql）或七层代理完成。
四层负载均衡本身不支持数据库读写分离路由，hash $remote_addr 也不能实现“读走从库、写走主库”这种基于 SQL 语义的分发逻辑。
这是关键前提：四层（TCP/UDP 层）只看 IP 和端口，不解析 SQL 内容。它无法识别 SELECT 还是 INSERT，因此天然不具备读写分离能力。
但你可以用 hash $remote_addr 实现读请求的会话保持（sticky read）——即同一个客户端 IP 的所有 TCP 连接始终转发到同一台从库，避免因主从延迟导致的查询结果不一致。这属于读负载均衡的优化手段，不是读写分离本身。
下面分两部分说明：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
四层负载均衡中 hash $remote_addr 的作用与配置
- 它对客户端源 IP 做一致性哈希，确保同一 IP 的连接长期落在同一后端节点上。
- 适用于长连接、需要会话粘性的场景（如 SSH 跳板、MySQL 只读连接池）。
- 不解决写请求路由问题，写请求仍需单独入口或由应用层/中间件处理。
示例配置（Nginx stream 模块）：
stream {
upstream mysql_read {
hash $remote_addr consistent;
server 192.168.1.10:3306; # 从库1
server 192.168.1.11:3306; # 从库2
server 192.168.1.12:3306; # 从库3
}
upstream mysql_write {
# 写库通常只配一个（主库），也可用 least_conn 或轮询（多主架构）
server 192.168.1.20:3306; # 主库
}
server {
listen 3307; # 读请求入口端口
proxy_pass mysql_read;
proxy_timeout 30s;
}
server {
listen 3306; # 写请求入口端口（或用不同 VIP）
proxy_pass mysql_write;
proxy_timeout 30s;
}
}
✅ 客户端连接
mysql -h lb_ip -P 3307→ 自动落到固定从库（IP 绑定）
✅ 客户端连接mysql -h lb_ip -P 3306→ 总是打向主库
❌ 不能让一个端口自动判断SELECT/UPDATE并分流
真正实现读写分离的推荐方式
| 方式 | 原理 | 是否依赖四层 | 备注 |
|---|---|---|---|
| 应用层路由 | 应用代码中区分数据源：写用 writeDataSource，读用 readDataSource
|
否 | 最灵活、零额外组件，但需开发配合 |
| 数据库中间件（如 MaxScale、ProxySQL、ShardingSphere-Proxy） | 解析 MySQL 协议，识别 SQL 类型，按规则路由 | 否（部署在四层之上） | 支持自动读写分离 + 负载均衡 + 故障转移，生产首选 |
七层代理（如 HAProxy 的 mysql-check + ACL） |
仅能做健康检查和端口级分发，仍无法识别 SQL | 否 | 实际仍是四层转发，ACL 对 MySQL 协议无效 |
⚠️ 注意：HAProxy 或 Nginx 的四层模块都不支持 SQL 解析。所谓 “HAProxy 读写分离” 都是靠人为约定端口或 VIP（如
3306→主库，3307→从库集群），而非自动识别语句。
小结
-
hash $remote_addr在四层中只能做客户端 IP 绑定的读负载均衡，提升从库缓存命中率和降低主从切换时的查询抖动。 - 读写分离必须由更上层（应用、中间件或协议解析代理）完成。
- 若你已用 Nginx 四层作入口，建议将其作为第一道流量入口网关（负责高可用、端口收敛、连接限速），再把读请求转发给 ProxySQL 或 MaxScale 这类真正支持 SQL 路由的中间件。
不复杂但容易忽略：四层是“管道”，七层/中间件才是“交通指挥员”。
