浅谈Nginx服务器的内部核心架构设计
|
事件发送器将每个请求放入一个 待处理事件列表 ，使用非阻塞 I/O 方式调用 事件处理器 来处理该请求。其处理方式称为 “多路 IO 复用方法” ，常见的包括以下三种： select 模型、 poll模型、 epoll 模型。 5. Nginx进程处理模型 Nginx 服务器使用 master/worker 多进程模式 。多线程启动和执行的流程如下： 主程序 Master process 启动后，通过一个 for 循环来 接收 和 处理外部信号 ； 主进程通过 fork() 函数产生 worker 子进程 ，每个 子进程 执行一个 for 循环来实现 Nginx 服务器 对事件的接收 和 处理 。 一般推荐 worker 进程数 与 CPU 内核数 一致，这样一来不存在 大量的子进程 生成和管理任务，避免了进程之间 竞争 CPU 资源 和 进程切换 的开销。而且 Nginx 为了更好的利用 多核特性 ，提供了 CPU 亲缘性 的绑定选项，我们可以将某 一个进程绑定在某一个核 上，这样就不会因为 进程的切换 带来 Cache 的失效。 对于每个请求，有且只有一个 工作进程 对其处理。首先，每个 worker 进程都是从 master进程 fork 过来。在 master 进程里面，先建立好需要 listen 的 socket（listenfd） 之后，然后再 fork 出多个 worker 进程。 所有 worker 进程的 listenfd 会在 新连接 到来时变得 可读 ，为保证只有一个进程处理该连接，所有 worker 进程在注册 listenfd 读事件 前 抢占 accept_mutex ，抢到 互斥锁 的那个进程 注册 listenfd 读事件 ，在 读事件 里调用 accept 接受该连接。 当一个 worker 进程在 accept 这个连接之后，就开始 读取请求 ， 解析请求 ， 处理请求 ，产生数据后，再 返回给客户端 ，最后才 断开连接 ，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由 worker 进程来处理，而且只在一个 worker 进程中处理。 浅谈Nginx服务器的内部核心架构设计 在 Nginx 服务器的运行过程中， 主进程 和 工作进程 需要进程交互。交互依赖于 Socket 实现的 管道 来实现。 5.1. 主进程与工作进程交互 这条管道与普通的管道不同，它是由 主进程 指向 工作进程 的 单向管道 ，包含主进程向工作进程发出的 指令 ， 工作进程 ID 等；同时 主进程 与外界通过 信号通信 ；每个 子进程 具备 接收信号 ，并处理相应的事件的能力。 5.2. 工作进程与工作进程交互 这种交互是和 主进程-工作进程 交互是基本一致的，但是会通过 主进程 间接完成。 工作进程之间是 相互隔离 的，所以当工作进程 W1 需要向工作进程 W2 发指令时，首先找到 W2 的 进程ID ，然后将正确的指令写入指向 W2 的 通道 。 W2 收到信号采取相应的措施。 小结 通过这篇文章，我们对 Nginx 服务器的 整体架构 有了一个整体的认识。包括其 模块化的设计、 多进程 和 异步非阻塞 的请求处理方式、 事件驱动模型 等。通过这些理论知识，才能更好地领悟 Nginx 的设计思想。对于我们学习 Nginx 来说有很大的帮助。 【编辑推荐】
点赞 0 （编辑：徐州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
