nginx如何实现高性能和可扩展性

NGINX的整体架构的特点是由一组进程协同工作:

主进程:负责执行特权操作,如阅读配置文件、绑定套接字、创建/通知协调(Signalling)子进程。 工作进程:负责接收和处理连接请求,读取和写入磁盘,并与上游服务器通信。当NGINX处于活跃状态时,只有工作进程是忙碌的。 缓存加载器进程:负责将磁盘高速缓存加载到内存中。这个进程在启动时运行后随即退出。 缓存管理器进程:负责整理磁盘缓存的数据保证其不越界。这个进程会间歇性运行。 NGINX能够实现高性能和可扩展性的关键取决于两个基本的设计选型: 尽可能限制工作进程的数量,从而减少上下文切换带来的开销。默认和推荐配置是让每个CPU内核对应一个工作进程,从而高效利用硬件资源。 工作进程采用单线程,并以非阻塞的方式处理多个并发连接。 NGINX的每个工作进程通过状态机处理多个连接请求,这个状态机被实现为非阻塞的工作方式: 每个工作进程需要处理若干套接字,包括监听套接字或者连接套接字。 当监听套接字收到新的请求时,会打开一个新的连接套接字来处理与客户端的通信。 当一个事件到达连接套接字时,工作进程迅速完成响应,并转而处理其他任何套接字新收到的事件。 Garrett说,NGINX选择这样的设计,使它从根本上区别于其他Web服务器。通常的Web服务器会选用将每个连接分配给独立线程的模式,这使得多个连接的处理非常容易,因为每个连接可以被认为是包含多个步骤的一个线性序列,但这样会产生上下文切换的开销。事实上,工作线程大部分的时间处于阻塞的状态,在等待客户端或其它上游服务器。当试图执行I/O等操作的并发连接数/线程数的规模超过一定阈值,或是内存消耗殆尽的时候,上下文切换的成本就显现出来了。 从另一方面讲,NGINX的设计是不让工作进程阻止网络流量,除非没有任何工作要做。此外,每一个新的连接只消耗很少的资源,仅包括一个文件描述符和少量的工作进程内存。 总的来说,NGINX的这种工作模式在系统调优后,它的每个工作进程都能够处理成百上千的HTTP并发连接。 深入NGINX:我们如何设计它的性能和扩展性

NGINX之所以能在性能上如此优越,是由于其背后的设计。许多web服务器和应用服务器使用简单的线程的(threaded)、或基于流程的(process-based)架构,NGINX则以一种复杂的事件驱动(event-driven)的架构脱颖而出,这种架构能支持现代硬件上成千上万的并发连接。

Inside NGINX infographic涉及了从高层次进程架构的挖掘,到NGINX的单进程处理多连接的图解。本篇文章讲解了这些工作细节。

设置场景——NGINX进程模型

Setting the Scene ? the NGINX Process Model

为了更好地理解设计,你需要了解NGINX是如何工作的。NGINX有一个主进程(master process)(执行特权操作,如读取配置、绑定端口)和一系列工作进程(worker process)和辅助进程(helper process)。

这个四核服务器内,NGINX主进程创建了4个工作进程和2个缓存辅助进程(cache helper processes)来管理磁盘内容缓存(on-disk content cache)。

为什么架构很重要?

Why Is Architecture Important?

任何Unix应用程序的根本基础都是线程或进程。(从Linux操作系统的角度看,线程和进程基本上是相同的,主要区别是他们共享内存的程度。) 进程或线程,是一组操作系统可调度的、运行在CPU内核上的独立指令集。大多数复杂的应用程序都并行运行多个线程或进程,原因有两个:

● 可以同时使用更多的计算机内核。

●线程和进程使并行操作很容易实现(例如,同时处理多个连接)。

进程和线程都消耗资源。它们都使用内存和其他OS资源,导致内核频繁切换(被称作上下文切换(context switch)的操作)。大多数现代服务器可以同时处理数百个小的、活跃的(active)线程或进程,但一旦内存耗尽,或高I/O负载导致大量的上下文切换时,服务器的性能就会严重下降。

对于网络应用,通常会为每个连接(connection)分配一个线程或进程。这种架构易于实现,但是当应用程序需要处理成千上万的并发连接时,这种架构的扩展性就会出现问题。

NGINX是如何工作的?

How Does NGINX Work?

NGINX使用一个了可预见式的(predictable)进程模型,调度可用的硬件资源:

1.主进程执行特权操作,如读取配置和绑定端口,还负责创建子进程(下面的三种类型)。

2.缓存加载进程(cache loader process)在启动时运行,把基于磁盘的缓存(disk-based cache)加载到内存中,然后退出。对它的调度很谨慎,所以其资源需求很低。

3.缓存管理进程(cache manager process)周期性运行,并削减磁盘缓存(prunes entries from the disk caches),以使其保持在配置范围内。

4.工作进程(worker processes)才是执行所有实际任务的进程:处理网络连接、读取和写入内容到磁盘,与上游服务器通信等。

多数情况下,NGINX建议每1个CPU核心都运行1个工作进程,使硬件资源得到最有效的利用。你可以在配置中设置如下指令:

worker_processes auto

当NGINX服务器在运行时,只有工作进程在忙碌。每个工作进程都以非阻塞的方式处理多个连接,以消减上下文切换的开销。

每个工作进程都是单线程且独立运行的,抓取并处理新的连接。进程间通过共享内存的方式,来共享缓存数据、会话持久性数据(session persistence data)和其他共享资源。

NGINX内部的工作进程

Inside the NGINX Worker Process

每一个NGINX的工作进程都是NGINX配置(NGINX configuration)初始化的,并被主进程设置了一组监听套接字(listen sockets)。

NGINX工作进程会监听套接字上的事件(accept_mutex和kernel socket sharding),来决定什么时候开始工作。事件是由新的连接初始化的。这些连接被会分配给状态机(state machine)——HTTP状态机是最常用的,但NGINX还为流(原生TCP)和大量的邮件协议(SMTP,IMAP和POP3)实现了状态机。

状态机本质上是一组告知NGINX如何处理请求的指令。大多数和NGINX具有相同功能的web服务器也使用类似的状态机——只是实现不同。

调度状态机

Scheduling the State Machine

把状态机想象成国际象棋的规则。每个HTTP事务(HTTP transaction)都是一局象棋比赛。棋盘的一边是web服务器——坐着一位可以迅速做出决定的大师级棋手。另一边是远程客户端——在相对较慢的网络中,访问站点或应用程序的web浏览器。

然而,比赛的规则可能会很复杂。例如,web服务器可能需要与各方沟通(代理一个上游的应用程序),或者和认证服务器交流。web服务器的第三方模块也可以拓展比赛规则。

阻塞状态机

A Blocking State Machine

回忆一下我们之前对进程和线程的描述:是一组操作系统可调度的、运行在CPU内核上的独立指令集。大多数web服务器和web应用都使用一个连接 /一个进程或一个连接/一个线程的模型来进行这局国际象棋比赛。每个进程或线程都包含一个将比赛玩到最后的指令。在这个过程中,进程是由服务器来运行的,它的大部分时间都花在“阻塞(blocked)”上,等待客户端完成其下一个动作。

1.web服务器进程(web server process)在监听套接字上,监听新的连接(客户端发起的新比赛)。

2.一局新的比赛发起后,进程就开始工作,每一步棋下完后都进入阻塞状态,等待客户端走下一步棋。

3.一旦比赛结束,web服务器进程会看看客户是否想开始新的比赛(这相当于一个存活的连接)。如果连接被关闭(客户端离开或者超时),web服务器进程会回到监听状态,等待全新的比赛。

记住重要的一点:每一个活跃的HTTP连接(每局象棋比赛)都需要一个专用的进程或线程(一位大师级棋手)。这种架构非常易于扩展第三方模块 (“新规则”)。然而,这里存在着一个巨大的不平衡:一个以文件描述符(file descriptor)和少量内存为代表的轻量级HTTP连接,会映射到一个单独的进程或线程——它们是非常重量级的操作系统对象。这在编程上是方便的,但它造成了巨大的浪费。

NGINX是真正的大师

NGINX is a True Grandmaster

也许你听说过车轮表演赛,在比赛中一个象棋大师要在同一时间对付几十个对手。

Kiril Georgiev在保加利亚首都索菲亚同时对阵360名棋手,最终取得284胜,70平,6负的战绩。

这就是NGINX工作进程玩“国际象棋”的方式。每一个工作进程都是一位大师(记住:通常情况下,每个工作进程占用一个CPU内核),能够同时对战上百棋手(实际上是成千上万)。

1.工作进程在监听套接字和连接套接字上等待事件。

2.事件发生在套接字上,工作进程会处理这些事件。

●监听套接字上的事件意味着:客户端开始了一局新的游戏。工作进程创建了一个新的连接套接字。

●连接套接字上的事件意味着:客户端移动了棋子。工作进程会迅速响应。

工作进程从不会在网络上停止,它时时刻刻都在等待其“对手”(客户端)做出回应。当它已经移动了这局比赛的棋子,它会立即去处理下一局比赛,或者迎接新的对手。

为什么它会比阻塞式多进程的架构更快?

Why Is This Faster than a Blocking, Multi-Process Architecture?

NGINX的规模可以很好地支持每个工作进程上数以万计的连接。每个新连接都会创建另一个文件描述符,并消耗工作进程中少量的额外内存。每一个连接的额外消耗都很少。NGINX进程可以保持固定的CPU占用率。当没有工作时,上下文切换也较少。

在阻塞式的、一个连接/一个进程的模式中,每个连接需要大量的额外资源和开销,并且上下文切换(从一个进程到另一个进程)非常频繁。

如果想了解更多,请查看由NGINX公司发展和联合创始人副总裁Andrew Alexeev编写的有关NGINX体系结构的文章。

通过适当的系统调优,NGINX能大规模地处理每个工作进程数十万并发的HTTP连接,并且能在流量高峰期间不丢失任何信息(新比赛开始)。

配置更新和NGINX升级

Updating Configuration and Upgrading NGINX

仅包含少量工作进程的NGINX进程架构,使得配置、甚至是二进制文件本身的更新都非常高效。

更新NGINX的配置,是一个非常简单的、轻量级的、可靠的操作。运行nginx ?s reload命令即可,该命令会检查磁盘上的配置,并给主进程发送一个SIGHUP信号。

当主进程接收到SIGHUP信号后,会做两件事:

1.重新加载配置,fork一套新的工作进程。这些新的工作进程会立即开始接受连接和处理流量(traffic)(使用新的配置)。

2.发出信号,通知旧的工作进程安静地退出。这些旧进程不会再接受新的连接了。只要它们处理的HTTP请求结束了,它们就会干净地关闭连接。一旦所有的连接都被关闭,工作进程也就退出了。

这个过程会导致CPU占用率和内存使用的一个小高峰,但相比于从活动连接中加载资源,这个小高峰可忽略不计。你可以在一秒内重新加载配置多次。极少情况下,一代又一代工作进程等待连接关闭时会出现问题,但即便出现问题,它们也会被立即解决掉。

NGINX的二进制升级过程更加神奇——你可以飞速地升级NGINX本身,服务器不会有任何的丢连接、宕机、或服务中断等情况。

二进制升级过程与配置更新相似。新的NGINX主进程与原来的主进程并行,它们共享监听套接字。两个进程都是活跃的(active),它们各自的工作进程处理各自的流量(traffic)。然后,你可以通知旧的主进程与其工作进程完美退出。

在Controlling NGINX中,整个过程有更详细的描述。

结论

Conclusion

NGINX的内部图表高度概述了NGINX是如何运作的,但在这简单的解释背后是超过十年的创新与优化。这些创新与优化,使NGINX在多种硬件上表现出良好的性能,同时还具备现代web应用所需要的安全性和可靠性。

以上是云栖社区小编为您精心准备的的内容,在云栖社区的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索服务器 , 线程 , 缓存 , 架构 , 进程 配置 nginx高性能web服务器、nginx lua 高性能、nginx高性能配置、nginx 高性能、centos7 nginx 高性能,以便于您获取更多的相关知识。

原文发布于微信公众号 - nginx(nginx-study)

原文发表时间:2018-04-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏新智元

入坑搞定Python多种任务,Go 1.11 新版本正式发布!

新版本在工具链、运行时和库等方面有很多变化和改进,兼容性方面也依然会兼容旧版本。此外,新版本增加了两个最激动人心的新特性:对模块(modules)和WebAss...

1421
来自专栏IMWeb前端团队

Node.js必须收藏,五大应用性能技巧

本文作者:IMWeb 土豆一号 原文出处:IMWeb社区 未经同意,禁止转载 Nodejs/web前端 权威大牛交流群:550392000 ,更多免费...

2167
来自专栏大魏分享(微信公众号:david-share)

最流行的5大开源Web服务器

根据维基百科介绍,web服务器是“通过HTTP协议处理web请求的计算机系统”(a computer system that processes request...

5545
来自专栏上善若水

S006SELinux(SEAndroid)是个什么呀

SEAndroid 是一套安全机制,实现的主要目的是为了是Android系统更安全。 SELinux是被设计为一个灵活的可配置的MAC机制。 SEAndro...

1374
来自专栏我是攻城师

Kakfa集群搭建

3388
来自专栏IT技术精选文摘

Kafka详细设计及其生态系统

Kafka生态-Kafka Core,Kafka Streams,Kafka Connect,Kafka REST Proxy和Schema Registry ...

2767
来自专栏葡萄城控件技术团队

Google 新推出Background sync API

Background sync是Google新推出的Web API,可延迟用户行为,直到用户网络连接稳定。这样有助于保证用户想要发送的数据就是实际发送的数据。 ...

23110
来自专栏友弟技术工作室

Nginx架构--nginx系列之二Nginx的架构详解

Nginx的架构详解 今天,回家,这篇文章在机场候机,原文来自这里 NGINX 在网络应用中表现超群,在于其独特的设计。许多网络或应用服务器大都是基于线程或者进...

4449
来自专栏企鹅号快讯

如何更精准的在 Github 上搜索开源库?你需要这些技巧!

正文共: 2468字 8图 预计阅读时间: 7分钟 一、前言 在日常工作中,我们并不推荐去重复造轮子,通常我们会去搜索一些稳定的第三方开源库来使用。而 Gith...

2066
来自专栏Golang语言社区

提升 Node.js 应用性能的 5 个技巧

“如果nginx没有在你的节点服务器之前,那么你可能就错了。”Bryan Hughes在Twitter上说 Node.js是全球领先的用JavaScript——...

3174

扫码关注云+社区