Nginx架构赏析

Posted 2021-04-01 小瑾守护线程

淘宝的某位大佬曾经做过测试，在一台24G内存的机器上，nginx的最大并发连接数达到了200万。同学们听到这个结论后，是不是被Nginx的超高性能深深折服了，它内部的架构设计究竟是怎么样的呢？这篇文章就带同学们来认识一下Nginx的架构设计吧。

本文主要参考了淘宝技术团队写的Nginx文章，将会从以下个方面去进行分享：

• Nginx进程模型

• Nginx事件模型

Nginx进程模型

Nginx默认以多进程的方式启动运行，当然Nginx也是支持多线程的方式的，只是我们主流的方式还是多进程的方式，也是Nginx的默认方式。Nginx采用多进程的方式有很多的好处，这一点与我们大部分同学们的认知发生冲突了。

大部分同学会说进程比线程重，进程更耗费资源等等，总之可以说出一大堆线程优于进程的证明。如果有同学恰恰是这样想的，那就得扩充下认知啦。比如我们大名鼎鼎的Redis，Oracle里边都是有多进程概念的 ，而这些软件无一例外都具有超高性能。所以，我们今天就主要来学习下Nginx的多进程模式。

Nginx的进程模型长个什么样子，废话不多说，直接上图。

Nginx在启动后，会有一个master进程和多个worker进程。master进程主要用来管理worker进程，包含：接收来自操作系统的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。而基本的网络事件，则是放在worker进程中来处理了。

多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它worker进程的请求。worker进程的个数是可以设置的，一般设置与机器cpu核数一致，这里面的原因与Nginx的进程模型以及事件处理模型是分不开的。

Nginx的多进程模型给它带来了一个大优点：优雅重启，服务不间断。具体它是怎么做到呢？从上面我们已经得知，master管理worker进程，所以我们只需要与master进程通信就行了。

master进程会接收来自操作系统发来的信号，再根据信号做不同的事情。所以我们要控制Nginx，只需要通过操作系统提供的kill命令向master进程发送信号就行了。比如使用kill -HUP pid重启Nginx，master进程在接收到HUP信号后是怎么做的呢？

首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的worker进程，并向所有老的worker进程发送信号，告诉他们可以光荣退休了。新的worker在启动后，就开始接收新的请求，而老的worker在收到来自master的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出。

我们知道了在操作Nginx的时候，Nginx内部做了些什么事情，那么，worker进程又是如何客户端处理请求的呢？我们前面有提到，worker进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？

首先，每个worker进程都是从master进程fork过来，在master进程里面，先创建好ServerSocket，开启监听，然后再fork出多个worker进程。所有worker进程都将和master进程持有同一份socket句柄，并且句柄会在新连接到来时变得可读，为保证只有一个进程处理该连接，所有worker进程在注册句柄读事件前抢accept_mutex，抢到互斥锁的那个进程注册句柄读事件，在读事件里调用accept接受该连接。

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

那么，Nginx采用这种进程模型有什么好处呢？实在是太多了，重点说上几条。首先，对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查找时，也会方便很多。

其次，采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master进程则很快启动新的worker进程。当然，worker进程的异常退出，肯定是程序有bug了，异常退出，会导致当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。当然，好处还有很多，同学们可以慢慢体会。

Nginx事件模型

Nginx采用了NIO的方式来处理请求，这是Nginx可以同时处理成千上万个请求的根本原因。想想低版本Tomcat的IO模型(高版本已支持NIO)，每个请求会独占一个工作线程，当并发数上到几千时，就同时有几千的线程在处理请求了。

几千个线程并发执行，对操作系统来说是个不小的挑战，线程带来的内存占用非常大，线程的上下文切换带来的cpu开销很大，自然性能就上不去了，而这些开销完全是没有意义的。

Nginx为什么要使用NIO呢？NIO到底是怎么回事呢？IO的本质就是读写事件，而当读写事件没有准备好时，必然不可操作，如果不用非阻塞的方式来调用，那就得阻塞调用了，事件没有准备好，那就只能等了，等事件准备好了，工作线程再继续吧。

阻塞调用会进入内核等待，cpu就会让出去给别人用了，工作线程只能傻傻的睡觉等待，对单线程的worker来说，显然不合适，当网络事件越多时，大家都在等待呢，cpu空闲下来没人用，cpu利用率自然上不去了，更别谈高并发了。所以，为了高性能，必须使用NIO。关于NIO，我们这里就是一笔带过，想详细学习的同学可以去看我的NIO源码分析文章。

接下来，我们使用一段伪代码来总结一下Nginx的事件处理模型：

Date now; // 表示当前时间while (true) { // 处理任务队列里的所有任务 for task in tasks: task.handler();
 flushTime(now); // 刷新当前时间 timeout = initValue; // 超时时间  // waitTasks可以理解为注册到epoll里的所有有效任务 for task in waitTasks:  // 列表里的第一个task的超时时间是最短的，如果它已经超时了，就调用超时处理函数 if (task.time <= now) {  task.timeoutHandler(); } else { // 更新超时时间 timeout = t.time - now; break; }  // 通过epoll拿到已经就绪的事件 nevents = epoll(events, timeout); // 挨个遍历处理事件 for i in nevents: Task task; // 读事件 if (events[i].type == READ) { task.handler = readHandler; } else { // 写事件 task.handler = writeHandler; } // 防到一个专门的执行队列里 tasks(task);}

好的，文章到这里就结束啦。希望Nginx的进程模型和事件模型的设计思想，能对朋友们以后的系统设计有所帮助。

小瑾能否回家过年的事情，昨天开会时候尘埃落地了。学校不让回家过年，我听到后内心是十分抗拒的。学校太固执了，它不曾知道，表面上是限制它的学生不给回家，实际上却已限制了double的人不能回。比如说我，注定这个年也不能回家过了呀。