mirror of
https://github.com/CyC2018/Interview-Notebook.git
synced 2026-11-01 03:23:42 +00:00
Update 集群.md
补充平滑加权轮询实现与 Nginx upstream 配置示例，调整 LVS DR 模式说明；新增 NAT/DR 对比配图并重新绘制部分算法配图。
This commit is contained in:
CyC2018
Binary file not shown.
|
Before Width: | Height: | Size: 120 KiB After Width: | Height: | Size: 120 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 261 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 103 KiB After Width: | Height: | Size: 108 KiB |
+75
-21
@@ -8,7 +8,7 @@
|
||||
* [3. 最少连接（Least Connections）](#3-最少连接least-connections)
|
||||
* [4. 加权最少连接（Weighted Least Connection）](#4-加权最少连接weighted-least-connection)
|
||||
* [5. 随机算法（Random）](#5-随机算法random)
|
||||
* [6. 源地址哈希法 (IP Hash)](#6-源地址哈希法-ip-hash)
|
||||
* [6. 源地址哈希法（IP Hash）](#6-源地址哈希法ip-hash)
|
||||
* [转发实现](#转发实现)
|
||||
* [1. HTTP 重定向](#1-http-重定向)
|
||||
* [2. DNS 域名解析](#2-dns-域名解析)
|
||||
@@ -20,6 +20,7 @@
|
||||
* [Session Replication](#session-replication)
|
||||
* [Session Server](#session-server)
|
||||
* [客户端保存](#客户端保存)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
@@ -27,7 +28,7 @@
|
||||
|
||||
集群中的应用服务器（节点）通常被设计成无状态，用户可以请求任何一个节点。
|
||||
|
||||
负载均衡器会根据集群中每个节点的负载情况，将用户请求转发到合适的节点上。
|
||||
负载均衡器按一定的算法把用户请求转发到集群中合适的节点上。
|
||||
|
||||
负载均衡器可以用来实现高可用以及伸缩性：
|
||||
|
||||
@@ -41,6 +42,8 @@
|
||||
|
||||
### 负载均衡算法
|
||||
|
||||
轮询、加权轮询、随机和哈希只按事先配置的规则分配，属于静态算法；最少连接和加权最少连接按实时的连接数选择，属于动态算法。
|
||||
|
||||
#### 1. 轮询（Round Robin）
|
||||
|
||||
轮询算法把每个请求轮流发送到每个服务器上。
|
||||
@@ -50,7 +53,7 @@
|
||||
<div align="center"> <img src="pics/lb-round-robin.png" width="640px"/> </div><br>
|
||||
|
||||
|
||||
该算法比较适合每个服务器的性能差不多的场景，如果有性能存在差异的情况下，那么性能较差的服务器可能无法承担过大的负载（下图的 Server 2）。
|
||||
该算法比较适合每个服务器的性能差不多的场景。如果服务器的性能存在差异，性能较差的服务器可能无法承担过大的负载（下图的 Server 2）。
|
||||
|
||||
<div align="center"> <img src="pics/lb-round-robin-weak.png" width="640px"/> </div><br>
|
||||
|
||||
@@ -62,13 +65,45 @@
|
||||
|
||||
<div align="center"> <img src="pics/lb-weighted-round-robin.png" width="640px"/> </div><br>
|
||||
|
||||
实际实现（例如 Nginx 的平滑加权轮询）会把请求交错发送，避免连续的请求集中到同一台服务器上，上图最后一行是按 Nginx 源码中的算法计算出的顺序。
|
||||
实际实现（例如 Nginx 的平滑加权轮询）会把请求交错发送，避免连续的请求集中到同一台服务器上。它为每台服务器维护一个当前权重：每个请求到来时，各服务器的当前权重先加上自己的权值，选出最大的一台（相等时选前一台），再把它的当前权重减去权值之和 6。上图最后一行按下表算出：
|
||||
|
||||
```text
|
||||
请求 加上权值后 (S1, S2) 选中 减去 6 后 (S1, S2)
|
||||
1 (5, 1) S1 (-1, 1)
|
||||
2 (4, 2) S1 (-2, 2)
|
||||
3 (3, 3) S1 (-3, 3)
|
||||
4 (2, 4) S2 (2, -2)
|
||||
5 (7, -1) S1 (1, -1)
|
||||
6 (6, 0) S1 (0, 0)
|
||||
```
|
||||
|
||||
6 个请求后当前权重回到 (0, 0)，之后按同样的顺序循环。用 Java 实现如下：
|
||||
|
||||
```java
|
||||
class Server {
|
||||
final String host;
|
||||
final int weight;
|
||||
int current; // 当前权重，初始为 0
|
||||
Server(String host, int weight) { this.host = host; this.weight = weight; }
|
||||
}
|
||||
|
||||
// total 是所有服务器的权值之和
|
||||
synchronized String getHost(List<Server> servers, int total) {
|
||||
Server best = null;
|
||||
for (Server s : servers) {
|
||||
s.current += s.weight;
|
||||
if (best == null || s.current > best.current) best = s;
|
||||
}
|
||||
best.current -= total;
|
||||
return best.host;
|
||||
}
|
||||
```
|
||||
|
||||
#### 3. 最少连接（Least Connections）
|
||||
|
||||
由于每个请求的连接时间不一样，使用轮询或者加权轮询算法的话，可能会让一台服务器当前连接数过大，而另一台服务器的连接过小，造成负载不均衡。
|
||||
|
||||
例如下图中，(1, 3, 5) 请求会被发送到服务器 1，但是 (1, 3) 很快就断开连接，此时只有 (5) 请求连接服务器 1；(2, 4, 6) 请求被发送到服务器 2，只有 (2) 的连接断开，此时 (6, 4) 请求连接服务器 2。该系统继续运行时，服务器 2 会承担过大的负载。
|
||||
例如下图中，轮询把请求 1、3、5 发给服务器 1，把请求 2、4、6 发给服务器 2。请求 1、3 很快就断开连接，请求 6 到达时服务器 1 只有 1 个连接，服务器 2 还有 2 个，轮询仍然把它发给服务器 2。该系统继续运行时，服务器 2 会承担过大的负载。
|
||||
|
||||
<div align="center"> <img src="pics/lb-least-conn-problem.png" width="640px"/> </div><br>
|
||||
|
||||
@@ -80,7 +115,7 @@
|
||||
|
||||
#### 4. 加权最少连接（Weighted Least Connection）
|
||||
|
||||
在最少连接的基础上，根据服务器的性能为每台服务器分配权重，将请求发送给“当前连接数 / 权重”最小的服务器。
|
||||
在最少连接的基础上，根据服务器的性能为每台服务器分配权重，将请求发送给“当前连接数 / 权重”最小的服务器。例如服务器 1 的权重为 3、有 6 个连接，服务器 2 的权重为 1、有 3 个连接，6 / 3 = 2 小于 3 / 1 = 3，新请求发给连接更多的服务器 1。
|
||||
|
||||
#### 5. 随机算法（Random）
|
||||
|
||||
@@ -90,7 +125,7 @@
|
||||
|
||||
<div align="center"> <img src="pics/lb-random.png" width="640px"/> </div><br>
|
||||
|
||||
#### 6. 源地址哈希法 (IP Hash)
|
||||
#### 6. 源地址哈希法（IP Hash）
|
||||
|
||||
源地址哈希通过对客户端 IP 计算哈希值之后，再对服务器数量取模得到目标服务器的序号。
|
||||
|
||||
@@ -98,7 +133,7 @@
|
||||
|
||||
<div align="center"> <img src="pics/lb-ip-hash.png" width="640px"/> </div><br>
|
||||
|
||||
缺点是同一出口 IP 后面的大量用户会落到同一台服务器上，造成负载不均；服务器数量变化时大部分客户端的取模结果都会改变，可以改用一致性哈希。需要注意的是，Nginx 的 ip_hash 只用 IPv4 地址的前 3 个字节计算哈希，同一个 /24 网段的客户端都会落到同一台服务器上。
|
||||
缺点是同一出口 IP 后面的大量用户会落到同一台服务器上，造成负载不均；服务器数量变化时大部分客户端的取模结果都会改变，可以改用[一致性哈希](缓存.md#六一致性哈希)。需要注意的是，Nginx 的 ip_hash 只用 IPv4 地址的前 3 个字节计算哈希，同一个 /24 网段的客户端都会落到同一台服务器上。
|
||||
|
||||
### 转发实现
|
||||
|
||||
@@ -139,6 +174,25 @@ HTTP 重定向负载均衡服务器使用某种负载均衡算法计算得到服
|
||||
|
||||
反向代理工作在应用层，属于七层负载均衡，可以根据 URL、Cookie 等内容进行转发，常用的有 Nginx、HAProxy。
|
||||
|
||||
例如 Nginx 用 upstream 定义一组服务器，默认按加权轮询分配，开头写 least_conn、ip_hash 或 hash $request_uri consistent 可以改为加权最少连接、源地址哈希或按 URL 的一致性哈希：
|
||||
|
||||
```nginx
|
||||
upstream order_service {
|
||||
least_conn; # 不写时为加权轮询
|
||||
server 10.0.0.11:8080 weight=5;
|
||||
server 10.0.0.12:8080 weight=1 max_fails=3 fail_timeout=30s;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
location /api/ {
|
||||
proxy_pass http://order_service;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
开源版 Nginx 不主动探测后端，只在转发失败时计数：fail_timeout 内失败 max_fails 次（默认 1 次、10 秒），之后的 fail_timeout 内不再向它转发。微服务之间的调用一般不经过 Nginx，由调用方从注册中心取得实例列表后自己选择，见[微服务的负载均衡策略](微服务.md#负载均衡策略)。
|
||||
|
||||
优点：
|
||||
|
||||
- 与其它功能集成在一起，部署简单。
|
||||
@@ -155,7 +209,7 @@ HTTP 重定向负载均衡服务器使用某种负载均衡算法计算得到服
|
||||
|
||||
优点：
|
||||
|
||||
- 在内核进程中进行处理，性能比较高。
|
||||
- 在内核中进行处理，性能比较高。
|
||||
|
||||
缺点：
|
||||
|
||||
@@ -165,18 +219,13 @@ HTTP 重定向负载均衡服务器使用某种负载均衡算法计算得到服
|
||||
|
||||
在链路层根据负载均衡算法计算源服务器的 MAC 地址，并修改请求数据包的目的 MAC 地址，并进行转发。
|
||||
|
||||
通过配置源服务器的虚拟 IP 地址和负载均衡服务器的 IP 地址一致，从而不需要修改 IP 地址就可以进行转发。也正因为 IP 地址一样，所以源服务器的响应不需要转发回负载均衡服务器，可以直接转发给客户端，避免了负载均衡服务器成为瓶颈。
|
||||
负载均衡服务器和源服务器配置同一个虚拟 IP（VIP），源服务器把它配置在回环等不响应 ARP 的接口上，从而不需要修改 IP 地址就可以进行转发。也正因为 IP 地址一样，所以源服务器的响应不需要转发回负载均衡服务器，可以直接转发给客户端，避免了负载均衡服务器成为瓶颈。
|
||||
|
||||
这是一种三角传输模式，被称为直接路由，对应 LVS 的 DR 模式，要求源服务器和负载均衡服务器位于同一个局域网内。对于提供下载和视频服务的网站来说，直接路由避免了大量的网络传输数据经过负载均衡服务器。
|
||||
这是一种三角传输模式，被称为直接路由，对应 LVS 的 DR 模式，要求源服务器和负载均衡服务器位于同一个局域网内，因为只改了 MAC 地址的帧无法经过路由器转发。对于提供下载和视频服务的网站来说，直接路由避免了大量的网络传输数据经过负载均衡服务器。
|
||||
|
||||
网络层和链路层的方式不解析应用层协议，属于四层负载均衡。链路层负载均衡的响应不经过负载均衡服务器，性能很好，在 Linux 平台可以使用的负载均衡服务器为 LVS（Linux Virtual Server），通常用 LVS 做四层负载均衡，再用 Nginx 做七层负载均衡。
|
||||
<div align="center"> <img src="pics/lb-nat-dr.png" width="760px"/> </div><br>
|
||||
|
||||
参考：
|
||||
|
||||
- [Comparing Load Balancing Algorithms](http://www.jscape.com/blog/load-balancing-algorithms)
|
||||
- [Nginx: ngx_http_upstream_module](https://nginx.org/en/docs/http/ngx_http_upstream_module.html)
|
||||
- [Nginx 源码：ngx_http_upstream_round_robin.c](https://github.com/nginx/nginx/blob/master/src/http/ngx_http_upstream_round_robin.c)
|
||||
- [Redirection and Load Balancing](https://web.archive.org/web/20250420002753/http://slideplayer.com/slide/6599069/)
|
||||
网络层和链路层的方式不解析应用层协议，属于四层负载均衡：它只看 IP 和端口，同一个 TCP 连接的包都转发给同一台服务器，开销小；七层负载均衡要先和客户端建立 TCP 连接、解析出 HTTP 请求才能选择服务器，开销更大。链路层负载均衡的响应不经过负载均衡服务器，性能很好，在 Linux 平台可以使用的负载均衡服务器为 LVS（Linux Virtual Server），通常用 LVS 做四层负载均衡，再用 Nginx 做七层负载均衡。
|
||||
|
||||
## 二、集群下的 Session 管理
|
||||
|
||||
@@ -223,13 +272,18 @@ HTTP 重定向负载均衡服务器使用某种负载均衡算法计算得到服
|
||||
|
||||
### 客户端保存
|
||||
|
||||
把用户信息签名后放在 Cookie 或者 JWT 中，由客户端保存，服务端只需要验证签名。
|
||||
把用户信息签名后放在 Cookie 或者 JWT 中，由客户端保存，服务端只需要验证签名和有效期。
|
||||
|
||||
缺点：
|
||||
|
||||
- 无法主动让某个会话失效。
|
||||
- 在过期之前无法主动让某个会话失效，需要服务端另外维护黑名单等状态，见 [JWT](HTTP.md#11-jwt)。
|
||||
|
||||
参考：
|
||||
## 参考资料
|
||||
|
||||
- [Comparing Load Balancing Algorithms](http://www.jscape.com/blog/load-balancing-algorithms)
|
||||
- [Nginx: ngx_http_upstream_module](https://nginx.org/en/docs/http/ngx_http_upstream_module.html)
|
||||
- [Nginx 源码：ngx_http_upstream_round_robin.c](https://github.com/nginx/nginx/blob/master/src/http/ngx_http_upstream_round_robin.c)
|
||||
- [Redirection and Load Balancing](https://web.archive.org/web/20250420002753/http://slideplayer.com/slide/6599069/)
|
||||
- [LVS: Virtual Server via Direct Routing](https://www.linuxvirtualserver.org/VS-DRouting.html)
|
||||
- [Session Management using Spring Session with JDBC DataStore](https://web.archive.org/web/20230602191402/https://www.sivalabs.in/2018/02/session-management-using-spring-session-jdbc-datastore/)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user