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

QQ登录

只需一步,快速开始

 找回密码
 立即注册

QQ登录

只需一步,快速开始

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

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

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

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

反向代理:

如下图所示,

" v. A- |' O! o0 G2 B& f- R9 M

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

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

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


/ Z# c  D" [' v2 c从图中,我们可以知道,对于浏览器来说,他会发一个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的这么一个过程便称为反向代理。
! j7 T% W6 v/ L! X. V: v
5 \+ @) r8 I, h3 y那么,Nginx服务器是如何实现这一步的呢,事实上也很简单,只需要在location中做一下简单的配置即可,命令大概如下图所示:(配置完命令记得reload重新加载才能生效)- Y: t3 D/ M( L

+ I+ k/ R5 Q# R) L5 K+ M- S% S6 ?' |, s/ C5 @
  1. worker_processes 1;
    , }( n+ i) I' m( `
  2. events{
复制代码
8 D* }# M% b# D  M5 k
- q1 O% z9 O8 }( n5 U3 T* v; S5 P
重点在于location处,这样的配置代表的是,所有来自浏览器的请求,在Nginx收到之后,都会代理到http://192.168.1.62:8080所在的地方
* F/ t$ X5 `9 h# A
7 X% A- W* H" T% {6 L  b7 z  ^9 k7 v比如,我浏览器上发起http://192.168.1.61/a/index.html;Nginx收到之后,将会发出http:// 192.168.1.62:8080/a/index.html这么一个请求到所连接的服务器上,如上图的Tomcat。
+ G4 O% g7 h7 @
# ~5 D* K: g6 e# y; r5 N
3 Y* E2 p" Q  E' \! e2 w6 E$ A! W接下来我们做这样一个假设,假如后端连接着几台。几十台服务器呢,这个时候Nginx也是做同样的代理吗,答案是肯定的。图示如下:那么,在这么多台服务器上,Nginx的转发又是基于怎样的策略呢?这个时候就涉及在负载均衡了,说白了就是,应该怎样的分发,才能做到资源的最大限度的利用?
. |3 X7 w, G! Z& `. r9 V& q% I3 \/ f  h
- j" h6 C! y$ `  L! V8 X% z) w

5 G) X# P% W! L' u+ `9 V% P0 N; |8 k
负载均衡策略

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

http:// 192.168.1.62:8080

http:// 192.168.1.63:8080

http:// 192.168.1.64:8080

1.   平均轮询

配置如下图:


9 ?4 O  P% x% T* N& m& R' F+ T( q ; t, S$ D9 f9 t
" F$ |: B) B# Z& }' b$ q, b

这里我们把后台所有的服务器放入upstream中,并在代理中进行引用。$ a* g4 R! d7 M

2.   加权轮询,使用weight参数设置,配置如下9 c1 n" P- R9 Q9 K' |6 ^% y8 y
  T' ^" k2 m' C' L& D
3.   ip_hash策略0 Y7 A, [. G- B! t/ v0 ~; a# s
(根据用户的IP地址进行hash运算,只要是同个用户发的请求,就会被永远地转发在某台服务器上,比如张三发的请求第一次时是由Tomcat1返回的,李四的是有Tomcat2返回的,那么,以后张三的所有请求,都有由Tomcat1返回,这就是ip_hash策略),配置如下:
# |; {: {# W" i 其他地方保持不变,在upstreaem中如下设置:
+ L2 k5 E  a% \; I! u" Y1 d; Z( x; i
8 [2 [% G: Y3 C7 U! c9 r) i2 U. k; g7 F6 U" d% W4 j' a: U1 p( Z
* j/ s- B: [5 R
5 s. Q! ?3 B- b; r
4.   fair策略5 r, ^) S- J: H9 @5 t9 A
(动态weight策略,我们的加权轮询是显式指定weight的,而fair策略是根据服务器的响应能力进行动态指定的,而意义上讲,我觉得是更为智能化的解决方法,不过这里要记住一点,fair策略是一个第三方策略)# M/ ^0 d: J1 J
5.   url_hash策略
$ j6 U' J3 \" f. u% @" c' P5 c
/ {7 ^* O0 c1 B(类似于ip,只不过绑定的值是url,这个也是第三方策略)
; w& D* [. T9 [5 Lfair策略与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重新编译源文件即可
/ h/ n$ k0 @: B& r6 Q' W; ^5 |/ b- ?+ C; m8 L! L4 U& e

; b, @4 F# r4 _9 e! b3 {  h1 F; F, t: c5 d& O( p
url_hash策略的用处?
' |' s* Z5 m" u* h3 Z4 f! f4 x; k# ^" j
url_hash策略比较适合于大型电子商务网站,对于不同的商品便是不同的url,我们可以据此进行负载均衡。
+ ]' P% M& A3 h" y+ O* D# z& F1 M
9 {# R, K: J1 H7 r' w/ d原理就是不同的商品形成不同的静态页面,然后服务器根据不同商品的火爆程度,按照命中率高的放在缓存里,加快访问速度,也就是说实现了一个基于缓存的服务器,相当于把有限的缓存最优化起来;. S) b$ r4 J( K
5 @4 y1 S# j& F* X8 S0 j
3 D! c& p8 x! y- `) T% N+ t

4 ~6 X. ~/ @/ w2 I/ j/ O4 z其他的配置. H3 I& h/ @. t5 H
备份与停机状态:/ r4 @4 C0 g$ B8 g: F9 F
server 192.168.1.64 backup;//备份,不参与转发,只有当所有服务器都挂掉时才参与转发;
5 F% ^% M1 z- |4 f( U. o5 g6 Z! c/ l' V: C8 q
server 192.168.1.65 down;//临时停机维护,不参与任何转发,是关闭状态,
  x' {! |/ P2 I8 w- g
$ ]' [  A6 I! B' e; mdown存在的意义在于,有时我们需要对服务器做临时停机更新维护,假如我们直接关闭服务器的话,那么对于Nginx来说,他还是会把请求发到该服务器上的,因为他并不知道服务器已关,而设置down后,Nginx则不会再发到该服务器上了,避免造成无用的请求浪费。
7 ?5 R4 ]) @- D# O/ }+ N% }& ^+ K( l2 m- r0 P+ X9 M( R

& r8 K' ]+ Z: e& r1 d0 a  s
' k) J/ |8 ]6 l3 q; z9 [/ S. kmax_fails:        达到指定次数后认为服务器挂掉8 ?1 F; ^, g: ?; ]1 P

" g; t0 e9 A5 z$ r% a fail_timeout:挂掉多久后再次测试是否已经挂掉) ^7 o, f" r0 b
8 [( Y# o  R/ W% p" {$ |# z* m
配置命令: ~7 g/ _1 r" M/ U' z( q
/ I1 P2 U0 _% B. L+ E4 G) T+ q* P
server 192.168.1.66 max_fails=2 fail_timeout=60s;
7 q' u6 m$ R* D' I
; ?; j( M0 |" G 后记1 H' p! G) I9 T; i
我们知道,服务器是会存储用户的session的,那么,如果按照上文所说的,比如fair策略,每次Nginx会根据后端服务器群的能力把请求分发出去,那假如第一次时分在了A,那么我把数据存储到了A服务器上,第二次时,刚好被分配到了B服务器上,那么问题来了,我的session不就不见了?(这就是我们在访问部分网站时有时我们的登录状态会不见)当然了,你可能 会说,ip_hash策略不就可以避免这一点吗?没错,这确实是一个解决方法,那除了ip_hash呢?其他策略下又当如何呢?下篇博客将会讲到负载均衡下如何对session进行处理。6 }3 M7 _' D, W) g1 n
; l1 T$ M0 J9 P1 Y

' @) O7 K+ g7 |
0 u) r0 R( b' x( g
: e" t5 m' g4 d7 Q9 b2 b: {% l! Y9 M& J' v) I+ j, N
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 分享分享 支持支持 反对反对
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

GMT+8, 2026-1-30 13:20 , Processed in 0.060372 second(s), 23 queries .

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