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

QQ登录

只需一步,快速开始

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 1977|回复: 0

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

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

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

反向代理:

如下图所示,

- Q' p, v  u. Q  x" w( X

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

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

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

8 g9 e2 {5 [( F; p" ^. z2 a7 w
从图中,我们可以知道,对于浏览器来说,他会发一个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的这么一个过程便称为反向代理。
0 O+ H& g7 b5 F/ t- d
7 s( V+ q; l4 ^# E& [6 Q那么,Nginx服务器是如何实现这一步的呢,事实上也很简单,只需要在location中做一下简单的配置即可,命令大概如下图所示:(配置完命令记得reload重新加载才能生效)0 L9 z) ], Y* h( q  U7 F

: d) D% w: a- t! D
# o3 y* i/ Z+ i' [. U$ t* G6 ~
  1. worker_processes 1;
    / b& Z% Y4 N% i
  2. events{
复制代码
4 U+ S+ K2 {" Y" i7 f7 {' s
: F% ^" y! R. F) l" S5 M' s  k: x% \
重点在于location处,这样的配置代表的是,所有来自浏览器的请求,在Nginx收到之后,都会代理到http://192.168.1.62:8080所在的地方) `, Y1 x4 S8 l: u, F# i& _$ T# N# R  M

. O% D+ Y+ f) ]( d7 Q/ m8 o# O比如,我浏览器上发起http://192.168.1.61/a/index.html;Nginx收到之后,将会发出http:// 192.168.1.62:8080/a/index.html这么一个请求到所连接的服务器上,如上图的Tomcat。7 X' i2 M, T0 ]; I

9 q1 S$ K$ t% o6 p! ?% {  C
9 `' o' `6 s+ Q$ l- W接下来我们做这样一个假设,假如后端连接着几台。几十台服务器呢,这个时候Nginx也是做同样的代理吗,答案是肯定的。图示如下:那么,在这么多台服务器上,Nginx的转发又是基于怎样的策略呢?这个时候就涉及在负载均衡了,说白了就是,应该怎样的分发,才能做到资源的最大限度的利用?4 T+ \8 o4 T; n! j9 U
, B* G# a" E* @* F6 q
9 C' h  R8 d( b" l$ h1 c7 c9 d
微信截图_20200225230312.png $ p$ e1 U9 v8 A" R
" u9 k* F. a6 j* n. x
负载均衡策略

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

http:// 192.168.1.62:8080

http:// 192.168.1.63:8080

http:// 192.168.1.64:8080

1.   平均轮询

配置如下图:

3 P% F! Z, }+ `" u8 s; ?
微信截图_20200225230312.png 8 {( S( X$ R$ ]
& W5 R, i+ x8 X& l- I

这里我们把后台所有的服务器放入upstream中,并在代理中进行引用。
$ E" S3 v" J% o

2.   加权轮询,使用weight参数设置,配置如下
# ]  w# D1 L- ]: i) L4 I* n 微信截图_20200225230312.png " p" ?5 p" T% `' e2 R4 j
3.   ip_hash策略  z/ e  t7 W8 O- ~: B& \/ j$ c
(根据用户的IP地址进行hash运算,只要是同个用户发的请求,就会被永远地转发在某台服务器上,比如张三发的请求第一次时是由Tomcat1返回的,李四的是有Tomcat2返回的,那么,以后张三的所有请求,都有由Tomcat1返回,这就是ip_hash策略),配置如下:0 N0 V6 z6 B8 }# q2 X" h: a
其他地方保持不变,在upstreaem中如下设置:
1 ?4 h# O" V" s7 q- i$ N3 r3 R7 j* r& W

, X6 O( a3 o' {, w 微信截图_20200225230312.png 4 e! W5 |0 m# D$ o; @4 n! O
% T/ {8 m( G7 J+ T
4.   fair策略3 `6 {' m+ \8 i. L# r; f. D9 e; p
(动态weight策略,我们的加权轮询是显式指定weight的,而fair策略是根据服务器的响应能力进行动态指定的,而意义上讲,我觉得是更为智能化的解决方法,不过这里要记住一点,fair策略是一个第三方策略)& u5 J* ?! P, Q
5.   url_hash策略# U$ e: U$ g& o! |4 s5 n( I
9 e* I0 |" b5 k: K- T, T5 f
(类似于ip,只不过绑定的值是url,这个也是第三方策略)6 {2 @0 \. _* `  G- l2 b. f
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重新编译源文件即可8 S+ A9 R2 R$ Q3 f6 N2 O
' J8 f: ?8 D4 W) r, {% ^7 g

/ @2 Q2 U0 t& o. n# ~- z- e
5 l* o( u4 e& S& l0 Aurl_hash策略的用处?
% {- L0 l! E7 M# L0 d9 L5 w
& [- ^3 t& `* k5 Q( O" D. q3 ourl_hash策略比较适合于大型电子商务网站,对于不同的商品便是不同的url,我们可以据此进行负载均衡。
$ Y7 m, i) }! A; w: `
' D6 N8 i8 ]0 R6 }, n原理就是不同的商品形成不同的静态页面,然后服务器根据不同商品的火爆程度,按照命中率高的放在缓存里,加快访问速度,也就是说实现了一个基于缓存的服务器,相当于把有限的缓存最优化起来;
! e( r# p; P( T6 d* g" h5 H  V) Z/ L/ d

* o( [% g9 y# z8 x( I4 b% \. O: N" n( R4 ]5 w7 q9 H! o
其他的配置  `9 C, N9 p2 y( x) w" Z! E
备份与停机状态:! w9 Q. _0 t9 j: e1 g; ?9 ]" x6 {3 W
server 192.168.1.64 backup;//备份,不参与转发,只有当所有服务器都挂掉时才参与转发;( H. |0 H4 _6 R9 E. e

  Q1 M3 o/ W- {  Zserver 192.168.1.65 down;//临时停机维护,不参与任何转发,是关闭状态,
. |8 p+ a: L- l7 S. ^
2 j; {( T1 f8 Jdown存在的意义在于,有时我们需要对服务器做临时停机更新维护,假如我们直接关闭服务器的话,那么对于Nginx来说,他还是会把请求发到该服务器上的,因为他并不知道服务器已关,而设置down后,Nginx则不会再发到该服务器上了,避免造成无用的请求浪费。
( f0 j1 w+ z% O- s" X5 U' L, B/ N& T8 O
8 J9 x4 O' Z1 ?/ r& @
- w0 `+ X8 i5 Z  R
max_fails:        达到指定次数后认为服务器挂掉
5 ], ]1 g9 `0 a' o6 e! A5 V6 o6 V( k; e8 W7 {. z# G
fail_timeout:挂掉多久后再次测试是否已经挂掉
/ O/ K2 b+ o2 ]: i2 [: C0 R2 ^; b/ O& I$ D& s. a; a) B. [
配置命令
  n  u) E( t1 m+ Z" M/ N* x, B- ?. f5 y# ~* u
server 192.168.1.66 max_fails=2 fail_timeout=60s;; F! l; ]; A5 l& W
8 y; M/ r8 f6 z7 K
后记
( s8 G* B4 {: s7 `我们知道,服务器是会存储用户的session的,那么,如果按照上文所说的,比如fair策略,每次Nginx会根据后端服务器群的能力把请求分发出去,那假如第一次时分在了A,那么我把数据存储到了A服务器上,第二次时,刚好被分配到了B服务器上,那么问题来了,我的session不就不见了?(这就是我们在访问部分网站时有时我们的登录状态会不见)当然了,你可能 会说,ip_hash策略不就可以避免这一点吗?没错,这确实是一个解决方法,那除了ip_hash呢?其他策略下又当如何呢?下篇博客将会讲到负载均衡下如何对session进行处理。" _- G8 n% p7 t+ @  L/ A
4 d* |5 R( X1 [' M9 \1 o

  l1 E. P  V# k+ x: B/ w. P. J1 l1 I0 S; p0 j
0 j/ C/ N$ r2 H- r& v
! w/ `$ P0 g1 ]$ b" l1 f
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

        在线客服系统
    申请友链|小黑屋|手机版|Archiver| 备案信息代码:冀ICP备18019919号-1

GMT+8, 2020-8-10 12:30 , Processed in 0.210672 second(s), 33 queries .

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