Nginx网络负载均衡,负载均衡,网络负载,网络均衡

2017-09-12 17:29:02

本节就聊聊采用Nginx负载均衡之后碰到的问题:

  • Session问题

  • 文件上传下载

通常解决服务器负载问题,都会通过多服务器分载来解决。常见的解决方案有:

  • 网站入口通过分站链接负载(天空软件站,华军软件园等)

  • DNS轮询

  • F5物理设备

  • Nginx等轻量级架构

那我们看看Nginx是如何实现负载均衡的,Nginx的upstream目前支持以下几种方式的分配 1、轮询(默认) 每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。 2、weight 指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。 2、ip_hash 每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。 3、fair(第三方) 按后端服务器的响应时间来分配请求,响应时间短的优先分配。 4、url_hash(第三方) 按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。

Upstream配置如何实现负载  

复制代码

http { 

upstream www.test1.com {
ip_hash;
server 172.16.125.76:8066 weight=10;
server 172.16.125.76:8077 down;
server 172.16.0.18:8066 max_fails=3 fail_timeout=30s;
server 172.16.0.18:8077 backup;
}

upstream www.test2.com {
server 172.16.0.21:8066;
server 192.168.76.98:8066; 
}

server {
listen 80;
server_name www.test1.com; 

location /{
proxy_pass http://www.test1.com;proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
} 
} 

server {
listen 80;
server_name www.test2.com; 

location /{
proxy_pass http://www.test2.com;proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

复制代码

按 Ctrl+C 复制代码

当有请求到www.test1.com/www.test2.com 时请求会被分发到对应的upstream设置的服务器列表上。test2的每一次请求分发的服务器都是随机的,就是第一种情况列举的。而test1刚是根据来访问ip的hashid来分发到指定的服务器,也就是说该IP的请求都是转到这个指定的服务器上。

根据服务器的本身的性能差别及职能,可以设置不同的参数控制。

down 表示负载过重或者不参与负载

weight 权重过大代表承担的负载就越大

backup 其它服务器时或down时才会请求backup服务器

max_fails 失败超过指定次数会暂停或请求转往其它服务器

fail_timeout 失败超过指定次数后暂停时间

以上就Nginx的负载均衡的简单配置。那继续我们的本节讨论内容:

一、Session问题

当我们确定一系列负载的服务器后,那我们的WEB站点会分布到这些服务器上。这个时候如果采用Test2 每一次请求随机访问任何一台服务器上,这样导致你访问A服务器后,下一次请求又突然转到B服务器上。这个时候与A服务器建立的Session,传到B站点服务器肯定是无法正常响应的。我们看一下常用的解决方案:

  • Session或凭据缓存到独立的服务器

  • Session或凭据保存数据库中

  • nginx ip_hash 保持同一IP的请求都是指定到固定的一台服务器

第一种缓存的方式比较理想,缓存的效率也比较高。但是每一台请求服务器都去访问Session会话服务器,那不是加载重了这台Session服务器的负担吗?

第二种保存到数据库中,除了要控制Session的有效期,同时加重了数据库的负担,所以最终的转变为SQL Server 负载均衡,涉及读,写,过期,同步。

第三种通过nginx ip_hash负载保持对同一服务器的会话,这种看起来最方便,最轻量。

正常情况下架构简单的话, ip_hash可以解决Session问题,但是我们来看看下面这种情况

 

这个时候ip_hash 收到的请求都是来自固定IP代理的请求,如果代理IP的负载过高就会导致ip_hash对应的服务器负载压力过大,这样ip_hash就失去了负载均衡的作用了。

如果缓存可以实现同步共享的话,我们可以通过多session服务器来解决单一负载过重的问题。那Memcached是否可以做Session缓存服务器呢?MemcachedProvider提供了Session的功能,即将Session保存到数据库中。那为什么不直接保存到数据库中,而要通过Memcached保存到数据库中呢?很简单,如果直接保存到数据库中,每一次请求Session有效性都要回数据库验证一下。其次,即使我们为数据库建立一层缓存,那这个缓存也无法实现分布式共享,还是针对同一台缓存服务器负载过重。网上也看到有用Memcached实现Session缓存的成功案例,当然数据库方式实现的还是比较常用的,比如开源Disuz.net论坛。缓存实现的小范围分布式也是比较常用的,比如单点登录也是一种特殊情况。

二、文件上传下载

如果实现了负载均衡,除了Session问题,我们还会碰到文件的上传下载问题。文件不可能上传不同的服务器上,这样会导致下载不到对应文件的问题。我们看一下下面的方案

  • 独立文件服务器

  • 文件压缩数据库

两种方案都是常用的,我们来说一下文件压缩数据库,以前的方式都是将文件二进制压缩至关系型数据库,而现在NOSQL的流行,加上MongoDB处理文件又比较方便,所以文件压库又多了一种选择。毕竟文件服务器的效率和管理以及安全都不及数据库。

随便聊聊这点事,其实也就是一些应用的趋势和多一种解决方案的实现。


  • 2020-11-17 16:50:16

    JS常见加密混淆方式

    目录 前端js常见混淆加密保护方式 eval方法等字符串参数 emscripten WebAssembly js混淆实现 JSFuck AAEncode JJEncode 代码压缩 变量名混淆 字符串混淆 自我保护,比如卡死浏览器 控制流平坦化 僵尸代码注入 对象键名替换 禁用控制台输出 调试保护,比如无限Debug,定时Debug 域名锁定

  • 2020-11-17 17:08:28

    用js编写WebAssembly ,WebAssembly 现状与实战

    自从 JavaScript 诞生起到现在已经变成最流行的编程语言,这背后正是 Web 的发展所推动的。Web 应用变得更多更复杂,但这也渐渐暴露出了 JavaScript 的问题:

  • 2020-11-17 17:28:06

    AssemblyScript 开发WebAssembly 教程

    WebAssembly 以及通过 AssemblyScript 的扩展,不会使每个网站都神奇地变得更快,但是这并不重要。 WebAssembly 之所以令人兴奋,是因为它可以使更多的应用在 Web 变得中可行。

  • 2020-11-17 21:15:48

    如何保障 API 接口的安全性?前端如何加密

    一、1. HTTP 请求中的来源识别 二、2. 数据加密 三、3. 数据签名 四、4. 时间戳 五、5. AppID 六、6. 参数整体加密 七、7. 限流 八、8. 黑名单 九、1. 压缩 十、2. 混淆 undefined、3. 加密

  • 2020-11-18 14:34:00

    当你写爬虫抓不到APP请求包的时候该怎么办?

    提示:因为高级篇以后的APP将无法使用很通用的方式处理,每种类型甚至是每个APP的反抓包处理方式都会有差别,所以这个系列以后会以【高级篇-具体类型】的形式来写。

  • 2020-11-21 20:41:51

    Kotlin Sealed class类详解

    Sealed class(密封类) 是一个有特定数量子类的类,看上去和枚举有点类似,所不同的是,在枚举中,我们每个类型只有一个对象(实例);而在密封类中,同一个类可以拥有几个对象。

  • 2020-11-22 20:53:43

    Dagger2之Kotlin写法

    修饰构造方法 修饰变量,在宿主类里,引入要注入的实例

  • 2020-11-22 20:56:13

    Dagger2使用详解

    简单的说,就是一个工厂模式,由Dagger负责创建工厂,帮忙生产instance。遵从Java规范JSR 330,可以使用这些注解。现在不研究Dagger2是如何根据注解去生成工厂的,先来看看工厂是什么东西,理解为什么可以实现了DI(Dependency Injection),如何创建IoC(Inverse of Control)容器。

  • 2020-11-22 21:00:28

    dagger.android--Fragment,BaseFragment

    1 使用Fragment参数来代替Activity参数 2 使用 @FragmentKey来代替@ActivityKey 3 使用HasFragmentInjector来代替@HasActivityInjector 4 AndroidInjection.inject(Fragment)方法,在Fragment的onAttach()中调用,而不是在onCreate()中 5 Fragment的Module添加位置,和Activity是不同的,它取决于Fragment需要的其他依赖注入