Nginx的负载均衡是基于反向代理实现的,因此,本文先讨论什么是反向代理,再在这个的基础上讨论负载均衡以及负载均衡时应该注意哪些策略。 反向代理:如下图所示,
+ \) ?' h5 T4 a- W' `9 Q
↓-----Nginx将结果返回给浏览器---丨 对Tomcat来说,只知道服务对象是Nginx服务器 浏览器 -发起对该域的访问请求-> Nginx --------------Nginx将请求来转发给Tomcat服务器----> Tomcat... 丨-对Tomcat来说,只对nginx负责,将结果返回给Nginx服务器---↑ / }5 K9 V/ b0 P( z- q$ V6 k9 f
从图中,我们可以知道,对于浏览器来说,他会发一个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的这么一个过程便称为反向代理。3 u: f3 ~* c6 \8 P/ c W, v
- H: u; _+ o4 |+ M8 B4 p那么,Nginx服务器是如何实现这一步的呢,事实上也很简单,只需要在location中做一下简单的配置即可,命令大概如下图所示:(配置完命令记得reload重新加载才能生效)
8 c6 S* b u$ J% y6 t4 \# ^# n7 [$ k& A% H) ]; J
5 } P9 g; ]: v" h
- worker_processes 1;
G2 v. A! e+ V) } - events{
复制代码
& |. w* w2 o5 l/ Y
& g d/ A W' b0 I' G' h0 y- E重点在于location处,这样的配置代表的是,所有来自浏览器的请求,在Nginx收到之后,都会代理到http://192.168.1.62:8080所在的地方* |* f- p4 O5 L5 L# D/ i
8 ], e% b u! _0 t) \6 W比如,我浏览器上发起http://192.168.1.61/a/index.html;Nginx收到之后,将会发出http:// 192.168.1.62:8080/a/index.html这么一个请求到所连接的服务器上,如上图的Tomcat。- Z" ?8 ^/ }* q% T: S% s
1 M. L! y' d6 d/ V/ D* j6 C
$ ?5 M$ q! O: v1 _' j) V$ D) d- G接下来我们做这样一个假设,假如后端连接着几台。几十台服务器呢,这个时候Nginx也是做同样的代理吗,答案是肯定的。图示如下:那么,在这么多台服务器上,Nginx的转发又是基于怎样的策略呢?这个时候就涉及在负载均衡了,说白了就是,应该怎样的分发,才能做到资源的最大限度的利用?
1 ?6 ~( K: B5 @1 h! n" F( Y
+ p" E2 l9 t2 S" u8 P8 T1 l4 d5 \ R7 \" |3 Y- A; q [
8 u# A# j! N E7 D* x
n3 Z& A) L$ g( M3 s- M, F
负载均衡策略( 我们这里假设三台服务器的IP地址分别为 http:// 192.168.1.62:8080 http:// 192.168.1.63:8080 http:// 192.168.1.64:8080 ) 1. 平均轮询配置如下图: 5 a( v& W' N% t# r8 h7 K
! Z" m( d/ s/ A8 \6 o( Z+ B% J% ]+ s9 [# V% t
这里我们把后台所有的服务器放入upstream中,并在代理中进行引用。
) V% K# Y- `5 S4 |3 { 2. 加权轮询,使用weight参数设置,配置如下
: C2 w$ ]1 B6 h: L6 _3 s
" Q3 z; l' E1 ]% Q3. ip_hash策略
9 w! L3 p5 k& K5 b" w$ t(根据用户的IP地址进行hash运算,只要是同个用户发的请求,就会被永远地转发在某台服务器上,比如张三发的请求第一次时是由Tomcat1返回的,李四的是有Tomcat2返回的,那么,以后张三的所有请求,都有由Tomcat1返回,这就是ip_hash策略),配置如下:
- n; X& G. \% T/ o. q5 q' ^+ B8 p 其他地方保持不变,在upstreaem中如下设置:# r9 |. p1 o0 [; K, `
! F6 v: z( R& k6 ^" t
' N; [5 H5 A) h0 O: p# d! V
1 o' H: g- l9 o
0 R1 g$ @4 J+ ]4. fair策略
4 e' a# B1 b1 j(动态weight策略,我们的加权轮询是显式指定weight的,而fair策略是根据服务器的响应能力进行动态指定的,而意义上讲,我觉得是更为智能化的解决方法,不过这里要记住一点,fair策略是一个第三方策略)
: k" r: G8 C' F' w- }0 J5 `5. url_hash策略7 O2 ^7 V6 P! B, e/ B0 T# i
+ _; E3 w6 Z) j" K8 T; w3 J
(类似于ip,只不过绑定的值是url,这个也是第三方策略)
' `% i/ @3 k+ [+ d8 [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重新编译源文件即可$ u: {, D5 I. R0 N2 x4 G- T
* P. `0 |2 M% y7 }6 @* k
5 L! j% h' M' L2 ^6 y9 d1 @+ ^2 Z- |; G# q0 m9 p1 w
url_hash策略的用处?% f C, ^& |- F% w% N
2 H) H; R. C+ A7 Q9 b, C! F+ surl_hash策略比较适合于大型电子商务网站,对于不同的商品便是不同的url,我们可以据此进行负载均衡。
' Z! k$ a3 B+ V. H! S" y# u( x! d+ W5 [/ Y! f. S6 R4 P& M
原理就是不同的商品形成不同的静态页面,然后服务器根据不同商品的火爆程度,按照命中率高的放在缓存里,加快访问速度,也就是说实现了一个基于缓存的服务器,相当于把有限的缓存最优化起来;2 k! o2 x1 {' s" t$ Q! M$ H
5 }. T( ^4 W' s B: r0 N6 b o7 n7 p# Y R* z. p s* T
& e- k; ^3 y4 m0 F5 J) T
其他的配置
, t( [* Z& r5 T备份与停机状态:
* D N* m4 B' M8 T c& p$ r5 J# y g/ @server 192.168.1.64 backup;//备份,不参与转发,只有当所有服务器都挂掉时才参与转发;
: I; F( S8 P' [4 P& y9 w! p3 j: k/ U4 l# l3 I& X) A2 o1 u8 s
server 192.168.1.65 down;//临时停机维护,不参与任何转发,是关闭状态,0 K+ s. a3 ^( G- s$ `* ^8 b+ b+ ?+ i
0 V9 @( p2 y8 A, e) [/ D8 [6 c5 V
down存在的意义在于,有时我们需要对服务器做临时停机更新维护,假如我们直接关闭服务器的话,那么对于Nginx来说,他还是会把请求发到该服务器上的,因为他并不知道服务器已关,而设置down后,Nginx则不会再发到该服务器上了,避免造成无用的请求浪费。2 o- h) K% b0 |/ |5 W- [
) Y. J) N( G; {. f" u( r
8 w: P9 `0 Z1 _( ?. L
D" `; f: |! Q
max_fails: 达到指定次数后认为服务器挂掉
, B0 m2 O h6 n
& D7 Z& n0 L9 x1 @ fail_timeout:挂掉多久后再次测试是否已经挂掉
! ?- r _* m/ F; k/ J: x. h9 t. D$ ?4 @$ @5 F8 S# a
配置命令2 I) V7 O* ]) {" G, `
- w5 k# P( V' s: U, _" d( [" u! Y. O6 X: m
server 192.168.1.66 max_fails=2 fail_timeout=60s;
$ E& u H1 Y3 C: D0 X9 U+ b( X, o: a; l: b, L4 t8 f @; R+ O' M
后记; v3 X5 A& w. [# G6 `: T- Y
我们知道,服务器是会存储用户的session的,那么,如果按照上文所说的,比如fair策略,每次Nginx会根据后端服务器群的能力把请求分发出去,那假如第一次时分在了A,那么我把数据存储到了A服务器上,第二次时,刚好被分配到了B服务器上,那么问题来了,我的session不就不见了?(这就是我们在访问部分网站时有时我们的登录状态会不见)当然了,你可能 会说,ip_hash策略不就可以避免这一点吗?没错,这确实是一个解决方法,那除了ip_hash呢?其他策略下又当如何呢?下篇博客将会讲到负载均衡下如何对session进行处理。
5 ]7 ^6 s# C+ I3 G: ~. y: V+ D
+ d* w2 i$ t) h4 x6 a# K: k" x
5 E! w9 L/ E1 z# A E" q) c9 [0 O5 i i- e" v. |. Z" B) c$ c
+ B: {( A0 C5 T
7 l1 c( w9 Z9 \2 K3 C |