cncml手绘网
标题: 浅谈Nginx之反向代理与负载均衡 [打印本页]
作者: admin 时间: 2020-2-25 23:05
标题: 浅谈Nginx之反向代理与负载均衡
Nginx的负载均衡是基于反向代理实现的,因此,本文先讨论什么是反向代理,再在这个的基础上讨论负载均衡以及负载均衡时应该注意哪些策略。
反向代理:如下图所示,
; x) e h4 d; v( i; f
↓-----Nginx将结果返回给浏览器---丨 对Tomcat来说,只知道服务对象是Nginx服务器
浏览器 -发起对该域的访问请求-> Nginx --------------Nginx将请求来转发给Tomcat服务器----> Tomcat...
丨-对Tomcat来说,只对nginx负责,将结果返回给Nginx服务器---↑
4 D2 ^0 T$ O& H5 J从图中,我们可以知道,对于浏览器来说,他会发一个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的这么一个过程便称为反向代理。
- R( B% ?2 M3 N5 ^7 }3 N9 a& j6 ^2 o# @) @* s- i! \( E1 x
那么,Nginx服务器是如何实现这一步的呢,事实上也很简单,只需要在location中做一下简单的配置即可,命令大概如下图所示:(配置完命令记得reload重新加载才能生效)
- `# U! i! G3 b
2 I' L, e0 y& e2 T; ?% j8 N- ^ `& g2 Y2 |$ S' O0 ?; G- T
- worker_processes 1;
5 ]& k: r/ Z" t+ p6 |5 [ v! C - events{
复制代码 4 F( m' a8 s( q% G
' a @" p5 H# c9 s* z
重点在于location处,这样的配置代表的是,所有来自浏览器的请求,在Nginx收到之后,都会代理到http://192.168.1.62:8080所在的地方7 g- d$ f( w. B6 L! Q1 I# s. W
/ V6 |8 n- T; ]* c; a6 J) `比如,我浏览器上发起http://192.168.1.61/a/index.html;Nginx收到之后,将会发出http:// 192.168.1.62:8080/a/index.html这么一个请求到所连接的服务器上,如上图的Tomcat。
/ X5 t( C) u1 s! {
2 O, d+ }" n0 t- J' W; Q
* d: T5 [. v- a/ A* i [# B接下来我们做这样一个假设,假如后端连接着几台。几十台服务器呢,这个时候Nginx也是做同样的代理吗,答案是肯定的。图示如下:那么,在这么多台服务器上,Nginx的转发又是基于怎样的策略呢?这个时候就涉及在负载均衡了,说白了就是,应该怎样的分发,才能做到资源的最大限度的利用?
. O! |8 K8 C7 f. x% D# a8 Y( X. b- O, s; G) i
# r9 A; {$ i7 _5 a4 { {2 q
4 G" v, O! f5 z# u8 u
! C5 W& @8 D! N4 f9 [/ |5 W0 B
负载均衡策略(
我们这里假设三台服务器的IP地址分别为
http:// 192.168.1.62:8080
http:// 192.168.1.63:8080
http:// 192.168.1.64:8080
)
1. 平均轮询配置如下图:
9 w/ E; t5 b" m# _
6 ], ?! v- c- t- h1 ~! w. D- U. n
1 n6 n9 P1 N% X# z3 x( m+ N这里我们把后台所有的服务器放入upstream中,并在代理中进行引用。
4 I. I3 \# N* K7 R, |$ y& a/ t
2. 加权轮询,使用weight参数设置,配置如下
; {5 {0 f, V8 @$ P1 m' F
# O' r1 |* H) ~; a* P
3. ip_hash策略
; p: f; ?& e/ \) D |2 M(根据用户的IP地址进行hash运算,只要是同个用户发的请求,就会被永远地转发在某台服务器上,比如张三发的请求第一次时是由Tomcat1返回的,李四的是有Tomcat2返回的,那么,以后张三的所有请求,都有由Tomcat1返回,这就是ip_hash策略),配置如下:
" n8 B$ S4 T7 g2 J: w. \" t 其他地方保持不变,在upstreaem中如下设置:/ `$ F6 G: H2 a/ X2 `# ^7 B
4 W! w+ r+ Y9 M, ?* X
5 E' H6 l' [$ P8 ]% B4 p3 S
: k: k2 I$ l, w1 [* ~2 n g
9 z) e6 w3 ]8 x; Y. P
4. fair策略# e6 [# E9 m# ?3 ]3 f* c( J
(动态weight策略,我们的加权轮询是显式指定weight的,而fair策略是根据服务器的响应能力进行动态指定的,而意义上讲,我觉得是更为智能化的解决方法,不过这里要记住一点,fair策略是一个第三方策略)
L- ]6 q- z1 h: Q2 ?2 w5. url_hash策略
( s( C2 z. o' J: |! ]
( N3 a; g; f3 M i0 A! q(类似于ip,只不过绑定的值是url,这个也是第三方策略)
) T U2 b2 R. M3 bfair策略与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重新编译源文件即可
; V2 l ]2 H x) `0 O! r) Y, X
9 @3 W0 q. m4 I, q& Z" k* A2 o5 R0 l+ L
- B/ ]8 {% e7 y0 D- o7 D, curl_hash策略的用处? ~0 w0 G$ `! o9 @$ n( ?
' |, ]) e4 l$ W. }2 \7 w( R) v$ furl_hash策略比较适合于大型电子商务网站,对于不同的商品便是不同的url,我们可以据此进行负载均衡。
4 ]- m7 `/ m' }0 y" @ O; B3 j2 u" C
原理就是不同的商品形成不同的静态页面,然后服务器根据不同商品的火爆程度,按照命中率高的放在缓存里,加快访问速度,也就是说实现了一个基于缓存的服务器,相当于把有限的缓存最优化起来;
- _8 m) d, T% v7 `! X# C2 \- F" S( Y1 B4 ]% S# O
2 j4 R0 a6 v$ }- k' B/ w4 Z5 e
8 | {- k! d" c0 u4 c其他的配置8 h/ \; d' i. `/ O" \) {' \
备份与停机状态:5 a, {# c* l. W. z3 m# t2 T
server 192.168.1.64 backup;//备份,不参与转发,只有当所有服务器都挂掉时才参与转发;) {/ x6 Y* U; h# ?, s& H$ T u
) C; v+ @" l8 v: P2 y; v
server 192.168.1.65 down;//临时停机维护,不参与任何转发,是关闭状态,
, D6 U+ n/ J. [/ P2 ]/ B( n
8 ?' c1 E# `, b; L! O5 l9 wdown存在的意义在于,有时我们需要对服务器做临时停机更新维护,假如我们直接关闭服务器的话,那么对于Nginx来说,他还是会把请求发到该服务器上的,因为他并不知道服务器已关,而设置down后,Nginx则不会再发到该服务器上了,避免造成无用的请求浪费。
# }/ V4 H+ R8 @5 D/ w% U2 `
, L, }& J& ?+ s Y) j4 e# i' @
! \$ V+ O u. N+ l! X8 q* t0 R# J G
- a2 f7 S9 m% r* smax_fails: 达到指定次数后认为服务器挂掉
6 A% n. Q( c5 G$ h. f$ M. Y% U# L4 D9 P& | ~) n0 j. W
fail_timeout:挂掉多久后再次测试是否已经挂掉
1 N) K3 Q+ E7 e% I' M, L
$ ]) C+ @2 w, F4 A0 R% e1 \配置命令
( F. h* r, e5 [/ m! |+ |( Q s
6 q; Z, U0 A; r7 Tserver 192.168.1.66 max_fails=2 fail_timeout=60s;
- r1 M6 Z( q7 D9 h6 |: L4 g" x4 R- S" H
后记
6 T& j7 {# m* p; C我们知道,服务器是会存储用户的session的,那么,如果按照上文所说的,比如fair策略,每次Nginx会根据后端服务器群的能力把请求分发出去,那假如第一次时分在了A,那么我把数据存储到了A服务器上,第二次时,刚好被分配到了B服务器上,那么问题来了,我的session不就不见了?(这就是我们在访问部分网站时有时我们的登录状态会不见)当然了,你可能 会说,ip_hash策略不就可以避免这一点吗?没错,这确实是一个解决方法,那除了ip_hash呢?其他策略下又当如何呢?下篇博客将会讲到负载均衡下如何对session进行处理。! W) y$ P7 K3 r5 S
. A. W- |! |( }- {
: t( J I( q0 C6 E% q, z* M) o) H0 r7 e1 {0 \+ N* u2 z
( H# v) T0 x3 f- X1 i# Q7 v
& @) l3 H& v7 f( @" N& S" d
| 欢迎光临 cncml手绘网 (http://www.cncml.com/) |
Powered by Discuz! X3.2 |