负载均衡模型
一、问题引入
如果有多个用户来访问服务器,要想要减轻服务器的压力,应该怎么办呢?
-
首先想到的方法就是用多个服务器来分担
问题:两台计算机通信最终是通过ip,如果客户端连接多台服务器,服务器这里是不能够都配相同的ip地址了(IP冲突),因为这里如果进行三次握手的话也乱了
-
使用一台服务器,客户端请求它,该服务器再将请求转给另外的几台服务器,只要该服务器足够快就能够解决高并发的问题
问题:转发给的几台服务器解决慢
为什么tomcat慢,并发数少呢?
-
网络层上:
因为它是7层中的一层,自身就是应用层的,也是最末端的层次,所以通信上面不算最快的,而且想到应用的话传输控制层还要进行3次握手,然后才开辟应用层,CPU开辟资源等操作
-
开发语言,基于Java开发的,需要JVM
-
-
知道为什么服务器会慢,所以负载均衡的服务器就应该快速的发给服务端,就避免握手,就跟网线一样
结论
要想解决高并发,从通信层次我们要避免握手连接,客户端是直接与服务端进行握手的,并且传输控制层只是窥探了端口号,通过端口号来判定是否要将数据包转发给其他的服务器.
基于上述理论,所以我们应该得出这样的服务器,如下图所示.这里服务器是镜像的,对于客户端是不可见的,所以服务器所得到的效果应该是一样
二、基本负载均衡模型
-
语义
- CIP-客户端IP
- VIP-虚拟IP
- DIP-分发IP
- RIP-真实IP
-
特点
- 四层负载
- 数据包转发级别(特别快)
- 不会和client握手
- 后端服务器是镜像的(相同)
注意: 这里客户端会CIP->VIP,但是server1不会响应,因为它会检查目标地址是否是RIP,如果不是会丢包
三、NAT模型
模拟在家上网的网络模型(Network Address Translation，网络地址转换)-NAT模型,一般是在路由器,左边为内网地址,右边是公网地址
-
场景:
在家两个人同时访问百度,也就是1.8和1.6同时访问8.8.8.8, -
过程
访问过程路由器会随机申请一个端口号并记录内网的ip和端口号然后发给百度,这两个信息的唯一区分就是在端口号上,当请求之后的数据回来的时候在路由器上的表查询,替换对应的信息在返回,从而达到独立通信的目的(如果是替换的原地址,那么就是S-NAT,其中S是source源地址的意思)
四、D-NAT模型
D-NAT(Destination Network Address Translation):目的地址转换
-
特点
-
非对称
客户端发来的请求一般是很小的,但是服务端返回的数据很大,所以是非对称的
-
带宽
来回都经过负载均衡服务器,带宽成为瓶颈
-
消耗算力
请求出去和回来都有地址的转换,所以消耗算力
-
要求RS的GW指向负载均衡服务器
-
-
过程
CIP->VIP->负载均衡服务器->RIP->地址转换(RIP-CIP)->负载均衡服务器->CIP
-
场景
常用于防火墙中
五、DR模型
DR模式（直接路由模式:Virtual Server via Direct Routing）
-
特点
- 负载均衡服务器暴露VIP,服务器隐藏VIP
- 基于2层(链路,物理)
- mac地址欺骗
- 负载服务器和RS在一跳的距离(负载服务器要和RS在同一局域网)
- 直接返回给客户端,没走负载均衡服务器
-
过程
CIP->VIP->负载均衡服务器(发送的时候拼接RIP的mac地址)->RIP->地址反转(通过隐藏VIP)->CIP
六、TUN模式
TUN 是IP Tunneling ，IP隧道的简称，它将调度器收到的IP数据包封装在一个新的IP数据包中，转交给应用服务器，然后实际服务器的返回数据会直接返回给用户
-
特点
- 解决了DR(负载服务器要和RS在同一局域网)和D-NAT模式(网关指向均衡负载服务器)的缺点
- 拼接IP数据包,速度极快
-
过程
CIP->VIP->负载均衡服务器(拼接DIP->RIP数据包)->RIP->解开数据包然后进行地址转换(CIP->VIP通过隐藏VIP)->VIP
-
VPN&*