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

QQ登录

只需一步,快速开始

 找回密码
 立即注册

QQ登录

只需一步,快速开始

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

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

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

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

反向代理:

如下图所示,


) M5 Y/ K2 |/ N0 Z1 c

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

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

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

: g7 t" s9 U8 \% ?+ o8 f
从图中,我们可以知道,对于浏览器来说,他会发一个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的这么一个过程便称为反向代理。% _4 u* F# C9 V; a

5 ~7 i% s: a! e' H$ j$ T' \- X那么,Nginx服务器是如何实现这一步的呢,事实上也很简单,只需要在location中做一下简单的配置即可,命令大概如下图所示:(配置完命令记得reload重新加载才能生效)
: w& _' r) Y5 N% m: C. ~0 w0 Z
# y6 L2 K" `# U9 R: v* L/ }& @
  1. worker_processes 1;( o1 y* b6 p3 V+ B/ i
  2. events{
复制代码
' q, |; G3 c4 c: _

6 ~0 @- L  j9 R& O* A  [+ M0 a重点在于location处,这样的配置代表的是,所有来自浏览器的请求,在Nginx收到之后,都会代理到http://192.168.1.62:8080所在的地方
3 r8 U- n6 m3 |5 U: V4 w$ D1 |7 d: E$ k' _4 M' X% g1 o
比如,我浏览器上发起http://192.168.1.61/a/index.html;Nginx收到之后,将会发出http:// 192.168.1.62:8080/a/index.html这么一个请求到所连接的服务器上,如上图的Tomcat。
2 p" ~1 n! x$ s4 w: m% K- j6 q( }, a4 S( l

, C- L& z7 ~/ ~& e0 {接下来我们做这样一个假设,假如后端连接着几台。几十台服务器呢,这个时候Nginx也是做同样的代理吗,答案是肯定的。图示如下:那么,在这么多台服务器上,Nginx的转发又是基于怎样的策略呢?这个时候就涉及在负载均衡了,说白了就是,应该怎样的分发,才能做到资源的最大限度的利用?6 `3 Y) A9 Z+ i! H

+ ^  s% X; B* }( O% ?; h/ ]& O, U' |. {# r' `1 j
+ A/ q# c# i5 b  X
! {' t6 M) e5 Q8 w# O
负载均衡策略

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

http:// 192.168.1.62:8080

http:// 192.168.1.63:8080

http:// 192.168.1.64:8080

1.   平均轮询

配置如下图:

" O& _) }. O8 [. v
$ a, I2 D* l' f+ w" j" r4 K6 w. G' h

: I0 ^5 f& ]$ \4 f6 B

这里我们把后台所有的服务器放入upstream中,并在代理中进行引用。. O+ z3 J: R0 Y4 R2 K

2.   加权轮询,使用weight参数设置,配置如下
1 B4 E3 H# d2 a7 _* M - J  N& o6 o6 S1 e$ H
3.   ip_hash策略
# d5 r1 O; V) s$ d" R7 d  n(根据用户的IP地址进行hash运算,只要是同个用户发的请求,就会被永远地转发在某台服务器上,比如张三发的请求第一次时是由Tomcat1返回的,李四的是有Tomcat2返回的,那么,以后张三的所有请求,都有由Tomcat1返回,这就是ip_hash策略),配置如下:; k# l: q, o( b; }! ^" D  e
其他地方保持不变,在upstreaem中如下设置:& F  F# S, N6 I, B
8 j9 i& W% p" u# Z( Y5 ?+ c4 ]' Z
, }" W1 b$ a6 V- G! B; h
' A0 z$ k' }2 [( p5 ^' l
9 Y0 ~* d8 E2 t. t1 D. Y8 f
4.   fair策略/ q( C7 ?5 J1 p, r! o) D' ^
(动态weight策略,我们的加权轮询是显式指定weight的,而fair策略是根据服务器的响应能力进行动态指定的,而意义上讲,我觉得是更为智能化的解决方法,不过这里要记住一点,fair策略是一个第三方策略)
! y! D# g: t8 r& G. l5.   url_hash策略+ t1 \. P, a+ B- R/ h& ~* X

- }! Z& B2 G4 y% E(类似于ip,只不过绑定的值是url,这个也是第三方策略)) e* m2 H6 o# u, E3 P! P8 n9 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重新编译源文件即可
% e$ L- k" D+ J* S3 i* T2 S) q) `9 u! ^
) q3 D6 x/ c9 c1 X- F
) z2 s% V$ l' U6 D3 L7 {5 m
url_hash策略的用处?( U$ [( G: s$ W/ J7 `

8 y1 n# Z% T  U; G8 a& ]9 Durl_hash策略比较适合于大型电子商务网站,对于不同的商品便是不同的url,我们可以据此进行负载均衡。2 r0 x% j9 Q4 x" R6 F. Z

  j1 H8 Z) c) [8 B+ o* n原理就是不同的商品形成不同的静态页面,然后服务器根据不同商品的火爆程度,按照命中率高的放在缓存里,加快访问速度,也就是说实现了一个基于缓存的服务器,相当于把有限的缓存最优化起来;* X9 K* s  M) m5 M' I
" J. Z1 `0 Q% \( [7 ^6 O6 Y" f
0 h$ ~, |$ H$ |% F  E* @: A

$ W5 b' s# n9 ]( o2 {8 o其他的配置0 j8 W! a% Z; u% \
备份与停机状态:
: b/ i0 n( H' aserver 192.168.1.64 backup;//备份,不参与转发,只有当所有服务器都挂掉时才参与转发;) _; U' {, e" |9 s

1 z$ w0 v, b! D& R  M5 ^& ?server 192.168.1.65 down;//临时停机维护,不参与任何转发,是关闭状态,
3 F; T1 ~1 L: K- [' g7 F  ]
6 O4 C9 l' `% L/ {) O- A0 udown存在的意义在于,有时我们需要对服务器做临时停机更新维护,假如我们直接关闭服务器的话,那么对于Nginx来说,他还是会把请求发到该服务器上的,因为他并不知道服务器已关,而设置down后,Nginx则不会再发到该服务器上了,避免造成无用的请求浪费。4 i6 t2 c; {1 K( v( o- R5 U, Z! S
( h; T) t7 y( E: w0 d2 Y% x6 U

1 g: b3 Q: v7 v9 t! `$ z. m8 t) V9 f
max_fails:        达到指定次数后认为服务器挂掉+ H& |& b9 I0 `9 s( Y

, O& J* m+ n3 ^, ]4 n2 Z/ m1 ^7 X fail_timeout:挂掉多久后再次测试是否已经挂掉
% r% V# e6 ^' B1 v+ }3 @8 O: C* ?3 V' O: H3 e0 R9 ~% u
配置命令
2 {6 r* D; l' [3 ], ~. }, A1 q. r
server 192.168.1.66 max_fails=2 fail_timeout=60s;
) ^: X8 z6 ?) W, u9 `
& l6 N9 e. J" ^. _5 Z: X 后记
1 }$ a* p' S2 ~: h' e4 Q% h我们知道,服务器是会存储用户的session的,那么,如果按照上文所说的,比如fair策略,每次Nginx会根据后端服务器群的能力把请求分发出去,那假如第一次时分在了A,那么我把数据存储到了A服务器上,第二次时,刚好被分配到了B服务器上,那么问题来了,我的session不就不见了?(这就是我们在访问部分网站时有时我们的登录状态会不见)当然了,你可能 会说,ip_hash策略不就可以避免这一点吗?没错,这确实是一个解决方法,那除了ip_hash呢?其他策略下又当如何呢?下篇博客将会讲到负载均衡下如何对session进行处理。9 b4 G5 `* z1 g5 s; K

5 s* e; b4 @  }5 W2 V) {" g9 I4 A! h, ?$ s8 E2 t' c* s
3 X% |4 _4 ]- [/ w- T0 h6 i6 [

9 l) K3 n2 @# T6 b7 p8 _0 X+ S* p. E+ t$ w  {; g& ?- [
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 分享分享 支持支持 反对反对
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

GMT+8, 2024-12-22 12:09 , Processed in 0.123395 second(s), 23 queries .

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