负载均衡

发布于: 2020 年 07 月 15 日

一: 常见的负载均衡架构

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服务器统一管理;

用户头像

满山李子

关注

还未添加个人签名 2018.09.18 加入

还未添加个人简介

评论

发布
暂无评论
负载均衡