Nginx的负载均衡是基于反向代理实现的,因此,本文先讨论什么是反向代理,再在这个的基础上讨论负载均衡以及负载均衡时应该注意哪些策略。 反向代理:如下图所示, 8 Z7 a* l* ~0 U5 K
↓-----Nginx将结果返回给浏览器---丨 对Tomcat来说,只知道服务对象是Nginx服务器 浏览器 -发起对该域的访问请求-> Nginx --------------Nginx将请求来转发给Tomcat服务器----> Tomcat... 丨-对Tomcat来说,只对nginx负责,将结果返回给Nginx服务器---↑ - L4 O" g' \# G- ^5 U
从图中,我们可以知道,对于浏览器来说,他会发一个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的这么一个过程便称为反向代理。
! }# A$ n+ x' v' Z: t
$ b% _" Q; [8 r那么,Nginx服务器是如何实现这一步的呢,事实上也很简单,只需要在location中做一下简单的配置即可,命令大概如下图所示:(配置完命令记得reload重新加载才能生效)
8 ? H, l% z5 X. _% {% J) L/ m4 {1 ^2 Y; d+ ^6 f7 O
4 E' L' v- i, S) O# F3 B- worker_processes 1;
% ~& n9 u4 A# i; _8 m# d8 z - events{
复制代码
+ X% h4 i- ~; g1 l# E& z$ r' p$ M7 W+ `% R+ \- W6 b# X v/ F
重点在于location处,这样的配置代表的是,所有来自浏览器的请求,在Nginx收到之后,都会代理到http://192.168.1.62:8080所在的地方& [1 p8 f6 M: {' S/ V( B0 g, w
# B. x* u( }1 L4 L( L: m, d比如,我浏览器上发起http://192.168.1.61/a/index.html;Nginx收到之后,将会发出http:// 192.168.1.62:8080/a/index.html这么一个请求到所连接的服务器上,如上图的Tomcat。/ j1 F$ C4 Y S( w1 ^
- O. |8 g: v& m, D3 c: |
4 x* P) ]1 B2 |( n$ T/ U1 \) l1 |
接下来我们做这样一个假设,假如后端连接着几台。几十台服务器呢,这个时候Nginx也是做同样的代理吗,答案是肯定的。图示如下:那么,在这么多台服务器上,Nginx的转发又是基于怎样的策略呢?这个时候就涉及在负载均衡了,说白了就是,应该怎样的分发,才能做到资源的最大限度的利用?: p* R9 e" F# m! u1 K7 H0 v7 }
* y- j/ ~& S, s. M! M
' [5 n/ A+ m2 @: s) c) O& H
p4 `* }) R1 P: @5 q: L
' Y$ c7 Q; a* m- j
负载均衡策略( 我们这里假设三台服务器的IP地址分别为 http:// 192.168.1.62:8080 http:// 192.168.1.63:8080 http:// 192.168.1.64:8080 ) 1. 平均轮询配置如下图:
( p# m! ~1 X6 O! B1 n) g7 a
! Y/ \2 R' l$ U: q" t6 K( @; R8 L! R# ` p) h2 C; n* J& T$ {* z
这里我们把后台所有的服务器放入upstream中,并在代理中进行引用。
( l) ?0 o4 q6 Z+ [9 k5 R3 G 2. 加权轮询,使用weight参数设置,配置如下7 `% _+ E( \! s! Z( _
2 a7 q" H! v }- T# V& J" ?
3. ip_hash策略
. F& X8 z8 `: | P* m4 N* n5 a7 U) h(根据用户的IP地址进行hash运算,只要是同个用户发的请求,就会被永远地转发在某台服务器上,比如张三发的请求第一次时是由Tomcat1返回的,李四的是有Tomcat2返回的,那么,以后张三的所有请求,都有由Tomcat1返回,这就是ip_hash策略),配置如下:& P/ F+ T+ w8 q
其他地方保持不变,在upstreaem中如下设置:
, t" Y }: {: Z' h7 @+ S+ T5 U3 S n* b# y+ J, J Z
4 [2 E( d* ]& O
: B: ~/ @. |0 V7 F: @0 V' N, N* n& [
4. fair策略$ ~' |; {# J! }- F1 ^! Q
(动态weight策略,我们的加权轮询是显式指定weight的,而fair策略是根据服务器的响应能力进行动态指定的,而意义上讲,我觉得是更为智能化的解决方法,不过这里要记住一点,fair策略是一个第三方策略)
% R; O% F. X0 j5. url_hash策略! q4 j, V/ o3 h, s4 |
7 K( F. }1 A) |9 z
(类似于ip,只不过绑定的值是url,这个也是第三方策略)0 ?, z7 f# H$ [% [
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重新编译源文件即可- G$ k$ S/ J1 c t
; D2 P; S. G. ?* L3 n+ i5 Z
$ h7 z8 w" _( K6 k9 I* {* z
4 w4 k* H, @- s: S/ [, }# b) n: u. Y# x* turl_hash策略的用处?
! |! g' g2 _. Q! N, L: h3 \6 n$ z% e0 N3 r
url_hash策略比较适合于大型电子商务网站,对于不同的商品便是不同的url,我们可以据此进行负载均衡。: f0 i6 l, T9 p& q7 m5 T
8 d' ~) v* L$ o原理就是不同的商品形成不同的静态页面,然后服务器根据不同商品的火爆程度,按照命中率高的放在缓存里,加快访问速度,也就是说实现了一个基于缓存的服务器,相当于把有限的缓存最优化起来;; N, H: [; F. Y8 H7 S8 N
' l3 n* G* \: w' s1 _- b6 s! F0 ?7 e( P9 G/ i3 L
! I8 \! u% b& |+ Q* U
其他的配置: u( b- u* Z9 \& e% @; e; ^
备份与停机状态:& N7 N7 h+ M/ f$ u6 }
server 192.168.1.64 backup;//备份,不参与转发,只有当所有服务器都挂掉时才参与转发;* Z: y9 V& U2 l7 ?2 D+ ]
# O. L& D1 |8 s+ C4 o& v1 h
server 192.168.1.65 down;//临时停机维护,不参与任何转发,是关闭状态,( @7 b6 t8 w7 q$ s( L) F
" S+ B& B/ n' L
down存在的意义在于,有时我们需要对服务器做临时停机更新维护,假如我们直接关闭服务器的话,那么对于Nginx来说,他还是会把请求发到该服务器上的,因为他并不知道服务器已关,而设置down后,Nginx则不会再发到该服务器上了,避免造成无用的请求浪费。' J( j/ c3 K, H3 s4 V' W) S) F0 C: T
' T [8 c- O/ y, s" S: C& L& n9 K3 _" ~. F
: S$ g; U; w2 K4 t6 d8 E
max_fails: 达到指定次数后认为服务器挂掉
: E5 Y3 k) m; Z6 y2 `, _5 T- P9 g3 T/ _ a7 @( Y
fail_timeout:挂掉多久后再次测试是否已经挂掉; g* z l- }3 F# Y8 H* {, O/ y4 o
# P. c! g" ^& X u1 F+ z, `9 z8 t配置命令
3 e" O% ^& @$ O! a
* K! q8 w( E- }) Z0 |4 ^6 Nserver 192.168.1.66 max_fails=2 fail_timeout=60s;. c1 n8 Y# [; x6 F, o+ O5 l
* ], _: j& E' c
后记
" v/ _4 y( T' C' [8 p! N# I+ z" p我们知道,服务器是会存储用户的session的,那么,如果按照上文所说的,比如fair策略,每次Nginx会根据后端服务器群的能力把请求分发出去,那假如第一次时分在了A,那么我把数据存储到了A服务器上,第二次时,刚好被分配到了B服务器上,那么问题来了,我的session不就不见了?(这就是我们在访问部分网站时有时我们的登录状态会不见)当然了,你可能 会说,ip_hash策略不就可以避免这一点吗?没错,这确实是一个解决方法,那除了ip_hash呢?其他策略下又当如何呢?下篇博客将会讲到负载均衡下如何对session进行处理。 D4 U! ]0 V8 h/ C+ Z2 Y
& P7 B/ H! q7 Q# y
1 `* [, k3 o$ e. _! |4 H. B
" @. C3 ?( Z1 y. P8 \ d, F0 M7 `0 ]/ \* O5 l2 `
. N" s$ Z, M! X' v0 }
|