Nginx基础教程（49）Nginx HTTP请求转发之负载均衡机制：Nginx负载均衡：如何让一群服务器完美“打工”不抱怨

这可能是服务器们最想点赞的协作指南

引言：当一个“包工头”有多爽？

想象一下，你开了一家超火爆的网红餐厅，突然涌来100个饿疯的食客，而你只有一个厨师。结果怎么样？厨师累瘫，食客砸店，你破产。

但如果你有三个厨师，并且有个聪明领班在门口安排客人去不同的厨房呢？这就是负载均衡的本质！Nginx就是这个世界上最聪明的“餐厅领班”，它能让你的多个服务器高效协同工作，谁累了就让谁休息，谁闲着了就给它多派活。

在今天的互联网世界里，高并发早已不是新鲜话题。据不完全统计，一个中型电商网站在促销时段每秒需要处理上千个请求，单台服务器哪怕性能再强，也难免捉襟见肘。Nginx的负载均衡功能就像是服务器的“包工头”，它自己不干重活，却懂得如何把任务合理分配给下面的“工人”——那些真正处理请求的后端服务器。

那么，这个“包工头”究竟是如何工作的呢？让我们一起揭开它的神秘面纱！

第一章：Nginx为何能成为“包工头”中的战斗机？

1.1 强悍的内心：多进程+异步非阻塞模型

Nginx之所以能高效处理海量请求，全得益于其独特的架构设计。它与传统服务器不同，采用了一种多进程+异步非阻塞方式（也就是IO多路复用epoll）。

正常运行的Nginx服务包含两种进程：

• Master进程：如同公司的总经理，只负责管理，不直接处理客户请求。它的任务是管理下面的Worker进程，监控它们的运行状态，如果发现哪个Worker进程异常终止，就会立刻重启它。
• Worker进程：如同公司的一线员工，实际处理网络请求。所有Worker进程都是平等的，而且数量通常设置为与服务器CPU核心数相同，这样可以充分利用CPU资源，同时避免进程过多导致竞争和切换损耗。

这种设计的好处是什么呢？当一个Worker进程因为I/O操作而阻塞时，其他Worker进程可以继续处理新的请求，不会出现“一个卡死，全家遭殃”的尴尬局面。

1.2 请求处理的“潜规则”

那么，当HTTP请求到达Nginx时，具体是怎样被处理的呢？

1. 建立连接：Worker进程竞争新的连接，获胜者通过三次握手建立Socket连接。
2. 读取请求：逐行读取请求行和请求头，判断有请求体后读取请求体。
3. 处理请求：根据配置和请求内容进行处理。
4. 响应请求：根据处理结果，生成相应的HTTP响应（包括响应行、响应头和响应体）。

有趣的是，请求的完整过程在底层其实就是读写Socket事件，而Nginx的事件处理模型能够高效地管理这些事件，确保高并发下的稳定性。

第二章：揭秘Nginx负载均衡的“调度算法”

2.1 轮询：像发牌一样的公平分配

轮询是Nginx负载均衡的默认算法，也是最基本的分配方式。它的工作方式就像打扑克时发牌一样，依次将请求分发给后端服务器，循环往复。

假设你有三台后端服务器，Nginx会这样分配请求：

• 第一次请求 → 服务器1
• 第二次请求 → 服务器2
• 第三次请求 → 服务器3
• 第四次请求 → 服务器1
• 第五次请求 → 服务器2
• ……（如此循环）

这种方式保证了每个服务器都能得到大致相等数量的请求，适合后端服务器性能相近的场景。配置简单明了：

upstream backend {
    server backend