cncml手绘网
标题: 浅谈Nginx之反向代理与负载均衡 [打印本页]
作者: admin 时间: 2020-2-25 23:05
标题: 浅谈Nginx之反向代理与负载均衡
Nginx的负载均衡是基于反向代理实现的,因此,本文先讨论什么是反向代理,再在这个的基础上讨论负载均衡以及负载均衡时应该注意哪些策略。
反向代理:如下图所示,
5 K# v- g* v3 N4 R7 G
↓-----Nginx将结果返回给浏览器---丨 对Tomcat来说,只知道服务对象是Nginx服务器
浏览器 -发起对该域的访问请求-> Nginx --------------Nginx将请求来转发给Tomcat服务器----> Tomcat...
丨-对Tomcat来说,只对nginx负责,将结果返回给Nginx服务器---↑
: e* ^9 I7 H# F6 ?( q$ {从图中,我们可以知道,对于浏览器来说,他会发一个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的这么一个过程便称为反向代理。9 P' i5 o" r, b! n+ R
- Q) f) a/ p2 \3 n! ~. d" V# F ?
那么,Nginx服务器是如何实现这一步的呢,事实上也很简单,只需要在location中做一下简单的配置即可,命令大概如下图所示:(配置完命令记得reload重新加载才能生效)0 ~' m3 @3 C# c+ V
1 `. ~7 ^) g1 \$ P
: X3 c$ Z* T* E4 @% Y: I% K
- worker_processes 1;/ u& h+ e: J* F+ l* o
- events{
复制代码 2 n6 ~4 \- u& b1 I" `
8 m- v( @# d( Y4 z% p0 y
重点在于location处,这样的配置代表的是,所有来自浏览器的请求,在Nginx收到之后,都会代理到http://192.168.1.62:8080所在的地方& M3 x+ y: Y5 ` f- I
( i3 X6 D+ k4 L v8 v
比如,我浏览器上发起http://192.168.1.61/a/index.html;Nginx收到之后,将会发出http:// 192.168.1.62:8080/a/index.html这么一个请求到所连接的服务器上,如上图的Tomcat。
) N+ |3 \7 S! d( P: \3 N$ N w P$ p6 O$ B! s+ t0 ^8 K$ h
$ `, S @6 I! \( `# {' G5 x
接下来我们做这样一个假设,假如后端连接着几台。几十台服务器呢,这个时候Nginx也是做同样的代理吗,答案是肯定的。图示如下:那么,在这么多台服务器上,Nginx的转发又是基于怎样的策略呢?这个时候就涉及在负载均衡了,说白了就是,应该怎样的分发,才能做到资源的最大限度的利用?
2 J5 D% K8 y$ A' l3 h- @0 W0 u. Q9 m* _. l) O8 e! U3 F
* I: F) H7 A7 Z: J( Q7 d
7 c" S! C4 B/ ^" J$ w1 B4 z [
. ~& h3 S1 _+ @7 a! x- f
负载均衡策略(
我们这里假设三台服务器的IP地址分别为
http:// 192.168.1.62:8080
http:// 192.168.1.63:8080
http:// 192.168.1.64:8080
)
1. 平均轮询配置如下图:
3 [1 K) D! j: J& ^5 H/ V+ G
+ n0 Y7 W! P- m4 b6 S4 ^3 x, y/ j, D. B4 u
这里我们把后台所有的服务器放入upstream中,并在代理中进行引用。 k. l' z# j$ f5 d; |9 `2 O$ K
2. 加权轮询,使用weight参数设置,配置如下 o; ]& E' M' x7 D. S |
& M8 {6 ^$ X1 u) X3 m( a, N+ ?3. ip_hash策略/ q: W+ v! c* ?/ c& Z
(根据用户的IP地址进行hash运算,只要是同个用户发的请求,就会被永远地转发在某台服务器上,比如张三发的请求第一次时是由Tomcat1返回的,李四的是有Tomcat2返回的,那么,以后张三的所有请求,都有由Tomcat1返回,这就是ip_hash策略),配置如下:- E5 b x7 z* G* n- R. R) H. q
其他地方保持不变,在upstreaem中如下设置:
9 m9 P6 [7 r# ~, T2 n1 o) n4 n3 v! M0 W! ]0 [" ]+ `# a
, s2 T/ R) J0 o9 {& \) K) ?
& }6 ~, K" N- y+ e( h) R# a1 R0 ? w. n4 X( z
4. fair策略: J. W( G* t5 U$ J- u( i( @
(动态weight策略,我们的加权轮询是显式指定weight的,而fair策略是根据服务器的响应能力进行动态指定的,而意义上讲,我觉得是更为智能化的解决方法,不过这里要记住一点,fair策略是一个第三方策略)
f- t# W$ {7 A; O9 c5. url_hash策略3 ]$ N( }4 ^* n3 y
/ o- B+ V2 Y4 j8 E* p1 w4 I5 t
(类似于ip,只不过绑定的值是url,这个也是第三方策略)2 B" x+ z% {) V! x1 [2 Q
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重新编译源文件即可
1 C# u8 \7 A0 s% D
2 [7 H7 c; F; P* C+ j* u7 y! n1 n( B' }5 P' Q
5 @+ B u4 ]: E
url_hash策略的用处?7 U. x" c$ H# q/ a5 ?2 o
* A- y. r( f6 y1 a4 F
url_hash策略比较适合于大型电子商务网站,对于不同的商品便是不同的url,我们可以据此进行负载均衡。 X# y' \5 A* @! X4 z5 I# U* V1 U
, Q0 N, y9 l3 }' }
原理就是不同的商品形成不同的静态页面,然后服务器根据不同商品的火爆程度,按照命中率高的放在缓存里,加快访问速度,也就是说实现了一个基于缓存的服务器,相当于把有限的缓存最优化起来;% n! f; ?* ~" U& o b0 {. g
* F& z: ]7 |! q& A* r% b8 Q$ H$ E+ D3 c4 @, w% o9 P
8 ^, Z, A3 X) x- R+ b6 p# ]
其他的配置
, P) {/ g9 D0 o J备份与停机状态:
* S* e. f' k# Jserver 192.168.1.64 backup;//备份,不参与转发,只有当所有服务器都挂掉时才参与转发;4 b! u% x/ w, y! ^7 x$ f( }
# `% z2 \# |9 d0 Z8 X% P
server 192.168.1.65 down;//临时停机维护,不参与任何转发,是关闭状态,
! L! m1 d+ p) S' M/ p3 G
u- D0 f( _. E- {6 R2 ]2 _5 N* Zdown存在的意义在于,有时我们需要对服务器做临时停机更新维护,假如我们直接关闭服务器的话,那么对于Nginx来说,他还是会把请求发到该服务器上的,因为他并不知道服务器已关,而设置down后,Nginx则不会再发到该服务器上了,避免造成无用的请求浪费。
; a, L1 C8 L3 L) R# ~% \' L6 a6 @1 w
; ~6 @: K" I$ A$ j+ d/ k3 q3 |. G, @/ q
% q5 n/ g! \0 K- E5 C9 F! Lmax_fails: 达到指定次数后认为服务器挂掉
6 g n- n9 ]. O7 w% f6 G: F. X2 a
fail_timeout:挂掉多久后再次测试是否已经挂掉' [, Y% m: R% B
+ o/ y: x& l/ B- M6 P) |- M配置命令& z& K0 B: i* U$ I
" D. u6 D4 m3 l+ \server 192.168.1.66 max_fails=2 fail_timeout=60s;% N @5 h7 G) I: g
7 c4 Q, i& x( _
后记: }, A! j2 E& T0 \7 K4 \
我们知道,服务器是会存储用户的session的,那么,如果按照上文所说的,比如fair策略,每次Nginx会根据后端服务器群的能力把请求分发出去,那假如第一次时分在了A,那么我把数据存储到了A服务器上,第二次时,刚好被分配到了B服务器上,那么问题来了,我的session不就不见了?(这就是我们在访问部分网站时有时我们的登录状态会不见)当然了,你可能 会说,ip_hash策略不就可以避免这一点吗?没错,这确实是一个解决方法,那除了ip_hash呢?其他策略下又当如何呢?下篇博客将会讲到负载均衡下如何对session进行处理。
# R( F2 ]$ m) e1 h' p
4 y$ q" @1 Y, r* J* B" [& |5 r
0 U3 v* j2 s, e/ @2 i" D) m) K! G
5 c0 Q1 n% c/ Z
" Y+ D! b: g) o8 {) o
| 欢迎光临 cncml手绘网 (http://www.cncml.com/) |
Powered by Discuz! X3.2 |