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

QQ登录

只需一步,快速开始

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 11711|回复: 0
打印 上一主题 下一主题

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

[复制链接]
跳转到指定楼层
楼主
发表于 2020-2-25 23:05:39 | 只看该作者 |只看大图 回帖奖励 |倒序浏览 |阅读模式

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

反向代理:

如下图所示,

" H! k" T( @! x  Y2 |$ y  u  P' y

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

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

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


" B2 }# B) ]3 ~3 k+ v从图中,我们可以知道,对于浏览器来说,他会发一个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的这么一个过程便称为反向代理。
( N& v% F4 P( y6 S, `4 R' k! W
3 J6 y" h# u5 Z% k4 M% G5 v那么,Nginx服务器是如何实现这一步的呢,事实上也很简单,只需要在location中做一下简单的配置即可,命令大概如下图所示:(配置完命令记得reload重新加载才能生效)9 A! i- Q% d: z0 ~" c

% {, Z' U; w6 @' B1 I1 [$ P. C3 L  W1 P- }2 A
  1. worker_processes 1;8 Q( i: M/ |: j
  2. events{
复制代码

3 i9 O  ~# ?# v5 L8 j" n  N- d. ~0 {1 e. S, R
重点在于location处,这样的配置代表的是,所有来自浏览器的请求,在Nginx收到之后,都会代理到http://192.168.1.62:8080所在的地方8 j2 s) _* g* E1 G% ~, _" }
3 h% q: a" }; a! a9 G! C
比如,我浏览器上发起http://192.168.1.61/a/index.html;Nginx收到之后,将会发出http:// 192.168.1.62:8080/a/index.html这么一个请求到所连接的服务器上,如上图的Tomcat。- ]3 D4 M+ L) j

% e: e/ r$ _1 p6 N1 L/ S& C
& A. k& Q+ ~/ f. Z# b: P接下来我们做这样一个假设,假如后端连接着几台。几十台服务器呢,这个时候Nginx也是做同样的代理吗,答案是肯定的。图示如下:那么,在这么多台服务器上,Nginx的转发又是基于怎样的策略呢?这个时候就涉及在负载均衡了,说白了就是,应该怎样的分发,才能做到资源的最大限度的利用?
' Q: ^# _# N  d, J, o& ^
/ ~- i  J# G0 O  G
( j. u3 g) J: u+ K  X- a " J/ d# B4 h3 C1 N( x& h# y. M* ]
) N5 Y9 }/ I2 Z5 D4 i
负载均衡策略

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

http:// 192.168.1.62:8080

http:// 192.168.1.63:8080

http:// 192.168.1.64:8080

1.   平均轮询

配置如下图:

+ ^: A+ v/ K1 v4 n
4 N0 ?! h& ^1 x" {
, i" k( @/ S' x% [9 s

这里我们把后台所有的服务器放入upstream中,并在代理中进行引用。
' r. f% U: }1 O3 x# V3 ^% S8 ^

2.   加权轮询,使用weight参数设置,配置如下
, m4 e6 d& u5 m' ~# I5 E" ^4 u 8 ]6 a! }, H) s  s0 T; {
3.   ip_hash策略% W; c7 h% I- Z4 B
(根据用户的IP地址进行hash运算,只要是同个用户发的请求,就会被永远地转发在某台服务器上,比如张三发的请求第一次时是由Tomcat1返回的,李四的是有Tomcat2返回的,那么,以后张三的所有请求,都有由Tomcat1返回,这就是ip_hash策略),配置如下:, d; l% J* v- ]
其他地方保持不变,在upstreaem中如下设置:
1 I! t) c. a; o4 t0 ]! ?% ?! [# R5 _, c6 g0 g4 m% d2 c
% t3 d1 a7 a7 E5 \) H$ y
* e* {2 o( X/ Y

5 r5 ~4 V( J7 }0 m; Q0 N4.   fair策略
; N- g% g- A9 T( X, i(动态weight策略,我们的加权轮询是显式指定weight的,而fair策略是根据服务器的响应能力进行动态指定的,而意义上讲,我觉得是更为智能化的解决方法,不过这里要记住一点,fair策略是一个第三方策略)
7 b* b! f* H) [1 @. [0 r0 o9 M5.   url_hash策略
; p3 ^1 }- |) G. b( V8 O( S  u: u: W% t( x  \; a8 K$ E
(类似于ip,只不过绑定的值是url,这个也是第三方策略)
4 @# `, L5 F' v" f& g6 Mfair策略与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重新编译源文件即可
5 u1 i$ }- k0 m+ p" W# @9 Z1 Q3 Z/ F* A3 l& |# ~+ {
4 ^7 m& K, z: i
  ]# @) e( P# S0 C3 p. a* z
url_hash策略的用处?' s/ X1 y! n. Z  W- E8 C0 k
# b4 r! Y$ Y. t. m4 F7 }$ |
url_hash策略比较适合于大型电子商务网站,对于不同的商品便是不同的url,我们可以据此进行负载均衡。
4 f$ u, V) _4 N/ [; L5 ^" f# [
: L9 C; m# D" m9 L原理就是不同的商品形成不同的静态页面,然后服务器根据不同商品的火爆程度,按照命中率高的放在缓存里,加快访问速度,也就是说实现了一个基于缓存的服务器,相当于把有限的缓存最优化起来;. f8 ]+ T1 e! l" N, O/ G3 X  d$ v
3 M" t( G+ ]7 m% Q; |% @
( y2 A# P) i, g2 `. s9 D' R

  s( i: |$ Q( C& w其他的配置
/ h1 a8 q6 {5 `( `# H; n1 R备份与停机状态:" C" n: c% A* Z) \; g
server 192.168.1.64 backup;//备份,不参与转发,只有当所有服务器都挂掉时才参与转发;# H9 z) @6 E. X) v- q; S

8 Z& ~8 B$ s! j0 z; ~server 192.168.1.65 down;//临时停机维护,不参与任何转发,是关闭状态,
' P  X7 s* O. ^5 Q! ]* u. H6 A
% n1 N9 J0 v( E4 L1 T! Gdown存在的意义在于,有时我们需要对服务器做临时停机更新维护,假如我们直接关闭服务器的话,那么对于Nginx来说,他还是会把请求发到该服务器上的,因为他并不知道服务器已关,而设置down后,Nginx则不会再发到该服务器上了,避免造成无用的请求浪费。8 T! ]9 B: X0 J  B- x7 _

' O" w. D3 }7 a* Y, z- T
; e5 |0 E. \# x# h5 D) B/ s2 Y$ p4 V; ?8 i4 \  F) o# U* g
max_fails:        达到指定次数后认为服务器挂掉
! U1 b* p9 Y5 w" x, J- c; ~& q0 i! J: @- U" j* {+ D5 q9 Y) M% \
fail_timeout:挂掉多久后再次测试是否已经挂掉
3 \5 {2 s+ }1 a6 w
. o3 [- J5 |; G& i配置命令
" y0 y8 h9 N; D; Y, F% c7 h
  Q* ^4 x1 }6 c+ b: ?2 Q1 _3 Gserver 192.168.1.66 max_fails=2 fail_timeout=60s;1 S1 t( c( t* b# b3 N
3 D7 t6 u/ o& C+ p
后记4 f& ^6 u5 W- y& \; d  m! k+ W
我们知道,服务器是会存储用户的session的,那么,如果按照上文所说的,比如fair策略,每次Nginx会根据后端服务器群的能力把请求分发出去,那假如第一次时分在了A,那么我把数据存储到了A服务器上,第二次时,刚好被分配到了B服务器上,那么问题来了,我的session不就不见了?(这就是我们在访问部分网站时有时我们的登录状态会不见)当然了,你可能 会说,ip_hash策略不就可以避免这一点吗?没错,这确实是一个解决方法,那除了ip_hash呢?其他策略下又当如何呢?下篇博客将会讲到负载均衡下如何对session进行处理。
$ `8 D  L( F& Q) v/ Y7 \% L6 Z) @! R' m0 b9 J7 i8 e
4 F# \- A+ j3 Q4 s1 p) |

  E' g* c- p0 m# ~" ]) p. g
* I1 o" |* j. p( Z7 B# _  E$ y. e: i& T- w0 g* X3 |
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 分享分享 支持支持 反对反对
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

GMT+8, 2024-5-20 19:03 , Processed in 0.139232 second(s), 22 queries .

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