least_conn 负载均衡怎么优化高并发下的锁竞争
在 nginx 中，`least_conn` 算法通过减少连接数来平衡负载，但在高并发下，其核心数据结构 `peers->lock` 会成为严重的锁竞争瓶颈。要优化这一竞争，最直接且有效的做法是启用 `zone` 共享内存模式，将原本每个 worker 进程独立维护的 peer 状态改为多进程共享，从而利用原子操作替代互斥锁进行计数更新。
为什么共享内存能解决锁竞争
默认情况下，Nginx 的 upstream 模块为每个 worker 进程分配独立的内存空间。当使用 `least_conn` 时，每次请求都需要获取 `peers->lock` 来读取和修改当前连接数。在高并发场景下，成千上万的请求同时争抢这把全局锁，导致 CPU 大量时间消耗在上下文切换和锁等待上。引入 `zone` 后，peer 信息存储在共享内存中，Nginx 使用自旋锁（spinlock）或原子指令来更新连接计数，避免了内核级的互斥锁开销，显著提升了吞吐量。
upstream backend {
least_conn;
zone my_backend 64k;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
上述配置中，`zone my_backend 64k` 是关键。它告诉 Nginx 创建一个名为 `my_backend`、大小为 64KB 的共享内存区域。所有 worker 进程都访问这块内存中的 peer 列表。由于连接数的增减变成了对共享内存中特定字段的原子操作，锁的竞争粒度从“整个 peer 列表”缩小到了“单个 peer 的状态字段”，极大地减少了锁冲突的概率。
基于程序中某个输入、条件或结果的具体问题
在使用 `zone` 模式时，一个常见的具体问题是：如果共享内存大小设置过小，会导致什么后果？答案是会导致 peer 信息无法完整存储，进而引发配置加载失败或运行时错误。Nginx 在启动时会计算所需的最小共享内存大小，公式大致为：`peer_count * (sizeof(peer_data) + overhead)`。如果设置的 `64k` 不足以容纳所有后端服务器的状态信息，Nginx 会在启动时报错 `invalid number "peers" in /etc/nginx/nginx.conf:xx` 或类似内存不足的错误。
为了验证这一点，我们可以查看 Nginx 源码中 `ngx_http_upstream_init_zone` 函数的逻辑。该函数会遍历所有配置的 server，计算总大小。如果用户指定的 size 小于计算出的最小值，初始化就会失败。因此，在高并发且后端服务器数量较多的场景下，必须适当增大 `zone` 的大小，例如设置为 `256k` 或更大，以确保有足够的空间存储每个 peer 的连接数、权重等状态信息。这不仅是性能优化的关键，也是系统稳定运行的前提。
