负载均衡

一: 常见的负载均衡架构

1. 负载均衡架构

(1) 优点:

分发给web服务器集群， 客户端看不到内部的web服务器， 更安全



(2) 缺点

之所以使用集群, 是因为用户的请求太多, web服务器处理不过来了;

现在负载均衡服务器, 要处理所有的用户请求, 那么负载均衡服务的性能或带宽将成为整个服务器集群的瓶颈



2. HTTP重定向负载均衡

HTTP重定向负载均衡服务器, 只是一个只负责路由选择, 对应用服务器请求有用户发起

优点:

HTTP重定向负载均衡服务器 性能和带宽不会成为瓶颈

缺点:

把应用服务器的真实地址暴露给了客户端, 不安全



3. DNS 负载均衡服务器

优点

不会影响性能， 域名解析结果缓存起来

缺点

把应用服务器的真实地址暴露给了客户端, 不安全



但是百度和淘宝还在使用DNS负载均衡服务器, 为什么?

是因为他们的DNS服务均衡服务器， 解析出来的是不是真实的web服务器的IP地址， 而是内部负载均衡服务器的IP地址。



4. 反向代理负载均衡服务器



优点:

真实应用服务器在在内网, 安全



缺点:

反向代理负载均衡服务器转发是基于HTTP协议的, HTTP包很重,

所以反向代理负载均衡服务器的带宽将成为整个集群的瓶颈

在转发请求是http请求，http请求包或响应包是比较大， 通信比较慢; 需要拿到请求的响应包才能返回数据，当并发比较多的时候，就会在反向代理服务器上沉淀很多数据, 用户就需要等待。



5. IP负载君合服务器



优点:

在IP层做负载均衡， 数据包比较小， 速度更快

检查http包中的目标地址ip， 对http请求的目标IP直接修改， 修改为内网目标服务器的地址。



缺点：

用户请求与响应都要经过负载均衡服务器，性能不会出现瓶颈， 网络带宽， 网卡接口会出现瓶颈。

主要是图片或视频的响应的数据。



6. 数据链路层负载均衡

数据链路层负载均衡也别称为三角模式

优点:

请求进来的时候， 经过负载均衡服务器， 返回响应时不经过负载均衡服务器, 由于请求一般都比较小, 所以带宽和网卡接口不会成为集群性能的瓶颈



实现原理:

由于应用服务器要返回数据给客户端, 此时就要负载均衡服务和应用服务器集群有相同的IP地址(虚拟IP地址)

服务均衡服务器与应用服务器之间, 通过修改链路层的Mac地址实现通讯

通过修改数据目的的mac地址， ip地址不变， 负载均衡的IP地址和应用服务器的IP地址是一样的；

通过mac地址决定是那个应用服务器处理该请求, http协议不关心mac地址， http链路是通的。



二: 负载均衡算法

1. 轮询（最多）: 所有请求被依次分发到每一台应用服务器上, 适用于所有服务器硬件都相同的常见

2. 加权轮询: 根据应用服务器硬件性能情况, 在轮询的基础上, 按照配置的权重, 将请求分发到每一台服务器上, 搞性能的服务器分配更多请求

3. 随机: 请求随机分配到各个应用服务器, 在许多场合下, 这种方案很简单实用, 因为好的随机数本身就是很均衡的

4. 加权随机: 当应用服务器硬件配置不同时, 可以使用加权随机算法

5. 最少链接: 记录每一个应用服务器正在处理的链接数(请求数), 将新的请求分发到最少链接的服务器上, 这是最符合负载均衡定义的算法

6. 源地址散列（没有用）: 根据请求来源的IP地址进行Hash计算, 得到应用服务器, 该算法可以保证同一个来源的请求总在同一个服务上处理, 实现会话粘滞; 但是实际中没有用; 因为一旦某个应用服务器挂掉了, 客户端请求就不能被处理, 可用性差



三: 应用服务器集群的session管理



1. 利用Cookie 记录 Session



早期是应用比较普遍（生命力比较强）



缺点：

每次请求都有一个记录Cookie的Session

用户禁用cookie无法就无法获取用户会话了



优点：

支持业务的快速迭代

2. Session服务器

把Session放到session服务器上, 由Session服务器统一管理;