负载均衡
集群中的应用服务器(节点)通常被设计成无状态,用户可以请求任何一个应用服务器。
负载均衡器会根据集群中每个节点的负载情况,将用户请求转发到合适的节点上。
负载均衡器可以用来实现高可用以及伸缩性:
- 高可用:当某个节点发生故障时,负载均衡器会将用户请求转发到另外的节点上,从而保证所有服务持续可用。
- 伸缩性:可以很容易的添加或者删除节点(应用服务器)。
负载均衡运行过程包括两部分:
- 根据负载均衡算法得到请求转发的节点。
- 将请求进行转发。
负载均衡算法:
轮询算法:
轮询算法把请求轮流发送到每个服务器上。
下图六个客户端产生6个请求,这六个请求按照123456的顺序发送。135的请求被发送到服务器1, 246的请求被发送到服务器2。
该算法比较适合每个服务器性能差不多的场景,如果性能存在差异,那么性能较差的服务器可能无法承担过大的负载。
加权轮询算法:
加权轮询是在轮询的基础上,根据服务器的性能差异,为服务器赋予一定的权值,性能高的服务器分配更高的权值。
如图,服务器1被赋予的权值为5,服务器2被赋予的权值为1。
最少连接算法:
由于每个请求的连接时间不一样,使用轮询或者加权轮询,可能会让一台服务器当前连接数过大,而另一台连接数过小,造成负载不均衡。
下图,135请求被发送到服务器1但是13很快断开连接,此时只有5请求连接服务器1; 246请求被发送到服务器2,只有2断开连接,此时46请求连接服务器2 。该系统运行时,服务器2会承担过大的负载。
最少连接算法就是将请求发送给当前连接数最少的服务器上。
下图,新来的6就会被连接到服务器1。
加权最少连接:
在最少连接的基础上,根据服务器的性能为每台服务器分配权重,在根据权重计算出每台服务器能处理的连接数。
随机算法:
把请求随机发送到服务器上,和轮询算法类似,该算法比较适合服务器性能差不多的场景。
源地址哈希法:
源地址哈希通过对客户端IP计算哈希值后,在对服务器数量取模得到目标服务器的序号。
可以保证同一IP的客户段请求会转发到同一台服务器上,用来实现会话粘滞(Sticky Session)。
转发实现
HTTP重定向:
HTTP重定向 负载服务器使用某种负载均衡算法,计算得到服务器的IP地址后,将该地址写入HTTP重定向报文中,状态码302。 客户端收到重定向报文后,需要重新向服务器发起请求。
缺点:
- 需要两次请求,因此访问延迟较高。
- HTTP负载均衡服务器处理能力有限,会限制集群的规模。
该负载缺点比较明显,实际场景使用较少。
DNS域名解析:
在DNS解析域名的同时,使用负载均衡算法计算服务器IP地址。
优点:
- DNS能够根据地理位置进行域名解析,返回离用户最近的服务器IP地址,改善性能。
- 将负载均衡工作交给DNS省去了网站管理维护负载均衡服务器的麻烦。
- 服务器可以部署在互联网的任意位置。
缺点: - 由于DNS具有多级结构,每一级的域名记录都可能被缓存,当下线一台服务器需要需要修改DNS记录时,需要很长一段时间才能有效。
- 不能按照服务器的处理能来分配负载。DNS负载均衡采用的是最简单的轮询算法,不能区分服务器之间的差异。
- 可能会造成额外的网络问题。为了使本DNS服务器和其它DNS服务器及时交互,保证DNS数据即时更新,使地址能够随机分配,一般都需要将DNS得刷新时间设置的较小,但太小会增加额外的网络问题。
大型网站基本使用了DNS作为第一级负载均衡手段,即域名解析得到的一组服务器并不是实际提供服务的物理服务器,然后再内部使用其它方式做第二级负载均衡。也就是说,域名解析的结果为内部负载均衡服务器的IP地址。
DNS域名解析工作原理
由上图可以看出,在DNS服务器中应该配置了多个A记录,如:
www.aaaa.com IN A 114.100.20.201;
www.aaaa.com IN A 114.100.20.202;
www.aaaa.com IN A 114.100.20.203;
因此,每次域名解析请求都会根据对应的负载均衡算法计算出一个不同的IP地址并返回,这样主机记录(也称A记录)中配置多个服务器就可以构成一个集群,并且可以实现负载均衡。
反向代理服务器:
首先了解下正向代理和反向代理的区别:
- 正向代理:发生在客户端,由用户主动发起。比如翻墙,客户端通过主动访问代理服务器,让代理服务器获得需要的外网数据,然后转发会客户端。
- 反向代理:发生在服务器端,用户不知道代理的存在。
反向代理服务器位于源服务器前面,用户的请求需要先经过反向代理服务器才能到达源服务器。反向代理可以用来进行缓存,日志记录等。同时可以用来做负载均衡服务器。
在这种负载均衡转发模式下,客户端不能直接请求源服务器,因此原服务器不需要外部IP地址,而反向代理需要配置内部和外部两套IP地址。
优点: - 与其它功能集成在一起,部署简单。
缺点: - 所有请求和响应都需要经过反向代理服务器,他可能会成为性能瓶颈。
网络层:
注意: 网络层转发和链路层转发都是基于对负载均衡服务器的优化。
在操作系统内核进程获取网络数据包,根据负载均衡算法计算源服务器的IP地址,并修改请求数据包的目的IP地址,最后进行转发。
源服务器返回的响应也需要经过负载均衡服务器,通常是让负载均衡服务器同时作为集群的网关服务器来实现。
优点:
- 在内核进程中进行处理,性能较高。
缺点: - 和反向代理一样,所有的请求和响应都经过负载服务器,会成为性能瓶颈。
链路层:
在链路层根据负载均衡算法计算源服务器的MAC地址,并修改请求数据包的目的MAC地址,并进行转发。
通过配置源服务器的虚拟IP地址和负载服务器的IP地址一致,从而不需要修改IP地址就可以进行转发。也正因为IP地址一样,所以源服务器的响应不需要发回负载均衡服务器,可以直接转发给客户端,避免了负载均衡服务器成为瓶颈。
这是一种三角传输模式,称为直接路由 ,对于提供下载和视频服务的网站来说,直接路由避免了大量的网络传输数据经过负载均衡服务器。
这是目前大型网站使用最广的负载均衡转发方式。在linux平台可以使用负载均衡服务器LVS(Linux Virtual Server) 。
集群下的Session(会话)管理
一个用户的Session信息如果存储在一个服务器上,那么当负载均衡器把用户的下一个请求转发到另一个服务器,由于服务器没有用户的Session信息,那么该用户就需要重新进行登陆等操作。
Sticky Session(粘性会话)
需要配置负载均衡器,使得一个用户的所有请求都被路由到同一个服务器,这样就可以把用户的Session存放在该服务器中。
缺点:
- 当服务器宕机时,将丢失该服务器上所有的Session。
Session Replication(复制会话)
在服务器之间进行Session同步操作,每个服务器都有所有用户的Session信息,因此用户可以向任何一个服务器进行请求。
缺点:
- 占用过多内存;
- 同步过程占用网络带宽以及服务器处理器时间。
- 寻找session也花费大量时间。
Session Server(会话服务器)
使用一个单独的服务器存储Session数据,可以使用传统的MySQL,也可以使用Redis或者Memcahed这种内存型数据库。
优点:
- 使得大型网站具有伸缩性(容易的添加/删除节点),集群中的应用服务器通常需要保持无状态,那么应用服务器不能存储用户的会话信息。 session Server将用户的会话信息单独进行存储,从而保证了应用服务器的无状态。
缺点:
- 需要去实现存取Session的代码。