nginx负载均衡策略(Nginx负载均衡)

负载均衡是我们大流量网站要做的一个东西，下面我来给大家介绍在Nginx服务器上进行负载均衡配置方法，希望对有需要的同学有所帮助哦。 负载均衡先来简单了解一下什么是负载均衡，单从字面上的意思来理解就可以解释N台服务器平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现，也就是两台以上即可。测试环境由于没有服务器，所以本次测试直接host指定域名，然后在VMware里安装了三台CentOS。测试域名：a.comA服务器IP ：192.168.5.149 （主）B服务器IP ：192.168.5.27C服务器IP ：192.168.5.126部署思路A服务器做为主服务器，域名直接解析到A服务器（192.168.5.149）上，由A服务器负载均衡到B服务器（192.168.5.27）与C服务器（192.168.5.126）上。域名解析由于不是真实环境，域名就随便使用一个a.com用作测试，所以a.com的解析只能在hosts文件设置。打开：C:WindowsSystem32driversetchosts在末尾添加192.168.5.149a.com保存退出，然后启动命令模式ping下看看是否已设置成功从截图上看已成功将a.com解析到192.168.5.149IPA服务器nginx.conf设置打开nginx.conf，文件位置在nginx安装目录的conf目录下。在http段加入以下代码upstream a.com {server192.168.5.126:80;server192.168.5.27:80;}server{listen 80;server_name a.com;location / {proxy_passhttp://a.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;}}保存重启nginxB、C服务器nginx.conf设置打开nginx.confi，在http段加入以下代码server{listen 80;server_name a.com;index index.html;root /data0/htdocs/www;}保存重启nginx测试当访问a.com的时候，为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的index.html文件，以作区分。打开浏览器访问a.com结果，刷新会发现所有的请求均分别被主服务器（192.168.5.149）分配到B服务器（192.168.5.27）与C服务器（192.168.5.126）上，实现了负载均衡效果。B服务器处理页面C服务器处理页面假如其中一台服务器宕机会怎样？当某台服务器宕机了，是否会影响访问呢？我们先来看看实例，根据以上例子，假设C服务器192.168.5.126这台机子宕机了（由于无法模拟宕机，所以我就把C服务器关机）然后再来访问看看。访问结果：我们发现，虽然C服务器（192.168.5.126）宕机了，但不影响网站访问。这样，就不会担心在负载均衡模式下因为某台机子宕机而拖累整个站点了。如果b.com也要设置负载均衡怎么办？很简单，跟a.com设置一样。如下：假设b.com的主服务器IP是192.168.5.149，负载均衡到192.168.5.150和192.168.5.151机器上现将域名b.com解析到192.168.5.149IP上。在主服务器(192.168.5.149)的nginx.conf加入以下代码：upstream b.com {server192.168.5.150:80;server192.168.5.151:80;}server{listen 80;server_name b.com;location / {proxy_passhttp://b.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;}}保存重启nginx在192.168.5.150与192.168.5.151机器上设置nginx，打开nginx.conf在末尾添加以下代码：server{listen 80;server_name b.com;index index.html;root /data0/htdocs/www;}保存重启nginx完成以后步骤后即可实现b.com的负载均衡配置。主服务器不能提供服务吗？以上例子中，我们都是应用到了主服务器负载均衡到其它服务器上，那么主服务器本身能不能也加在服务器列表中，这样就不会白白浪费拿一台服务器纯当做转发功能，而是也参与到提供服务中来。如以上案例三台服务器：A服务器IP ：192.168.5.149 （主）B服务器IP ：192.168.5.27C服务器IP ：192.168.5.126我们把域名解析到A服务器，然后由A服务器转发到B服务器与C服务器，那么A服务器只做一个转发功能，现在我们让A服务器也提供站点服务。我们先来分析一下，如果添加主服务器到upstream中，那么可能会有以下两种情况发生：1、主服务器转发到了其它IP上，其它IP服务器正常处理；2、主服务器转发到了自己IP上，然后又进到主服务器分配IP那里，假如一直分配到本机，则会造成一个死循环。怎么解决这个问题呢？因为80端口已经用来监听负载均衡的处理，那么本服务器上就不能再使用80端口来处理a.com的访问请求，得用一个新的。于是我们把主服务器的nginx.conf加入以下一段代码：server{listen 8080;server_name a.com;index index.html;root /data0/htdocs/www;}重启nginx，在浏览器输入a.com:8080试试看能不能访问。结果可以正常访问既然能正常访问，那么我们就可以把主服务器添加到upstream中，但是端口要改一下，如下代码：upstream a.com {server192.168.5.126:80;server192.168.5.27:80;server127.0.0.1:8080;}由于这里可以添加主服务器IP192.168.5.149或者127.0.0.1均可以，都表示访问自己。重启Nginx，然后再来访问a.com看看会不会分配到主服务器上。主服务器也能正常加入服务了。最后一、负载均衡不是nginx独有，著名鼎鼎的apache也有，但性能可能不如nginx。二、多台服务器提供服务，但域名只解析到主服务器，而真正的服务器IP不会被ping下即可获得，增加一定安全性。三、upstream里的IP不一定是内网，外网IP也可以。不过经典的案例是，局域网中某台IP暴露在外网下，域名直接解析到此IP。然后又这台主服务器转发到内网服务器IP中。四、某台服务器宕机、不会影响网站正常运行，Nginx不会把请求转发到已宕机的IP上解析nginx负载均衡原理摘要：对于一个大型网站来说，负载均衡是永恒的话题。随着硬件技术的迅猛发展，越来越多的负载均衡硬件设备涌现出来，如F5 BIG-IP、Citrix NetScaler、Radware等等，虽然可以解决问题，但其高昂的价格却往往令人望而却步，因此负载均衡软件仍然是大部分公司的不二之选。nginx作为webserver的后起之秀，其优秀的反向代理功能和灵活的负载均衡策略受到了业界广泛的关注。本文将以工业生产为背景，从设计实现和具体应用等方面详细介绍nginx负载均衡策略。 关键字：nginx 负载均衡 反向代理

一、 下载Nginx（nginx-1.5.8.zip） 解压到D：/serve目录下双击运行nginx.exe,屏幕一闪而过或者在DOS里面敲打命令，如图所示：可以看到屏幕一闪而过，接下来测试一下是否安装启动成功；在任务管理器的进程中查看nginx.exe是否启动若看到该映像名称，证明nginx程序已经启动成功！这时我们就可以在浏览器中访问:http://localhost这样我们就成功的搭建了一个nginx服务！！Nginx+Tomcat负载均衡配置这里只需要修改Nginx的配置文件nginx.conf，让它通过tomcat来转发。Nginx配置文件完成如下：#使用的用户和组,window下不指定#usernobody;#指定工作衍生进程数(一般等于CPU总和数或总和数的两倍，例如两个四核CPU，则总和数为8)worker_processes1;#指定错误日志文件存放路径，错误日志级别可选项为【debug|info|notice|warn|error|crit】#error_loglogs/error.log;#error_loglogs/error.lognotice;#error_loglogs/error.loginfo;#指定pid存放路径#pidlogs/nginx.pid;#工作模式及连接数上限events {#使用网络I/O模型，Linux系统推荐使用epoll模型，FreeBSD系统推荐使用kqueue;window下不指定#允许的连接数#user epoll;worker_connections100;}#设定http服务器，利用他的反向代理功能提供负载均衡支持http {#设定mime类型include mime.types;default_typeapplication/octet-stream;#设定日志格式log_formatmain'$remote_addr - $remote_user [$time_local] "$request" ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent" "$http_x_forwarded_for"';client_header_buffer_size 1k;large_client_header_buffers 4 4k;access_loglogs/access.logmain;#设定access logclient_header_timeout 3m;client_body_timeout 3m;send_timeout 3m;sendfileon;tcp_nopush on;tcp_nodelay on;#keepalive_timeout0;keepalive_timeout65;#开启gzip模块gzipon;gzip_min_length 1100;gzip_buffers 4 8k;gzip_types text/plain application/x-javascript text/css application/xml;output_buffers 1 32k;postpone_output 1460;server_names_hash_bucket_size 128;client_max_body_size 8m;fastcgi_connect_timeout 300;fastcgi_send_timeout 300;fastcgi_read_timeout 300;fastcgi_buffer_size 64k;fastcgi_buffers 4 64k;fastcgi_busy_buffers_size 128k;fastcgi_temp_file_write_size 128k;gzip_http_version 1.1;gzip_comp_level 2;gzip_vary on;#设定负载均衡的服务器列表upstream localhost {#设定负载均衡的服务器列表#ip_hash;#同一机器在多网情况下，路由切换，ip可能不同 #weigth参数表示权值，权值越高被分配到的几率越大server 192.168.101.222:8088 max_fails=2 fail_timeout=600s;server 192.168.101.5:8081 max_fails=2 fail_timeout=600s;}#设定虚拟主机server {listen 80;server_namelocalhost;charset UTF-8;#设定本虚拟主机的访问日志access_loglogs/host.access.logmain;#对 "/" 启用负载均衡location / {root \192.168.101.222D:webapache-tomcat-6.0.37webapps;indexindex.html index.htm index.aspx;proxy_redirect off;#保留用户真实信息proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;#允许客户端请求的最大单个文件字节数client_max_body_size 10m;#缓冲区代理缓冲用户端请求的最大字节数，可以理解为先保存到本地再传给用户client_body_buffer_size 128k;#跟后端服务器连接超时时间 发起握手等候响应超时时间proxy_connect_timeout 12;#连接成功后 等待后端服务器响应时间 其实已进入后端的排队之中等候处理proxy_read_timeout 90;#代理请求缓存区 这个缓存区间会保存用户的头信息一共Nginx进行规则处理 一般只要能保存下头信息即可proxy_send_timeout 90;#同上 告诉Nginx保存单个用的几个Buffer最大用多大空间proxy_buffer_size 4k;proxy_buffers 4 32k;#如果系统很忙的时候可以申请国内各大的proxy_buffers 官方推荐 *2proxy_busy_buffers_size 64k;#proxy 缓存临时文件的大小proxy_temp_file_write_size 64k;proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;proxy_max_temp_file_size 128m;proxy_passhttp://localhost;}error_page 500 502 503 504/50x.html;location = /50x.html {root html;}}}四、测试前提是分别启动两台机器的tomcat,其次启动nginx服务；在192.168.101.23上访问nginx服务器（通过访问（项目路径）来实现对192.168.101.222和192.168.101.5这两个机器上应用程序的访问，最终实现tomcat的均衡负载）[1]关闭192.168.101.222上的tomcat服务，访问192.168.101.23上的nginx服务，观察192.168.101.5上的tomcat是否运行；[2]关闭192.168.101.5上的tomcat服务，访问192.168.101.23上的nginx服务，观察192.168.101.222上的tomcat是否运行；[3]两个tomcat都启动，访问nginx服务，模拟并发用户n个，观察tomcat的运行情况； 如果[1]和[2]的tomcat都运行就说明搭建nginx代理服务成功，tomcat实现了均衡负载；

这方面的资料，基本都是一块一块不完整的。我大概跟你说一个基本架构： 1、DNS服务器，如果资金充足的话，建议使用BGP机房，2-3台DNS服务器均衡，通常使用bind软件。如果资金紧的话，可以购买专业的dns服务，比如国内的dnspod。2、CDN服务器，一开始如果想省事，可以买专业公司的服务，如chinacache，但随着发展成本会越来越高。自建的话，可能分别搭建，放电信、联通、移动等不同机房的服务器，通过dns做动态解析。超大网站的话，可以用Squid，普通中至大型用nginx，内部玩玩用varnish。3、前端均衡，资金充足的话，可以使用硬件设备，几十万一台。自已有技术队伍的话，就用nginx/haproxy+keepalived等自已组建前端。均衡的方式都比较灵活，随机、权重、ip、url都有。4、同步的问题要看同步什么东西，普通的可以实时文件同步。但数据库的话，要看具体类型选择同步方式了。 5、后端的应用服务器和数据库集群，要看流量规划了。

1、nginx做反向代理几台服务器都可以用，一台也可以，具体要看你预计的业务量有多少。一台的话，就是将访问本机80/443端口的请求转发给本机8080端口，多台同理。 2、理论上很少直接用tomcat对外提供服务的，因为可扩展性太差。比如你单台tomcat负载太大了，就没法直接扩展。而使用nginx的话，后端的tomcat可以很方便的做横向扩展。3、tomcat只适用于少量并发的环境，并且处理静态文件的能力一般。nginx可承载较大的并发量。但具体多少并发才能看出来差距就没有实测过了。 4、个人理解一台高配性能的服务器应该是高于两台中配的，因为单机中减去了网络传输的消耗，稳定性单机就不如两台了，因为两台可以做高可用。
一般需要三台服务器， 两台nginx做前端，一台后端数据库。

哈希负载均衡原理ngx_http_upstream_hash_module支持普通的hash及一致性hash两种负载均衡算法，默认的是普通的hash来进行负载均衡。nginx 普通的hash算法支持配置http变量值作为hash值计算的key，通过hash计算得出的hash值和总权重的余数作为挑选server的依据；nginx的一致性hash(chash)算法则要复杂一些。这里会对一致性hash的机制原理作详细的说明。一致性hash算法的原理一致性hash用于对hash算法的改进，后端服务器在配置的server的数量发生变化后，同一个upstream server接收到的请求会的数量和server数量变化之间会有变化。尤其是在负载均衡配置的upstream server数量发生增长后，造成产生的请求可能会在后端的upstream server中并不均匀，有的upstream server负载很低，有的upstream server负载较高，这样的负载均衡的效果比较差，可能对upstream server造成不良的影响。由此，产生了一致性hash算法来均衡。那么为什么一致性hash算法能改善这种情况呢？这里引用网上资料的一致性hash算法的图例。因为对于hash(k)的范围在int范围，所以我们将0~2^32作为一个环。其步骤为：1，求出每个服务器的hash（服务器ip）值，将其配置到一个 0~2^n 的圆环上（n通常取32）。2，用同样的方法求出待存储对象的主键 hash值，也将其配置到这个圆环上，然后从数据映射到的位置开始顺时针查找，将数据分布到找到的第一个服务器节点上。其分布如图：除了上边的优点，其实还有一个优点：对于热点数据，如果发现node1访问量明显很大，负载高于其他节点，这就说明node1存储的数据是热点数据。这时候，为了减少node1的负载，我们可以在热点数据位置再加入一个node，用来分担热点数据的压力。雪崩效应接下来我们来看一下，当有节点宕机时会有什么问题。如下图：如上图，当B节点宕机后，原本存储在B节点的k1，k2将会迁移到节点C上，这可能会导致很大的问题。如果B上存储的是热点数据，将数据迁移到C节点上，然后C需要承受B+C的数据，也承受不住，也挂了。。。。然后继续CD都挂了。这就造成了雪崩效应。上面会造成雪崩效应的原因分析：如果不存在热点数据的时候，每台机器的承受的压力是M/2(假设每台机器的最高负载能力为M)，原本是不会有问题的，但是，这个时候A服务器由于有热点数据挂了，然后A的数据迁移至B，导致B所需要承受的压力变为M（还不考虑热点数据访问的压力），所以这个失败B是必挂的，然后C至少需要承受1.5M的压力。。。。然后大家一起挂。。。所以我们通过上面可以看到，之所以会大家一起挂，原因在于如果一台机器挂了，那么它的压力全部被分配到一台机器上，导致雪崩。怎么解决雪崩问题呢，这时候需要引入虚拟节点来进行解决。虚拟节点虚拟节点，我们可以针对每个实际的节点，虚拟出多个虚拟节点，用来映射到圈上的位置，进行存储对应的数据。如下图：如上图：A节点对应A1，A2，BCD节点同理。这时候，如果A节点挂了，A节点的数据迁移情况是:A1数据会迁移到C2，A2数据迁移到D1。这就相当于A的数据被C和D分担了，这就避免了雪崩效应的发送，而且虚拟节点我们可以自定义设置，使其适用于我们的应用。ngx_http_upstream_consistent_hash该模块可以根据配置参数采取不同的方式将请求均匀映射到后端机器，比如：指令语法：consistent_hashvariable_name默认值：none上下文：upstream配置upstream采用一致性hash作为负载均衡算法，并使用配置的变量名作为hash输入。参考文档：https://www.cnblogs.com/FengGeBlog/p/10615345.htmlhttp://www.ttlsa.com/nginx/nginx-upstream-consistent-hash-module/