你好,游客 登录 注册 搜索
背景:
阅读新闻

负载均衡——Nginx理论

[日期:2016-11-14] 来源:Linux社区  作者:ivehd [字体: ]

nginx是什么?

  nginx是一个强大的web服务器软件,用于处理高并发的http请求和作为反向代理服务器做负载均衡。具有高性能、轻量级、内存消耗少,强大的负载均衡能力等优势。

nginx架构?

  如上官方示意图所示,nginx启动以后,会在系统中以daemon的方式在后台运行,其中包括一个master进程,n(n>=1)个worker进程。

  其中,master进程用于接收来自外界的信号,并给worker进程发送信号,同时监控worker进程的工作状态。

      worker进程则是外部请求真正的处理者,每个worker请求相互独立且平等的竞争来自客户端的请求。请求只能在一个worker进程中被处理,且一个worker进程只有一个主线程,所以同时只能处理一个请求。那么问题来了,一个worker进程只有一个主线程,只能同时处理一个请求,nginx对高并发请求强大的处理能力是如何保证的呢?答案是nginx采用异步非阻塞的方式来处理请求,即单线程、非阻塞、异步IO的工作模型。对比apache的异步非阻塞版本的工作模式,apache会为每一个请求新建一个线程去处理请求,线程进行上下文切换,会造成内存和CPU的浪费。反看nginx的异步非阻塞io模式,实用操作系统提供的io多路复用技术(epoll),在一个线程中处理所有请求,当一个io操作开始的时候,nginx不会等待其完成就回去处理下一个请求,等到io操作完成后,nginx再回来处理这一次请求io操作的后续工作。相比apache,nginx省去了线程上下文切换带来的资源开销。

      那么nginx如何确定哪个worker来处理请求呢?首先,每个worker进程都是从master进程fork过来,在master进程里面,先建立好需要listen的socket(listenfd)之后,然后再fork出多个worker进程。所有worker进程的listenfd会在新连接到来时变得可读,为保证只有一个进程处理该连接,所有worker进程在注册listenfd读事件前抢accept_mutex,抢到互斥锁的那个进程注册listenfd读事件,在读事件里调用accept接受该连接。当一个worker进程在accept这个连接之后,就开始读取请求,解析请求,处理请求,产生数据后,再返回给客户端,最后才断开连接,这样一个完整的请求就是这样的了。这样,一个请求,完全由worker进程来处理,而且只在一个worker进程中处理。

nginx性能?

      这里援引网上搜索到的nginx的测试数据:10000个非活跃的HTTP keep-alive 连接仅占用约2.5MB内存。三万并发连接下,10个Nginx进程,消耗内存150M。淘宝tengine团队说测试结果是“24G内存机器上,处理并发请求可达200万”。

nginx负载均衡?

      通信协议支持:nginx负载均衡主要是对七层网络通信模型中的第七层应用层上的http、https进行支持。同时nginx更新版本也在逐步对Websocket、SPDY等协议作出支持。

nginx是以反向代理的方式进行负载均衡的。反向代理(Reverse Proxy)方式是指以代理服务器来接受Internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给Internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。(为了理解反向代理,这里插播一条什么是正向代理:正向代理指的是,一个位于客户端和原始服务器之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始服务器转交请求并将获得的内容返回给客户端。)

      这里再插播一条实现负载均衡的技术的方式有哪些:硬件层面有F5负载均衡器,网络层层面有LVS(Linux Virtual Server),应用层层面就是nginx、Haproxy等。

      nginx实现负载均衡的分配策略有很多,被编进nginx内核的策略有轮询和ip_hash,第三方的有fair、url_hash等。这里主要对内核策略进行介绍。

1.轮询

  a)none(默认轮询):upstream按照轮询(默认)方式进行负载,每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。虽然这种方式简便、成本低廉。但缺点是:可靠性低和负载分配不均衡。

  b)weight(按权重轮询):指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。 

server 192.168.61.22 weight = 6; # 60% 请求
server 192.168.61.23 weight = 4; # 40% 请求

2.ip_hash

  每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。配置只需要在upstream中加入"ip_hash;"即可。

upstream tomcats {
      ip_hash;
      server 127.0.0.1:9001;
      server 127.0.0.1:9002;
}

3.fair(第三方)

  按后端服务器的响应时间来分配请求,响应时间短的优先分配。与weight分配策略类似。

upstream tomcats {
      server 127.0.0.1:9001;
      server 127.0.0.1:9002;
      fair;
}

4.url_hash(第三方)

  和IP哈希类似,只不过针对请求的url进行hash(基于缓存的server,页面静态化)。

更多Nginx负载均衡配置相关教程见以下内容

Nginx负载均衡配置说明 http://www.linuxidc.com/Linux/2016-03/129424.htm

Linux下Nginx+Tomcat负载均衡和动静分离配置要点  http://www.linuxidc.com/Linux/2016-01/127255.htm

Docker+Nginx+Tomcat7配置简单的负载均衡  http://www.linuxidc.com/Linux/2015-12/125907.htm

Nginx负载均衡(主备)+Keepalived  http://www.linuxidc.com/Linux/2015-12/126865.htm

使用Nginx作为负载均衡器 http://www.linuxidc.com/Linux/2015-12/125789.htm

使用Nginx简单实现负载均衡  http://www.linuxidc.com/Linux/2016-08/134443.htm

Nginx负载均衡与高可用的实现 http://www.linuxidc.com/Linux/2016-04/130350.htm

初学Nginx实现Web负载均衡  http://www.linuxidc.com/Linux/2016-10/136116.htm

Nginx 的详细介绍请点这里
Nginx 的下载地址请点这里

本文永久更新链接地址http://www.linuxidc.com/Linux/2016-11/137111.htm

linux
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款