PHP本身不提供负载均衡能力，所谓“PHP负载均衡”实为误称，需借助Nginx、HAProxy等外部组件构建分布式架构；手动用curl转发会引发阻塞、无健康检查、session丢失等问题；应从Nginx upstream配置起步，重视权重、健康探测与header透传；session共享需结合Redis或数据库统一管理，并审视所有本地状态；客户端负载均衡仅适用于PHP主动调用其他服务的微服务场景。
PHP 本身不提供负载均衡能力，所谓“PHP 负载均衡”是误称——你学的不是 PHP 怎么做负载均衡，而是怎么用 PHP 配合外部组件（如 Nginx、HAProxy、Consul）构建可伸缩的分布式架构。
别在 PHP 里写 curl 转发逻辑
有人想用 curl 或 stream_socket_client 在 PHP 中手动转发请求，这会立刻掉进几个坑：
- 阻塞式 I/O：一个后端响应慢，整个 PHP-FPM 进程卡住，
max_children很快耗尽 - 无健康检查：
curl_exec失败后不会自动剔除宕机节点，下次请求照样打过去 - Session 丢失：默认
session.save_handler = files，用户登录后刷新可能跳到另一台机器，直接登出 - 超时/重试/限流全得自己补，且难以统一控制
这不是“学负载均衡”，是在重复造轮子，还造得不安全。真要练手，也只适合本地模拟，绝不能上生产。
从 Nginx upstream 开始配真实流量分发
这是绝大多数 PHP 应用起步最稳、文档最全、调试最直观的方式。重点不是背参数，而是理解每个配置项的实际影响：
立即学习“PHP免费学习笔记（深入）”；
-
least_conn：适合长连接或响应时间差异大的后端；ip_hash能保 session，但 NAT 下失效，不推荐作为主方案 -
weight=3和max_fails=2 fail_timeout=30s必须一起用，否则权重再高，节点挂了还在持续发请求 -
keepalive 32对接 PHP-FPM 时有用，但若后端是 Apache/PHP（非 FPM），proxy_pass必须指向http://...，不是fastcgi://或:9000 - 务必加
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for，否则$_SERVER['REMOTE_ADDR']全是 Nginx 内网 IP
验证是否生效？在每个后端 PHP 入口加一行：header('X-Backend-ID: server-01');，然后用 curl -I 看响应头变化。
Session 共享不是“选一个配置”，而是状态治理起点
负载均衡之后，第一个崩的就是登录态。改 php.ini 是最表层动作，真正要理清的是：
- Redis 方案要确认
session.save_path是否带tcp://前缀（PHP 8.0+ 默认要求），且 Redis 实例必须所有 PHP 服务器都能连通 - 如果用数据库存 session，注意
session.gc_maxlifetime和表中expires字段类型要匹配（INT vs DATETIME），否则 GC 不触发 -
ip_hash看似省事，但 CDN、企业出口 NAT 会让多个用户共用一个REMOTE_ADDR，导致 session 混乱
别只盯着 session，缓存（如 apcu）、上传临时目录、日志路径、定时任务（cron）——所有有本地状态的地方，都得重新评估。
客户端负载均衡只在微服务场景下有意义
如果你的 PHP 服务本身要主动调用其他内部服务（比如调 user-service 或 payment-api），才需要考虑客户端侧的负载策略：
- DNS 服务发现简单，但
dns_get_record()结果受 TTL 和 PHP 进程内缓存影响，更新延迟可能达分钟级 - 用 Consul 或 Etcd 需引入 HTTP 客户端（如 Guzzle），每次请求前查一次服务列表，性能开销明显，建议加本地缓存 + TTL
- 轮询/随机/最小连接这些策略，写法不难，但关键在失败后能否快速熔断、降级、重试——
try/catch包一层远远不够
这时候你学的已不是 PHP 语法，而是服务治理意识：节点注册、心跳上报、健康阈值、故障转移链路。PHP 只是执行载体，逻辑在架构里。
