热搜词: 

nginx负载均衡原理,nginx反向代理和负载均衡的区别

发布:小编

本文目录

nginx反向代理和负载均衡的区别

负载均衡配置是超大型机器需要考虑的一些问题 同时也是数据安全的一种做法 下面我来介绍在nginx中反向代理 负载均衡配置图解 大家可参考本文章来操作 首先简单的介绍下修改默认的nginx conf 大概在 ~ 行 去掉前面的#号 重启nginx

#location ~ php$ {# proxy_pass ;#}改为 location ~ php$ { proxy_pass // : ;}

分别访问 出现如下图已经能够针对不同请求访问服务器了

这样当我们访问 l的时候 前端的nginx会自动进行响应 当访问 /test php的时候(这个时候nginx目录下根本就没有该文件) 但是通过上面的设置location ~ php$(表示

访问php页面test php : 的Apache进行响应

访问目录phpMyAdmin下的页面的话 : 的Apache进行响应

修改原始默认的nginx conf的server模块部分(大概在 ~ 行)

#location ~ php$ {# proxy_pass ;#}修改为 location ^~ /phpMyAdmin/ { proxy_pass : ;} location ~ php$ { proxy_pass : ;}

上面第一个部分location ^~ /phpMyAdmin/ 表示不使用; index index

2.在配置文件nginx.conf的模块中添加服务器集群server cluster的定义。Tw.WinGWit.

upstream myCluster { server 192.168.2.3:8080 ; server 192.168.2.2:80 ; server 192.168.2.8:80 ;}

表示这个server cluster包含3台服务器

3.然后在server模块中定义负载均衡

location ~ .php$ { proxy_pass //myCluster ; 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;}

proxy_pass //myCluster ; 这里的名字和上面的cluster的名字相同

配置好后,当访问页面,nginx目录下根本没有该文件,但是它会自动将其pass到myCluster定义的服务器群,分别由上述的3台服务器中的一台来做处理。

上面在定义upstream的时候每个server之后没有定义权重,表示两者均衡;如果希望某个更多响应的话,可以加weight

upstream myCluster { server 192.168.2.3:8080 weight=5; server 192.168.2.2:80 ; server 192.168.2.8:80 ;}

这样表示5/7的几率访问第一个server,1/7访问第二个、第三个。另外还可以定义max_fails和fail_timeout等参数。

所以我们使用nginx的反向代理服务器reverse proxy server的功能,将其布置到多台apache server的前端。

nginx仅仅用来处理静态页面响应和动态请求的代理pass,后台的apache服务器来对前台pass过来的动态页面进行处理并返回给nginx。

nginx负载均衡原理,nginx反向代理和负载均衡的区别图1

nginx实现负载均衡几种方式

1.负载均衡配置

2.失败重试配置

在fail_timeout时间内失败了max_fails次请求后,认为上游服务器不可用,就会将服务地址剔除掉,fail_timeout时间后会再次将服务器加入存活列表进行重试。

limit_req_zone指令设置参数

参数说明

limit_req_zone定义在http块中,$binary_remote_addr表示保存客户端IP地址的二进制形式。

Zone定义IP状态及URL访问频率的共享内存区域。zOne=keyword标识区域的名字,以及冒号后面跟区域大小。16000个IP地址的状态信息约1MB,例子区域可以存储160000个IP地址。

Rate定义最大请求速率。示例中速率不能超过每秒10个请求。

设置限流

burs排队大小,nodelay不限制单个请求间的时间。具体使用可以查看高并发场景如何使用nginx实现限流-实战篇

不限流白名单

该配置说明 192.168.1.0/24网段的ip访问是不限流的,其它限流。ip后面数字的含义

24表示子网掩码:255.255.255.0

16表示子网掩码:255.255.0.0

8表示子网掩码:255.0.0.0

1.浏览器缓存 静态资源缓存用expire

Response Header中添加了Expires和Cache-Control

所谓的静态资源一般包括一直不变的图像,如网站的logo,js、css静态文件还有可下载的内容,媒体文件

协商缓存(add_header ETag/Last-Modified value)包括html文件,经常替换的图片,经常需要修改的js、css文件和基本不变的api接口

不需要缓存包括用户隐私等敏感数据,用户经常变动的api接口

2.代理层缓存

在本地磁盘创建一个文件目录,根据我们的配置把请求资源以k(key自定义,这边用url的hash值)->v形式缓存到目录里,并根据需求对内容设置缓存时长,比如状态码为200缓存10分钟,其余的缓存1分钟等待。要清理缓存可以借助purger的功能。如果ab测试/个性化需求时应禁用浏览器缓存,否则会因为缓存导致误差。

方式一

方式二 lua+redis动态黑名单(openresty)

配置(/usr/local/openresty/nginx/conf/nginx.conf)

lua脚本编写(ip_blacklist.lua)

1.根据COOKIE实现灰度发布

根据cooke查询version值,根据version跳转到对应的host,如果没有匹配上的就跳转到默认配置。

2.根据来路ip实现灰度发布

nginx负载均衡原理,nginx反向代理和负载均衡的区别图2

Nginx怎么配置负载均衡

nginx和多台apache构成的机群cluster的负载均衡。

两种均衡:

1)可以在nginx中定义访问不同的内容,代理到不同的后台server; 如上例子中的访问phpMyAdmin目录代理到第一台server上;访问test.php代理到第二台server上;

2)可以在nginx中定义访问同一页面,均衡 (当然如果服务器性能不同可以定义权重来均衡)地代理到不同的后台server上。 如上的例子访问test.php页面,会均衡地代理到server1或者server2上。

实际应用中,server1和server2上分别保留相同的app程序和数据,需要考虑两者的数据同步。

nginx负载均衡原理,nginx反向代理和负载均衡的区别图3

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_hash variable_name

默认值:none

上下文:upstream

配置upstream采用一致性hash作为负载均衡算法,并使用配置的变量名作为hash输入。

参考文档:

https://www.cnblogs.com/FengGeBlog/p/10615345.html

***/nginx/nginx-upstream-consistent-hash-module/

nginx负载均衡原理,nginx反向代理和负载均衡的区别图4

以上就是关于nginx负载均衡原理,nginx反向代理和负载均衡的区别的全部内容,以及nginx负载均衡原理的相关内容,希望能够帮到您。

大家都在看

查看更多综合百科