负载均衡

    负载均衡是网站必不可少的基础技术手段，不但可以实现网站的伸缩性，同时还改善网站的可用性，负载均衡的基础技术有以下几种：

HTTP重定向负载均衡

    HTTP重定向负载均衡利用HTTP重定向协议实现。如下图所示：

    HTTP重定向服务器就是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP请求计算一台真实的Web服务器地址，并将该Web服务器地址写入HTTP重定向响应中返回给用户浏览器（响应状态码302）。
    优点是比较简单。缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差。重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用HTTP302响应码重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。

DNS域名解析负载均衡

这是利用DNS处理域名解析请求的同时进行负载均衡处理的一种方案，如下图所示：

    在DNS服务器中配置多个A记录，每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，这样A记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。
    DNS域名解析负载均衡的优点是将负载均衡的工作转交给DNS，省掉了网站管理维护负载均衡服务器的麻烦，同时许多DNS还支持基于地理位置的域名解析，即会将域名解析成距离用户地理最近的一个服务器地址，这样可加快用户访问速度，改善性能。缺点如下：目前的DNS是多级解析，每一级DNS都可能缓存A记录，当下线某台服务器后，即使修改了DNS的A记录，要使其生效也需要较长时间，这段时间会导致用户访问失败；而且DNS负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。

反向代理负载均衡

    利用反向代理服务器进行负载均衡如下图所示：

    反向代理服务器处于Web服务器前面，管理一组Web服务器，将请求根据负载均衡算法转发到不同Web服务器上。Web服务器处理完成的响应也需要通过反向代理服务器返回给用户。由于Web服务器不直接对外提供访问，因此不需要使用外部ip地址，而反向代理服务器则需要配置双网卡和内部外部两套IP地址。
    由于反向代理服务器转发请求在HTTP协议层面，因此也叫作应用层负载均衡。其优点是和反向代理服务器功能集成在一起，部署简单。缺点是反向代理服务器是所有请求和响应的中转站，其性能可能成为瓶颈。

IP负载均衡

    IP负载均衡在网络层通过修改请求目标地址进行负载均衡。

    用户请求数据包达到负载均衡服务器114.100.80.10后，负载均衡服务器在操作系统内核进程获取网络数据包，根据负载均衡算法计算得到一台真实Web服务器10.0.0.1，然后将数据目的IP地址修改为10.0.0.1，不需要通过用户进程处理。真实Web应用服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器再将数据包源地址修改为自身的IP地址(114.100.80.10)发送给用户浏览器。
    这里的关键在于真实物理Web服务器响应数据包如何返回给负载均衡服务器。一种方案是负载均衡服务器在修改目的IP地址的同时修改源地址，将数据包源地址设为自身IP，即源地址转换，这样Web服务器的响应会再回到负载均衡服务器；另一种方案是将负载均衡服务器同时作为真实物理服务器集群的网关服务器，这样所有响应数据都会到达负载均衡服务器。
     IP负载均衡在内核进程完成数据分发，较反向代理负载均衡有更好的处理性能。但是由于所有请求响应都需要经过负载均衡服务器，集群的最大响应数据吞吐量不得不受制于负载均衡服务器网卡带宽。

数据链路层负载均衡

    数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡，如下图所示：

    这种数据传输方式又称为三角传输模式，负载均衡数据分发过程中不修改IP地址，只修改目的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的，由于实际处理请求的真实物理服务器IP和数据请求目的IP一致，不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈，这种负载均衡方式又称作直接路由方式（DR）。
    使用三角传输模式的链路层负载均衡是目前大型网站使用最广的一种负载均衡手段。在linux平台上最好的链路层负载均衡开源产品是LVS（Linux Virtual Server）。

负载均衡算法

    负载均衡服务器的实现可以分为两个部分：
1. 根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址；
2. 将请求数据发送到该地址对应的Web服务器上。
负载均衡算法
1） 轮询（Round Robin, RR）
    所有请求被依次分发到每台应用服务器上，即每台服务器需要处理的请求数目都相同，适合于所有服务器硬件都相同的场景。
2） 加权轮询（Weighted Round Robin， WRR）
    根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请求分发到每个服务器，高性能的服务器能分配更多请求。
3） 随机（Random）
    请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很均衡。即使应用服务器配置不同，也可以实用加权随机算法。
4） 最少连接（Least Connections）
    记录每个应用服务器正在处理的连接数，将新的请求分发到连接数最少的服务器上。最少连接算法也可以实现加权最少连接。
5） 源地址散列（Source Hashing）
    根据请求来源的IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话周期内重复使用，从而实现会话黏滞。