您尚未登录,请登录后浏览更多内容! 登录 | 立即注册

QQ登录

只需一步,快速开始

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 8663|回复: 0

[centos] 浅谈Nginx之反向代理与负载均衡

[复制链接]
发表于 2020-2-25 23:05:39 | 显示全部楼层 |阅读模式

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

反向代理:

如下图所示,

2 @( d- i0 ^' b( A5 I

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

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

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

# }" w0 Y: ^; x1 z: O: |3 E
从图中,我们可以知道,对于浏览器来说,他会发一个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的这么一个过程便称为反向代理。" d% R; W+ S& W: h# {3 d

) ?+ k5 I2 ]0 B( h% b那么,Nginx服务器是如何实现这一步的呢,事实上也很简单,只需要在location中做一下简单的配置即可,命令大概如下图所示:(配置完命令记得reload重新加载才能生效); v* T9 ^7 ^0 E+ [: K3 Q- {( a
+ _, @1 T% k+ r+ G6 }/ A: \

2 h5 E2 y: _9 @5 N
  1. worker_processes 1;5 `/ o1 V, p$ A
  2. events{
复制代码

# `* K" u5 X' G. h( ]" a3 o8 j" s: M5 E$ v! g+ o1 O2 N
重点在于location处,这样的配置代表的是,所有来自浏览器的请求,在Nginx收到之后,都会代理到http://192.168.1.62:8080所在的地方9 E7 ]" A0 ^& w
' S6 y+ N+ H* \
比如,我浏览器上发起http://192.168.1.61/a/index.html;Nginx收到之后,将会发出http:// 192.168.1.62:8080/a/index.html这么一个请求到所连接的服务器上,如上图的Tomcat。
. X4 l9 l" ^  a/ O$ C% W* N' K1 }/ N) T7 Q. \

; c3 s3 y- F( M1 W9 i3 ]6 Q接下来我们做这样一个假设,假如后端连接着几台。几十台服务器呢,这个时候Nginx也是做同样的代理吗,答案是肯定的。图示如下:那么,在这么多台服务器上,Nginx的转发又是基于怎样的策略呢?这个时候就涉及在负载均衡了,说白了就是,应该怎样的分发,才能做到资源的最大限度的利用?
5 ~  H- D- o% D1 q  V9 s7 \& i5 T8 U4 N4 k
0 D* @4 X  P3 n  j8 K+ B/ W
微信截图_20200225230312.png " C* P; f8 i% ]5 [
9 @  w' a0 }! V
负载均衡策略

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

http:// 192.168.1.62:8080

http:// 192.168.1.63:8080

http:// 192.168.1.64:8080

1.   平均轮询

配置如下图:

4 G* D( Y) [) c
微信截图_20200225230312.png 4 W4 Y! e! d& R: A+ h( v' G3 F

. z; J( ~1 W! t8 ?

这里我们把后台所有的服务器放入upstream中,并在代理中进行引用。' a5 I4 n! M- V8 p" J" w

2.   加权轮询,使用weight参数设置,配置如下
& o( n+ p6 \' }8 ^6 u  h' x 微信截图_20200225230312.png ! s) n5 ?: H: L9 P) |0 I0 L
3.   ip_hash策略! k9 q1 ?- o4 R
(根据用户的IP地址进行hash运算,只要是同个用户发的请求,就会被永远地转发在某台服务器上,比如张三发的请求第一次时是由Tomcat1返回的,李四的是有Tomcat2返回的,那么,以后张三的所有请求,都有由Tomcat1返回,这就是ip_hash策略),配置如下:
: g* M6 O$ W9 l) O 其他地方保持不变,在upstreaem中如下设置:* d4 M1 z0 h3 l% x
; e  c* i; L1 n: F" P  t- n

3 V1 Z5 |7 m) F  L% |& k' x+ t 微信截图_20200225230312.png 9 O  r, n& v; ]: [

2 a/ E. X- C/ O  T: }4.   fair策略* o0 @: {  f6 O7 p+ a& H
(动态weight策略,我们的加权轮询是显式指定weight的,而fair策略是根据服务器的响应能力进行动态指定的,而意义上讲,我觉得是更为智能化的解决方法,不过这里要记住一点,fair策略是一个第三方策略)% e+ K) I& p) F! u- r
5.   url_hash策略$ _4 a8 r7 w/ h+ S0 I5 _1 ]

, T. ?4 V! E* N(类似于ip,只不过绑定的值是url,这个也是第三方策略)0 }6 _- G. L2 C* R0 K3 J0 E
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重新编译源文件即可
# J5 d) g3 a4 V, \
1 N1 t+ u+ X, v# F! o3 v+ u! K# }% l

/ a! H1 V1 `  i7 r) Z8 [url_hash策略的用处?
: t" l. E: y1 X9 _
: P/ A+ i" `& o2 G2 K+ u  Burl_hash策略比较适合于大型电子商务网站,对于不同的商品便是不同的url,我们可以据此进行负载均衡。5 p9 d# M+ o7 R! C( }
/ M! ]# y! \& W9 ]* q3 U/ z1 w
原理就是不同的商品形成不同的静态页面,然后服务器根据不同商品的火爆程度,按照命中率高的放在缓存里,加快访问速度,也就是说实现了一个基于缓存的服务器,相当于把有限的缓存最优化起来;
" a% e& U( v! e$ ?2 U# t- {+ |4 h/ G' v
. @/ `6 d1 d9 f2 A, E

% v! [/ T" p2 E2 o/ o# ^8 b其他的配置0 _/ {; G! s& o- @3 H, h
备份与停机状态:# @# L. l6 k' D- q+ k9 ~
server 192.168.1.64 backup;//备份,不参与转发,只有当所有服务器都挂掉时才参与转发;
! |! U- r* h5 o( R: K$ Z% @5 U( z* x
server 192.168.1.65 down;//临时停机维护,不参与任何转发,是关闭状态,. x& U( ^- a/ Q  ~* T
0 |/ Q& G$ o2 M0 [
down存在的意义在于,有时我们需要对服务器做临时停机更新维护,假如我们直接关闭服务器的话,那么对于Nginx来说,他还是会把请求发到该服务器上的,因为他并不知道服务器已关,而设置down后,Nginx则不会再发到该服务器上了,避免造成无用的请求浪费。: l6 Y0 e9 x% V4 B2 ^& ^* S6 T

. l9 A5 \+ p. D$ c) e# ]4 ]; f: [1 u7 q
' K3 g" j. p9 @7 M5 @1 n5 \
max_fails:        达到指定次数后认为服务器挂掉
/ M) }2 G1 Q. {5 x" J9 i
/ S* x: M! j# g# s( z fail_timeout:挂掉多久后再次测试是否已经挂掉6 `; M8 {, D: b: J4 `9 I

" Z$ \' U( j' s# Z配置命令
5 U# r1 p2 m3 V. h
+ B2 u8 i, T1 R0 G) y% q1 x3 _server 192.168.1.66 max_fails=2 fail_timeout=60s;) c: g+ N5 e3 J) K* K/ J2 Y. ^2 {
5 ~% O0 T& o# F3 x' t2 ]; G
后记. Z8 p. E) y3 R. z* [, Z6 t$ k
我们知道,服务器是会存储用户的session的,那么,如果按照上文所说的,比如fair策略,每次Nginx会根据后端服务器群的能力把请求分发出去,那假如第一次时分在了A,那么我把数据存储到了A服务器上,第二次时,刚好被分配到了B服务器上,那么问题来了,我的session不就不见了?(这就是我们在访问部分网站时有时我们的登录状态会不见)当然了,你可能 会说,ip_hash策略不就可以避免这一点吗?没错,这确实是一个解决方法,那除了ip_hash呢?其他策略下又当如何呢?下篇博客将会讲到负载均衡下如何对session进行处理。
# L, \  I& K+ B" @: W0 i
; ?0 G; k& [" w7 Y. a# t2 \4 a* u4 U2 Z" s, x

( Q' S! b7 k! R: l4 S5 v! d; F  B: C8 ~5 U' S4 n6 k

0 Y4 r- u5 m/ m( r; n# x, r
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

GMT+8, 2023-2-1 16:38 , Processed in 0.132445 second(s), 23 queries .

Copyright © 2001-2023 Powered by cncml! X3.2. Theme By cncml!