Nginx 面对 100 万并发，是怎么把请求分给服务器的？
如果说服务器是干活的“码农”，那么 负载均衡器 (Load Balancer) 就是分派任务的“项目经理”。
它的核心职责只有一条：把涌进来的海量请求，合理地分配给后端的服务器集群，防止“闲的闲死，忙的忙死”。
但是，到底该怎么分？是轮流分？还是谁强给谁？还是随机瞎分？这就涉及到了经典的 负载均衡算法。
💻 一、技术分析：五大经典算法
我们假设有 3 台服务器：Server A、Server B、Server C。
1. 轮询法 (Round Robin) —— “雨露均沾”
-
原理: 按照顺序，一人一个。
-
请求 1 -> A
-
请求 2 -> B
-
请求 3 -> C
-
请求 4 -> A …
-
优点: 简单，绝对公平。
-
缺点: 它假设所有服务器性能一样。如果 A 是 64 核超跑，C 是 1 核老爷车，一人一个会导致 C 累死，A 还在看戏。
2. 加权轮询法 (Weighted Round Robin) —— “能者多劳”
-
原理: 给服务器配置权重。性能好的权重高，分到的多。
-
配置：A(5), B(1), C(1)。
-
结果：每 7 个请求里，A 处理 5 个，B 和 C 各处理 1 个。
-
场景: Nginx 默认常用。适合服务器配置新旧混搭的情况。
3. 随机法 (Random) —— “看天吃饭”
- 原理: 生成一个随机数，指哪打哪。
- 特点: 在请求量非常大的时候，随机法的效果约等于轮询法（大数定律）。
- 场景: 某些简单的消息队列消费场景。
4. 最小连接数法 (Least Connections) —— “谁闲给谁”
- 原理: 负载均衡器会实时记录每台服务器当前正在处理的连接数。新请求来了，直接给当前连接数最少的那台。
- 优点: 最智能。它能感知服务器的真实负载（比如 A 虽然配置高，但正好在处理一个耗时的大任务，就不给它派新活了）。
- 缺点: 算法复杂度高，需要维护状态。
5. 源地址哈希 (IP Hash) —— “认准死理”
-
原理: 对客户端的 IP 地址算一个 Hash 值，然后对服务器数量取模。
-
Hash(IP) % 3 -
只要 IP 不变，算出来的结果永远一样。
-
优点: 会话保持 (Sticky Session)。张三第一次访问在 A 登录了，Session 在 A 上；下次张三再来，还能分到 A，保证登录不失效。
-
缺点: 如果 A 挂了，张三的会话就丢了。（现在通常用 Redis 存 Session，所以这个算法用得少了）。
💍 二、进阶必考：一致性哈希 (Consistent Hashing)
这是面试中的终极加分项，专门用于 分布式缓存 (Redis Cluster) 和 RPC 负载均衡。
-
普通 Hash 的问题:
-
你有 10 台 Redis，用
Hash(Key) % 10。 -
如果加了一台变成 11 台。
-
灾难: 所有 Key 的取模结果全变了 (
% 10变成% 11)。所有的缓存瞬间失效（缓存雪崩），数据库直接被击穿。 -
一致性 Hash 的解法:
-
哈希环: 把 0 到 2^32-1 的数字连成一个圆环。
-
落点: 把服务器 Hash 后放在环上。把数据 Key Hash 后也放在环上。
-
寻找: 数据顺时针旋转，遇到的第一个服务器就是它的归宿。
-
优势: 增加或减少一台服务器，只影响环上那一小段的数据，其他数据不受影响。
🏦 三、故事场景：银行大厅的“叫号机”
我们将 负载均衡 比作 银行大厅的叫号系统。
- 客户: 请求 (Request)。
- 柜员: 服务器 (Server)。
- 叫号机/大堂经理: 负载均衡器 (Nginx/LVS)。
1. 轮询 (Round Robin)
大堂经理是个机器人，不管柜员是谁，机械地分配：
“1号去1号窗，2号去2号窗，3号去3号窗……”
- Bug: 2 号窗是实习生，动作慢；1 号窗是老员工，动作快。结果 1 号窗早没事干了，2 号窗排起长队。
2. 加权轮询 (Weighted)
大堂经理变聪明了，知道 1 号窗是王牌柜员（权重 5），2 号窗是实习生（权重 1）。
“来 6 个人！前 5 个都去 1 号窗，第 6 个去 2 号窗。”
- Result: 大家都挺忙，效率最高。
3. 最小连接数 (Least Connections)
大堂经理实时盯着每个窗口的排队情况。
“诶，3 号窗现在没人排队？下一个客户直接去 3 号窗！”
- Result: 最灵活，不论柜员能力如何，只看眼前忙不忙。
4. IP Hash
大堂经理认脸。
“哎？你不是刚才来过的张三吗？你刚才在 1 号窗办的业务，资料都在 1 号窗，你还是去 1 号窗吧。”
- Result: 方便连续办理业务。
