负载均衡服务器有什么优缺点？

随着网站、应用访问量的增加，一台服务器租用已经不能满足应用的需求，而需要多台服务器集群，这时就会用到负载均衡，那么负载均衡优点有那些呢，壹基比小喻来说说

负载均衡设备优势

• 负载均衡优化了访问请求在服务器组之间的分配，消除了服务器之间的负载不平衡，从而提高了系统的反应速度与总体性能；

• 负载均衡可以对服务器的运行状况进行监控，及时发现运行异常的服务器，并将访问请求转移到其它可以正常工作的服务器上，从而提高服务器组的可靠性采用了负均衡器器以后，可以根据业务量的发展情况灵活增加服务器，系统的扩展能力得到提高，同时简化了管理。

负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。

一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。当Web服务器为图像服务、SSL（安全套接层）会话或数据库事务而进行优化时，负载均衡器可以体现特别的价值。

当需要进行服务器升级或系统维护时，保证稳定的服务器退出服务以避免服务中断。当选定某台服务器要退出服务后，将不会将任何新的用户分配到该服务器。但是，它可以要该服务器完成对当前用户的服务。从而保证了无中断的优质服务，并且简化了服务器群的管理。

智能的服务器服务恢复

将重新启动的服务器应用到服务中时，避免新服务器因突然出现的流量冲击导致系统故障是非常重要的。所以，在将新服务器引入服务器群时，将逐渐地增加分配到该服务器的流量，直至达到其完全的处理能力。从而不仅保证用户在服务器退出服务时，同时还保证服务器在启动期间以及应用程序开始时，均能获得不间断服务。

随着用户访问的增多，一个应用服务器不能满足需求了，就需要部署多台应用服务器，通过负载均衡，将数据分发到不同的应用服务器。

从作用来看，和缓存集群的分发很相似，但是有不同。缓存需要发送到特定的服务器。但是，由于应用服务器是无状态的，因此，负载均衡不用根据请求分发到特定服务器，发送到哪个应用服务器都可以。

因此，负载均衡关注的技术焦点有两个，分别是：网络通信、路由选择

网络通信分为以下几种方法。

负载均衡服务器什么都不做，重定向响应

这种方法优点是简单，但是缺点也很明显：

由于这些问题，这种方法，在现实中几乎没有人使用。

每次请求DNS解析到IP地址不同，从而访问到不同到应用服务器。

这种方法，性能方面没有问题，虽然，还是2次http请求，但是不是每一次请求都需要域名解析，一次解析，ip就会记录到本地。下次，直接访问记录的ip。因此，性能无问题。

但是，由于域名解析服务器解析出的ip，如果出错，不会很快更新，且用户已经本地存储了ip也不会很快改变。因此，采用这种方案时，需要两级负载均衡。若应用服务器出错，在第二层负载均衡去掉。

对于安全性，现实使用时，该方法主要适用于两层负载均衡的情况，DNS负载均衡用于第一层负载均衡，解析出来的是第二层负载均衡服务器，因此，脆弱的服务器还是可以在内网中。淘宝、百度，不同时间ping，返回地址不同，意味着都是用了DNS负载均衡。

在应用层进行负载均衡，收到请求时，将请求转发到内网，再将收到的内网响应，返回给用户。

nagix本身的反向代理服务器，就有该功能。一般应用服务器是几十台，这种模式够用，再多一些，会不够用。因此，大一些的网站不会使用。

因为用的http请求协议，http比较重（比tcp的包重）。对反向代理服务器压力很大，其通过应用程序级别的线/进程才能完成分发，还要等应用服务器返回，因此，会有性能瓶颈。即使负载均衡做集群效率也低，因为后面的应用服务器有限。

因此，可以应用的规模很有限。

负载均衡服务器，和反向代理负载均衡原理相同，但是是在tcp层，修改包中源地址和目标地址，并发送到内网，收到响应后，再修改目标地址和原地址，返回给用户。

因为，负载均衡服务器处理的是ip那一层包，因此，处理能力可以提高。

但是，这种方法，请求和响应都通过了负载均衡，尤其是响应一般比较大。响应出口网络带宽会成为瓶颈。

数据链路层负载均衡，IP地址不变，只修改网卡MAC地址。应用服务器和负载均衡服务器共享一个虚拟ip。因为ip没有被修改过，tcp/ip协议还是通的，可以通过校验。又由于目的地址的mac地址改变了，因此，处理响应不用再经过负载均衡服务器。

大型互联网应用主要使用的负载均衡方案，也称为负载均衡的三角模式。

轮询

....

该方案已经被淘汰的。

通过session复制的方式，集群规模会受限制，复制不过来。做集群就是因为用户请求多，请求多，session也多，如果每个都有所有的session，对服务器压力很大。

来自相同的ip，总是到同一个应用服务器。这种方法也很快就淘汰了。

因为，会话需要会话关闭，如果因为发布程序，kill进程，session丢失。系统的可用性会下降。

发请求时，带cookie发送服务器，session记录的cookie中，返回给浏览器。任何一台服务器可以重cookie里得到session。

缺点：cookie变大，网络开销有影响。且有些浏览器禁用cookie，不好用。

早期使用的这个方案。缺点明显，但是生命力强。

对服务器架构要求很低。

---