nginx部分实现原理解析

时间:2023-03-09 01:47:45
nginx部分实现原理解析

nginx底层实现有几个主要的模块:

  1. 进程模块
  2. 事件模块
  3. 网络模块

进程模块

默认采用守护模式启动,守护模式让master进程启动后在后台运行,不在窗口上卡住。

Nginx 启动后会有一个 Master 进程和多个Worker 进程,Master 进程主要用来管理 Worker 进程,对网络事件进程进行收集和分发,调度哪个模块可以占用 CPU 资源,从而处理请求。

一般配置Worker进程的个数与机器cpu个数一致,从而达到cpu资源的最大化利用,也避免由于进程资源分配带来的额外开销。

nginx部分实现原理解析

Master进程工作原理

master进程主要用来管理worker进程,如:

  1. 接收来自外界的信号,向各worker进程发送信号;
  2. 监控worker进程的运行状态,当worker进程退出后(异常情况下),会自动重新启动新的worker进程。

Worker进程工作原理

基本的网络事件,则是放在worker进程中来处理了。

worker进程之间是平等的,每个进程,处理请求的机会也是一样的。

当一个worker进程在accept这个连接之后,就开始读取请求,解析请求,处理请求,产生数据后,再返回给客户端,最后才断开连接,这样一个完整的请求就是这样的了。我们可以看到,一个请求,完全由worker进程来处理,而且只在一个worker进程中处理。

(nginx提供了一个accept_mutex(互斥锁),有了这把锁之后,同一时刻,就只会有一个进程在accpet连接,worker进程内部不需要锁)

好处:

  1. 对于每个worker进程来说,独立的进程,不需要加锁,所以省掉了锁带来的开销,同时在编程以及问题查找时,也会方便很多。
  2. 互相之间不会影响,一个进程退出后,其它进程还在工作,服务不会中断,master进程则很快启动新的worker进程。

事件模块

apache的常用工作方式:每个请求会独占一个工作线程,当并发数上到几千时,就同时有几千的线程在处理请求了。这对操作系统来说,是个不小的挑战,线程带来的内存占用非常大,线程的上下文切换带来的cpu开销很大,自然性能就上不去了,而这些开销完全是没有意义的。

nginx采用多worker的方式来处理请求,每个worker里面只有一个主线程,那能够处理的并发数很有限啊,多少个worker就能处理多少个并发,何来高并发呢?非也,这就是nginx的高明之处,nginx采用了异步非阻塞的方式来处理请求,也就是说,nginx是可以同时处理成千上万个请求的。

为什么nginx可以采用异步非阻塞的方式来处理呢,或者异步非阻塞到底是怎么回事呢?

我们先回到原点,看看一个请求的完整过程。

请求过来,要建立连接,然后再接收数据,接收数据后,再发送数据。

nginx里面,最忌讳阻塞的系统调用了。不要阻塞,那就非阻塞喽。非阻塞就是,事件没有准备好,马上返回EAGAIN,告诉你,事件还没准备好呢,你慌什么,过会再来吧。好吧,你过一会,再来检查一下事件,直到事件准备好了为止,在这期间,你就可以先去做其它事情,然后再来看看事件好了没。

虽然不阻塞了,但你得不时地过来检查一下事件的状态,你可以做更多的事情了,但带来的开销也是不小的。所以,才会有了异步非阻塞的事件处理机制。

我们之前说过,推荐设置worker的个数为cpu的核数,在这里就很容易理解了,更多的worker数,只会导致进程来竞争cpu资源了,从而带来不必要的上下文切换。

现在,知道了nginx为什么会选择这样的进程模型与事件模型了。对于一个基本的web服务器来说,事件通常有三种类型,网络事件、信号、定时器。从上面的讲解中知道,网络事件通过异步非阻塞可以很好的解决掉。如何处理信号与定时器?

  • 信号的处理。(待补充)
  • 定时器。nginx里面的定时器事件是放在一颗维护定时器的红黑树里面,每次在进入epoll_wait前,先从该红黑树里面拿到所有定时器事件的最小时间,在计算出epoll_wait的超时时间后进入epoll_wait。(待补充)

网络模块

先不提。

参考资料:

  1. Nginx 之实现原理 http://www.jianshu.com/p/b77482d4b670
  2. Nginx 多进程模型是如何实现高并发的? https://www.zhihu.com/question/22062795
  3. nginx平台初探 http://tengine.taobao.org/book/chapter_02.html