1）http重定向
HTTP重定向服务器就是一个普通的服务器，当用户访问时，其会根据一定的算法得到服务器集群的一个真实服务器的IP地址，将其放在HTTP响应头中，响应状态码为（302），当用户浏览器接收到这个响应时，会将得到的真实服务器的IP地址提出并重新访问。如上图所示，当用户访问域名时通过DNS解析得到114.100.20.200，然后访问114.100.20.200，也就是HTTP重定向服务器，响应重定向至114.100.20.203，用户浏览器再重新访问。
缺点:
1. 这种方式需要用户浏览器访问两次，性能较差
2. HTTP重定向服务器会的处理能力会成为负载均衡的瓶颈
3. HTTP重定向返回302，可能会使搜索引擎判定为SEO作弊，降低搜索排名
2）dns域名解析（DNS:通过域名获取ip地址的手段）
当我们通过域名访问网站时，需要通过DNS服务器得到服务器的IP地址，我们可以在DNS服务器上设置一定的算法，每次得到不同的IP地址来进行访问从而实现负载均衡
如图，当用户访问www.apusapp.com时，这个域名对应了多个IP地址，通过DNS服务器解析会得到一个IP地址（可以看到，得到的这个IP地址，是服务器集群中一个服务器的IP地址），用户访问这个IP地址来达到真实的服务。
优点：
将负载均衡的工作丢给了DNS服务器去做，省去了网站管理人员的维护工作
对于真实地址的服务器，不需要做任何的配置
简单易用，成本低，而且方便灵活
服务器可以放在任何的地方
同时，DNS服务还可以做基于地理位置的解析，可以让一个距离最近的服务器的IP地址放回，提高性能
缺点:
1.DNS服务是有多级的（之后有时间写一个详细的DNS服务介绍）
大致上来说，首先是在浏览器中有一个DNS缓存，如果找不到就在本机地址的hosts文件中查找，再找不到就去路由器缓存中查找。然后是本地DNS服务器，如果没有，就是根服务器，顶级服务器，权限域名服务器等等等
总之，在每一级都有可能缓存这DNS的对应关系，所以有可能当某一台真实服务器下线之后，修改了DNS服务器的记录，但在生效之前还有一段时间，在这段期间，其IP地址已经不可用了，通过域名进行访问时还是会访问到这个IP地址。会访问失败
2.DNS服务器和真实服务器是完全分开的，所以DNS的负载均衡不能监测到真是服务器当前的运行状态，其负载均衡的效果不是很好
3.可能会造成额外的网络问题。为了使本DNS服务器和其他DNS服务器及时交互，保证DNS数据及时更新，使地址能随机分配，一般都要将DNS的刷新时间设置的较小，但太小将会使DNS流量大增造成额外的网络问题。
事实上，大型网站都将DNS负载均衡作为第一级的负载均衡手段，在服务器内部再进行第二级的负载均衡，也就是说，我们通过DNS得到的IP地址并不是真实服务器的IP地址，而是内部负载均衡服务器的IP地址。
3）反向代理
代理与反向代理：VPN服务就是我们常用的一种代理（正向代理），用户将请教交给代理服务器，代理服务器访问网站获取数据，之后代理服务器再将数据返还给用户。在这个过程中，应用服务器并不知道用户的存在。只知道代理浏览器的访问。
反向代理是指在服务器端的代理，代理服务器接收用户的请求，再转发给真实服务器，之后再返回给代理服务器再给用户，在这个过程中，用户并不知道真实服务器的存在。
反向代理服务器管理了一组服务器，当用户访问时，代理服务器根据负载均衡算法将请求转发到真实服务器，真实服务器也通过反向代理服务器返还数据。内部服务器不对外部提供服务，所以不需要外部IP，而反向代理服务器需要两个网卡，一个IP用于外部用户访问使用，另外一个用于内部使用。
如上图所示，当用户发起访问，请求访问的ip地址是114.100.20.200，到达反向代理服务器时，根据负载均衡算法得到一个真实服务器的IP地址，并将用户请求转发到该服务器上，当真实服务器处理完之后将数据返回到反向代理服务器。反相代理服务器再将该响应的内容返回给用户。
优点：
反向代理服务器位于应用层，负载均衡方案和反向代理服务器集成在了一起，部署简单
缺点：
反向代理服务器用户处理所有的请求和响应，其性能可能成为服务器集群的瓶颈
有名Nginx就是反向代理服务
4）IP层负载均衡
IP包结构
其中，可能看到有源地址和目的地址两项，这两项就是用来做IP层的负载均衡的关键。我们就是通过修改这两个地址来达到“转发”目的
如上图所示，当用户发起请求时（源地址为200.110.50.1），访问负载均衡服务器（目的地址为114.100.20.200），负载均衡服务器在内核进程获取网路数据包，根据一定的算法得到一个真实服务器的IP地址，其后将IP数据包的目的地址修改为该IP地址（192.168.1.1），之后就会将数据包发送到该真实服务器上去，之后再向负载均衡服务器返回数据，负载均衡服务器将源地址修改为114.100.20.200后返回给用户浏览器。
这个方法的关键就是因为只能在负载均衡服务器出修改源地址和目的地址，所以在真实服务器处理完之后要想办法将数据返回给负载均衡服务器而不是用户浏览器。
比如，当用户发出请求时，目的地址是114.100.20.200，源地址是200.110.50.1，到达负载均衡服务器后，将目的地址该位192.168.1.1，源地址还是200.110.50.1，所以当真实服务器处理完之后的数据无法回到负载均衡服务器
解决方法：
提供两个网卡，负载均衡服务器就有内部IP和外部IP两个IP，当请求到达负载均衡服务器时，修改目的地址，也修改源地址，将源地址修改为负载均衡服务器的内部IP，这样的话，真实服务器处理后的响应就会再次回到负载均衡服务器
将负载均衡服务器作为真实服务器集群的网关服务器，这样的话所有的请求响应都要经过网关服务器
优点:
IP负载均衡在内核进程完成数据分发，处理性能得到了很好的提高。
缺点:
由于所有请求和响应都要经过负载均衡服务器，集群的最大响应数据吞吐量将受到负载均衡服务器网卡带宽的限制，对于提供下载服务或者视频服务等需要大量传输数据的站点而言，这是难以满足需求的
5）链路层的负载均衡
MAC地址：mac地址是与网卡相关，其编号只与网卡生产厂商和流水号有关，基本上可以作为每台电脑的“身份证”。以太网中数据帧之间是通过MAC寻址来到达对应的计算机网卡或者路由的
链路层的负载均衡通过修改帧数据包中的MAC地址来达到转发的目的。这种方法，所有的真实服务器和负载均衡服务器都有相同的IP地址，不用修改IP数据包的目的地址和源地址，只通过修改MAC地址就可以达到效果，因为请求的IP地址和实际处理的真实服务器的IP地址一致，所以不需要回到负载均衡服务器进行地址交换，可以将响应直接发会给用户浏览器，避免了负载均衡服务器成为传输瓶颈的可能
————————————————
版权声明：本文为CSDN博主「zm-技术共享」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/bpb_cx/java/article/details/82771168