本节就聊聊采用Nginx负载均衡之后碰到的问题:
通常解决服务器负载问题,都会通过多服务器分载来解决。常见的解决方案有:
- 网站入口通过分站链接负载(天空软件站,华军软件园等)
- 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配置如何实现负载
View Code
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;
}
}
当有请求到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处理文件又比较方便,所以文件压库又多了一种选择。毕竟文件服务器的效率和管理以及安全都不及数据库。
随便聊聊这点事,其实也就是一些应用的趋势和多一种解决方案的实现。
分享到:
相关推荐
主要介绍了nginx负载均衡配置,宕机自动切换方式,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧
lvs+nginx负载均衡,lvs+nginx负载均衡,lvs+nginx负载均衡,lvs+nginx负载均衡
nginx 负载均衡与缓存服务器标准配置文件
基于nginx负载均衡的集群聊天系统,其中技术点有网络方面、数据库方面、线程安全方面;功能点有添加好友、单人聊天、群组聊天等 基于nginx负载均衡的集群聊天系统,其中技术点有网络方面、数据库方面、线程安全方面...
nginx 完成服务器之间集群的搭建 能够解决服务器调用负载均衡
nginx负载均衡配置文件实例:基本配置说明文档和一个配置好的nginx.conf文件实例
企业级keepalived高可用实战与Nginx负载均衡视频教程.zip
Nginx负载均衡搭建及配置技术,尽可能详细介绍了相关配置用法及静态资源配置相关,提高服务器运行及运维方面的知识
Tomcat在高并发环境下处理动态请求时性能很低,而在处理静态页面更加脆弱。是通过Nginx来处理静态页面要比通过Tomcat处理在性能方面好很多。本例为nginx负载均衡配置方法
在一台服务器的操作系统上,安装一个附加软件来实现负载均衡,如Nginx负载均衡(我们管理系统平台使用的也是这款均衡器)。它的优点是基于特定环境、配置简单、使用灵活、成本低廉,可以满足大部分
nginx负载均衡ssl证书认证强制跳转https+keeplived+apache
linux下安装Nginx并做到负载均衡,配置详细在文档有介绍!
该文档以Nginx为基础,详细梳理了负载均衡的原理,以及优化方式,和实现步骤,无论新手还是大虾都可以从中得到深入体会。
nginx 负载均衡 反向代理 nginx 负载均衡 反向代理 nginx 负载均衡 反向代理
阿里云服务器搭建nginx负载均衡
linux下的nginx搭建的负载均衡,nginx.conf文件修改成自己对应的地址即可直接使用,将配置复制进windows版本的nginx下应该也可用,这个没有测试,有问题,请联系哦
Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器... Nginx 支持简单的负载均衡和容错; 支持作为基本 HTTP 服务器的功能,例如日志、压缩、Byte ranges、Chunked responses、SSL、虚拟主机等等,应有尽有
Nginx的特点是: ... 2、Nginx对网络的依赖比较小; 3、Nginx安装和配置比较简单,测试起来比较方便; 4、也可以承担高的负载压力且稳定,一般能支撑超过1万... 另外默认的只有Round-robin和IP-hash两种负载均衡算法。
nginx经常用到的负载均衡的5种策略,注意细节,部分属性不能一起使用。
基于lua的nginx自定义负载均衡基于lua的nginx自定义负载均衡