彻底搞懂负载均衡的原理及其常见方法

以你之姓@ 2021-11-29 07:10 85阅读 0赞

负载均衡（百度百科）定义：负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。（一脸懵逼的进来又一脸懵逼的出去）

以下是我查阅相关内容后的总结和理解：  
**1. 负载均衡的由来**  
了解计算机网网络的同学（不了解也没关系）都知道我们客户端和服务端通信（发送请求和接收相应）的时候，服务器需要建立 TCP 连接、解析请求、响应请求等。假设现在只有一台服务器，那么所有的这些操作都由该台服务器解决，如果通信量小倒还没啥事，正常处理就行，用户也不感受不到时延。但是，一旦通信量大的时候（比如晚高峰），由于要处理大量的请求和相应，服务器的 CUP、硬盘、内存都不堪重负，处理的速度越来越慢，这时用户就能明显感受到打开网页的速度变慢了，这对用户体验非常不好。解决这个问题有两种方式：1. 买更好的服务器（这叫纵向扩展，缺点：太贵） 2. 买几台便宜的服务器，把资源多部署几份（这叫横向扩展，这就叫负载均衡）。

**2. 具体实现**  
某公司在原来的一台服务器基础上又购买了三台服务器，原理图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70]  
蓝色的 LoadBalance （简称LB）具有两个IP，一个对外（IP1，用户访服务器时看到的 IP），一个对内（后面三个真实的服务器网关指向该IP）。接下来我们看一个真实的请求和响应如何实现的。  
首先用户发过来的数据报是封装过的，LB 对数据报进行解封，解析到网络层，如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70 1]  
可以看到该数据报的目的地就是咱们上面的 LB，但是这个时候 LB 对该 IP 数据报做了一些手脚，将目的地改成了 RS1 的IP地址：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70 2]  
然后这个数据报就交个 RS1 去处理了。等 RS1 处理完后将响应发送出去，由于 LB 是网关，会收到 RS1 发来的数据，这是 LB 又臭不要脸的对该数据报做了手脚，神不知鬼不觉将目的地又改成了自己的，让客户端以为都是他处理的。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70 3]  
我们总结一下该数据报的流向：**客户端 --> Load Balancer --> RS1 --> Load Balancer --> 客户端**  
当然，每次不一定都是RS1，因为有不止一个服务器，我们 LB 会均衡一下，具体怎么个均衡法？如下：

1.  轮询：一个个的轮换
2.  加权轮询：让好的服务器权重大些，选中的机会更大。
3.  最少链接：让链接最少的处理
4.  加权最少链接：加上权重  
    … …  
    上面的请求存在一个问题，就是客户端发送来的请求肯定会不止一个数据报，为了使同一个请求的所有数据报都流向同一个服务器，Load Balancer 必须得维护一个表，这个表需要记录下客户端的数据包被我们转发到了哪个真实的服务器上， 这样当下一个数据包到来时，我们就可以把它转发到同一个服务器上去。这个负载均衡软件需要是面向连接的，也就是OSI网络体系的第4层， 可以称为**四层负载均衡**。

从上面的负载均衡可以看出，虽然减轻了 Load Balance 的压力，但是大量请求和响应的时候其实它还是会不堪重负，最终降低用户体验。还有一种方法是将请求和响应分开处理。  
首先让所有的服务器都有同一个IP， 我们把他称为VIP吧（如图中115.39.19.22）。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70 4]  
把每个实际服务器的loopback都绑定了那个VIP，这样所有服务器的IP地址都是同一个了，当一个数据报过来的时候，它的帧是这样的：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70 5]  
现在知道目的地的地址是：115.39.19.22（VIP），并不知道具体该去哪一台服务器（？表示不知道MAC地址），这时就通过 ARP（地址解析协议）给所有服务器发送一个广播，只让 Load Balance 回复，其它不回复，这样就可以知道谁是 Load Balance 并将帧发送过去了，Load Balance 收到帧之后根据算法选择相应的服务器，服务器处理完请求就直接给客户端发送响应，因为它本身的 IP 地址就是客户端要访问的地址。Load Balancer只负责把用户请求发给特定的服务器就万事大吉了， 剩下的事由具体的服务器来处理。  
上面数据报的流向：**客户端 --> Load Balancer --> RS --> 客户端**

本文所描述的，其实就是著名开源软件LVS的原理，上面讲的两种负载均衡的方式，就是LVS的NAT和DR。  
所有内容来自：  
[用故事来给你讲负载均衡的原理][Link 1]  
[一篇文章彻底了解清楚什么是负载均衡][Link 2]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70]: /images/20211129/43e5d7ec0ef442a797380677889b12ad.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70 1]: /images/20211129/4d03ea3a9f0a49859a0f46b7f9de322f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70 2]: /images/20211129/eaf8958887b840e9a29d9916113bd276.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70 3]: /images/20211129/72fadad15e27470d92ce99eaa3d35e98.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70 4]: /images/20211129/27463ed359fc4c399240088bc5a27aff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjk4OTU3Ng_size_16_color_FFFFFF_t_70 5]: /images/20211129/ad6d75357a0241d7ac54974c411033a6.png
[Link 1]: https://baijiahao.baidu.com/s?id=1634386941492502616&wfr=spider&for=pc
[Link 2]: https://mp.weixin.qq.com/s?__biz=MzI3NzE0NjcwMg==&mid=2650121487&idx=1&sn=71086d1b4cf4231c6c1d0fcea5ab9ea0&chksm=f36bb82ec41c31387aef7ad7df1cf2a5a89f5f3d6d0505f4d2220f8dd792e4e59934dfde9124&mpshare=1&scene=1&srcid=0614WlRZiAw05dGZkuyGdmC6#rd