负载均衡背景



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

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

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

网络通信（怎么分发过去？）

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

HTTP重定向负载均衡

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

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

每次请求，都需要2次http通信，延长了响应时间；

安全性问题：一般应用服务器只配置内网地址，脆弱的服务器可以在内网中保护起来，而负载均衡服务里面什么也没有，可以暴露到公网ip。

http重定向方法，会将应用服务器暴露到公网。

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

DNS负载均衡

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

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

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

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

反向代理负载均衡（7层负载均衡）



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

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

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

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



IP负载均衡（3层负载均衡）



image.png

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

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

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



数据链路层负载均衡



image.png

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

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



负载均衡路由算法



轮询

....



应用服务器的session管理



session复制



image.png

该方案已经被淘汰的。

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



session绑定（会话粘滞）



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

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



利用cookie记录session



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

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

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

对服务器架构要求很低。



session服务器



image.png