（点击上方蓝字，快速关注我们)
NGINX 在网络应用中表现超群，在于其独特的设计。许多网络或应用服务器大都是基于线程或者进程的简单框架，NGINX突出的地方就在于其成熟的事件驱动框架，它能应对现代硬件上成千上万的并发连接。 NGINX内部信息图从进程框架的顶层开始，向下逐步揭示NGINX如何处理单个进程中的多个连接，并进一步探讨其工作机制。 场景设置 NGINX进程模型为了更好地理解这种设计模式，我们需要明白NGINX是如何运行的。NGINX拥有一个主线程，用来处理配置文件的读取、端口的绑定等特权操作，以及一组工作进程、辅助进程。
在这个四核服务器中，主线程创建了四个工作进程和一组缓存辅助进程（cache helper processes），后者用来管理硬盘缓存。 为什么框架如此重要？任何Unix应用的基础是线程或者进程-对于Linux操作系统，线程和进程几乎相同；最大的区别在于线程间是内存共享的。一个线程或者进程是一套指令集(self-contained set of instructions )，操作系统调度这些指令在单个CPU内核上运行。许多复杂应用并行地运行在多个线程或者进程，原因有二：
进程和线程消耗资源，比如对内存以及其它操作系统资源的占用、内核切换(wapped on and off the cores)(本操作叫做一次上下文切换(context switch))。如今的服务器需要同时处理成千个小的、活跃线程或者进程，一旦内存耗尽、或者过高的读写负载，这些都会导致大规模的上下文切换，性能会严重退化。 通常的设计思路是，网络应用为每个连接分派一个线程或者进程。这类框架简单易于实现，不过在同时应对成千上万个连接时难以扩展。 NGINX是如何运作的呢？NGINX利用一个预测进程模型调度可用的硬件资源：
NGINX推荐的配置是，一个工作进程对应一个CPU内核，确保硬件资源的有效利用，在配置文件中设置worker_processes auto：
一旦NGINX服务起来，仅有工作进程在忙，每个工作进程采用非阻塞地方式处理多个连接，降低上下文切换的次数。 每个工作进程都是单线程且独立运行，负责获取新连接并进行处理。进程之间通过共享内存进行通信，诸如缓存数据，会话持续化数据(ession persistence data),以及其他共享资源。NGINX1.7.11及以后的版本，有一个可选的线程池，工作进程将阻塞操作丢给它们。更多细节，参看《 声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除 |
注册
登录
