cncml手绘网

标题: 浅谈Nginx之反向代理与负载均衡 [打印本页]

作者: admin    时间: 2020-2-25 23:05
标题: 浅谈Nginx之反向代理与负载均衡

Nginx的负载均衡是基于反向代理实现的,因此,本文先讨论什么是反向代理,再在这个的基础上讨论负载均衡以及负载均衡时应该注意哪些策略。

反向代理:

如下图所示,

, n1 d. v1 S# b0 g& {

  ↓-----Nginx将结果返回给浏览器---丨                                                          对Tomcat来说,只知道服务对象是Nginx服务器

浏览器  -发起对该域的访问请求->   Nginx  --------------Nginx将请求来转发给Tomcat服务器---->  Tomcat...

                                                          丨-对Tomcat来说,只对nginx负责,将结果返回给Nginx服务器---↑


( L+ Q$ k+ L% v6 D: v3 m从图中,我们可以知道,对于浏览器来说,他会发一个http://www.a.com/uri请求到Nginx服务器,对于他来说,他认为数据就是从http://www.a.com/uri域中返回的,事实上,当http://www.a.com/uri到达Nginx服务器后,Nginx服务器会将其转发给http://www.b.com/uri,从http://www.b.com/uri域中取得数据并将其返回给浏览器,这个步骤浏览器是不知道的,也就是说,浏览器并不知道http://www.b.com/uri该域的存在,同理,http://www.b.com/uri所在的域(图中的Tomcat)也并不知道浏览器的存在,他也只对Nginx负责。Nginx的这么一个过程便称为反向代理。- F6 B: H5 a5 t7 Z" i

# T3 E9 X. e0 b' Y! i" q4 D那么,Nginx服务器是如何实现这一步的呢,事实上也很简单,只需要在location中做一下简单的配置即可,命令大概如下图所示:(配置完命令记得reload重新加载才能生效)# {7 r" N/ v  I4 t
- R! a: _# y, }$ y  t4 |
$ _% `; H+ `% ]  M4 ?
  1. worker_processes 1;
    : ]% I+ J" E* s# ], T8 N
  2. events{
复制代码

3 u  L* Q4 ^$ i- {; C
: p- y9 t+ f# A" a" F: l重点在于location处,这样的配置代表的是,所有来自浏览器的请求,在Nginx收到之后,都会代理到http://192.168.1.62:8080所在的地方" n: a; l0 ^+ z$ l
# I7 F) L3 [5 {1 x
比如,我浏览器上发起http://192.168.1.61/a/index.html;Nginx收到之后,将会发出http:// 192.168.1.62:8080/a/index.html这么一个请求到所连接的服务器上,如上图的Tomcat。
% ~& i  k' v; S$ Y% q# a: Y+ a% n
" b" y+ M3 T2 Q
接下来我们做这样一个假设,假如后端连接着几台。几十台服务器呢,这个时候Nginx也是做同样的代理吗,答案是肯定的。图示如下:那么,在这么多台服务器上,Nginx的转发又是基于怎样的策略呢?这个时候就涉及在负载均衡了,说白了就是,应该怎样的分发,才能做到资源的最大限度的利用?9 [) W% @! T% c7 N2 J) f

; A5 z8 S9 Z- U; ?) s; N% X: g3 {5 t3 J# y- i# O4 H% \
6 J& z4 [2 d# G
% j8 c1 V- M! b1 H: I5 e
负载均衡策略

我们这里假设三台服务器的IP地址分别为

http:// 192.168.1.62:8080

http:// 192.168.1.63:8080

http:// 192.168.1.64:8080

1.   平均轮询

配置如下图:


, s4 ?8 Q. A' E4 r  U   a; c2 v% b+ D& j! d3 u
( H/ f  Y6 v' p( {

这里我们把后台所有的服务器放入upstream中,并在代理中进行引用。! {4 O) k( o. }' F% @

2.   加权轮询,使用weight参数设置,配置如下
; U; V+ k8 \  Q7 s9 f4 q 5 P, |- v8 p- y/ w/ G
3.   ip_hash策略  D3 R8 o* t" U$ x# \- E) b( v
(根据用户的IP地址进行hash运算,只要是同个用户发的请求,就会被永远地转发在某台服务器上,比如张三发的请求第一次时是由Tomcat1返回的,李四的是有Tomcat2返回的,那么,以后张三的所有请求,都有由Tomcat1返回,这就是ip_hash策略),配置如下:  W9 X4 ~7 T' Q$ [; }
其他地方保持不变,在upstreaem中如下设置:
9 {5 J: G) ~. v1 `! D8 E( ^" v/ P
# W  h' B  `* J7 ^

( P3 o1 B) @! ?' j3 e4 X4 {' S
2 {3 h5 B% @$ d! x7 o1 U4.   fair策略
0 K' v' W) V" G  J# z) X7 U(动态weight策略,我们的加权轮询是显式指定weight的,而fair策略是根据服务器的响应能力进行动态指定的,而意义上讲,我觉得是更为智能化的解决方法,不过这里要记住一点,fair策略是一个第三方策略)
, F& Z) g& ?; t6 f5.   url_hash策略' G: {1 P1 f7 J. r7 [5 v

: I  ]3 x, R. d( m(类似于ip,只不过绑定的值是url,这个也是第三方策略)# z/ R! m( i( U; R" V
fair策略与url_hash策略的配置与ip_hash策略的类似,直接把upstream tomcats 中的ip_hash替换为fair和url_hash即可,不过这里需要注意的是fair和url_hash都是第三方扩展,因此需要先安装第三方扩展模块,直接百度搜索nginx-upstream-fair-master.zip与upstream-url-hash -master.zip;解压安装使用make&&make install重新编译源文件即可% o* ^( D+ Q$ J# U8 k  q

9 e0 I1 F* B- I* c# T1 J  Y" B& C: }$ Y# u
/ Z2 h& i' i5 f& S: T
url_hash策略的用处?
( n: ~" [. Z7 Q
& p, d* D& D. N/ t3 B% `6 nurl_hash策略比较适合于大型电子商务网站,对于不同的商品便是不同的url,我们可以据此进行负载均衡。
2 g+ ?" ^2 t% |; o' Q% B2 s6 B9 G0 {) H1 D+ Q, i# J5 p
原理就是不同的商品形成不同的静态页面,然后服务器根据不同商品的火爆程度,按照命中率高的放在缓存里,加快访问速度,也就是说实现了一个基于缓存的服务器,相当于把有限的缓存最优化起来;" r( j' Q  |% H

7 l! ^7 a: Q$ ?* \% K* Y! ]7 o5 @& d
( A/ |+ T9 h& Z
其他的配置
. d5 |# v, n# E, H3 c  i备份与停机状态:
# S2 p* L% x1 W0 x7 zserver 192.168.1.64 backup;//备份,不参与转发,只有当所有服务器都挂掉时才参与转发;
/ f) S1 T7 E2 T; v4 D8 N$ w4 d& H. v* `/ L' s( Q
server 192.168.1.65 down;//临时停机维护,不参与任何转发,是关闭状态,
5 P$ E# w$ S. x$ Y, z
& {0 f0 j$ {2 b' W$ }1 }0 }down存在的意义在于,有时我们需要对服务器做临时停机更新维护,假如我们直接关闭服务器的话,那么对于Nginx来说,他还是会把请求发到该服务器上的,因为他并不知道服务器已关,而设置down后,Nginx则不会再发到该服务器上了,避免造成无用的请求浪费。/ F8 V, g  v: e2 q4 M
" _& c3 M. |! R" M3 f4 q% J
7 ~1 C8 |# y. z/ k# U$ s1 x! V
' f7 i9 f. y, w( d
max_fails:        达到指定次数后认为服务器挂掉. e/ d$ ?7 G3 U, Y3 T

" [* o5 R& B; d fail_timeout:挂掉多久后再次测试是否已经挂掉3 e9 }1 A& z! X3 T0 v1 j% q( H+ U
" X- c9 |, t* ?% |# k4 r
配置命令) d& }; n$ U; \$ `
  Q7 Q9 ^) [2 D* F9 v
server 192.168.1.66 max_fails=2 fail_timeout=60s;
5 |7 x& D& N7 k1 W1 v2 p+ f. w( R2 g! K* X. m' O' ]. {$ U" }+ C8 R
后记3 o' V( y/ o( J3 y0 R$ S
我们知道,服务器是会存储用户的session的,那么,如果按照上文所说的,比如fair策略,每次Nginx会根据后端服务器群的能力把请求分发出去,那假如第一次时分在了A,那么我把数据存储到了A服务器上,第二次时,刚好被分配到了B服务器上,那么问题来了,我的session不就不见了?(这就是我们在访问部分网站时有时我们的登录状态会不见)当然了,你可能 会说,ip_hash策略不就可以避免这一点吗?没错,这确实是一个解决方法,那除了ip_hash呢?其他策略下又当如何呢?下篇博客将会讲到负载均衡下如何对session进行处理。1 o6 h& Y  q  T2 |0 v* m1 q

' B7 e" N9 F- t9 R6 w2 {9 q8 B6 O* @: g* L- C, H& h2 e" T
5 e, R4 p% e6 z* a

% f* t: c: {0 j$ j' y
5 H7 Q3 K: ^0 v




欢迎光临 cncml手绘网 (http://www.cncml.com/) Powered by Discuz! X3.2