Nginx：基本原理篇

Nginx基本模块：

nginx功能模块

• Nginx 默认采用守护模式启动，守护模式让master进程启动后在后台运行。在Nginx运行期间主要由一个master主进程和多个worker进程

• worker进程数目建议设为与cpu核数相同，这样每个worker进程都绑定特定的CPU核心，进程间切换的代价是最小的。因为一是Nginx一般做的是高并发代理，基本没有IO操作，大多数都是CPU密集型操作，很少出现IO阻塞等情况。二是进程与CPU调度的关系，单个核心处理多个进程的时候，是排队处理的，如果设置多个进程的时候，是排队处理的，如果设置多个进程时，会带来进程间切换的开销

• master进程不会对用户请求提供服务，只用于管理真正提供服务的worker进程，所以master进程可以是唯一的，它仅专注于自己的纯管理工作，为管理员提供命令行服务，包括诸如启动服务、停止服务、重载配置文件、平滑升级程序等，当任意一个worker进程出现错误从而导致coredump时，master进程会立刻启动新的worker进程继续服务。

• 网络请求的处理，是放在worker进程中来完成的，而且只能在一个worker进程中处理。多个worker进程是相互独立且对等竞争的。
  采用这种方式的好处：

  • 节省锁带来的开销。对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查上时，也会方便很多
  • 独立进程，减少风险。
    采用独立的进程，可以让互相之间不会影响，当一个worker进程异常退出时，其它进程还在工作，服务不会中断，master进程则很快重新启动新的worker进程。虽然当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。

• 每个worker里面只有一个主线程，但一个worker可以同时处理多个请求。nginx采取异步非阻塞的方式处理请求，每个请求进来，worker线程将其注册处理转发给下游服务（如php-fpm）后，并不是挂起等待，而是切换处理别的请求。采用这种轮询的方式来并发处理大量请求

nginx进程模型

nginx的处理流程

Nginx的IO通常使用epoll，epoll函数使用了I/O复用模型。与I/O阻塞模型比较，I/O复用模型的优势在于可以同时等待多个（而不只是一个）套接字描述符就绪。Nginx的epoll工作流程如下：

1. 首先，master 进程接受到信号（如nginx -s reload）后启动，读取配置文件，建好需要listen的socket后，然后再fork出多个woker进程，这样每个work进程都可以去accept这个socket

2 . 当一个client连接到来时，所有accept的work进程都会受到通知，但只有一个进程可以accept成功，其它的则会accept失败，Nginx提供了一把共享锁accept_mutex来保证同一时刻只有一个work进程在accept连接，从而解决惊群问题

3. 当一个worker进程accept这个连接后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完成的请求就结束了

4. 一个worker进程可以同时处理多个请求，每个worker进程只有一个主线程，而是采用异步非阻塞的方式来处理并发请求。比如同时有多个http request的时候，worker主线程与第一条request建议连接将其处理转发给下游fast cgi后，并不会挂起等待，而是立马处理下一条，可以理解轮询处理。与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换），更多的并发数，只是会占用更多的内存而已。因此nginx 是非常适合处理高并发请求的

惊群现象

惊群现象：惊群效应就是当一个fd的事件被触发时，所有等待这个fd的线程或进程都被唤醒。一般都是socket的accept()会导致惊群，很多个进程都block在server socket的accept()，一但有客户端进来，所有进程的accept()都会返回，但是只有一个进程会读到数据，就是惊群。
Nginx 采用accept-mutex来解决惊群问题：当一个请求到达的时候，只有竞争到锁的worker进程才会惊醒处理请求，其他进程会继续等待，结合 timer_solution 配置的最大的超时时间继续尝试获取accept-mutex

从I/O复用角度谈 nginx 和apache 的区别

I/O 复用接口有select 和 epoll 两种模型，首先介绍一下这两种模型的执行方式：

• select 模型：说的通俗一点就是各个客户端连接的文件描述符也就是套接字，都被放到了一个集合中，调用select函数之后会一直监视这些文件描述符中有哪些可读，如果有可读的描述符那么我们的工作进程就去读取资源。PHP 中有内置的函数来完成 select 系统调用。select()所维护的 存储大量文件描述符的数据结构 ，随着文件描述符数量的增长，其在用户态和内核的地址空间的复制所引发的开销也会线性增长

由于网络响应时间的延迟使得大量TCP连接处于非活跃状态，但调用select()还是会对 所有的socket进行一次线性扫描 ，会

• epoll 模型：epoll 是 select 的增强版。epoll 文件描述符数量无限制。基于事件的就绪通知方式 ，select/poll方式，进程只有在调用一定的方法后，内核才会对所有监视的文件描述符进行扫描，而epoll事件通过epoll_ctl()注册一个文件描述符，一旦某个文件描述符就绪时，内核会采用类似call back的回调机制，迅速激活这个文件描述符，epoll_wait()便会得到通知

调用一次epoll_wait()获得就绪文件描述符时，返回的并不是实际的描述符，而是一个代表就绪描述符数量的值，拿到这些值去epoll指定的一个数组中依次取得相应数量的文件描述符即可，这里使用内存映射（mmap）技术， 避免了复制大量文件描述符带来的开销。

在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。
epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统，把原先的select/poll调用分成了3个部分：

调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
调用epoll_ctl向epoll对象中添加这100万个连接的套接字
调用epoll_wait收集发生的事件的连接

只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

apache 采用的select模型，nginx采用epoll模型，nginx 处理请求是异步非阻塞的，而apache则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能。在Apache+PHP（prefork）模式下，如果PHP处理慢或者前端压力很大的情况下，很容易出现Apache进程数飙升，从而拒绝服务的现象。

Nginx 常用功能

• Nginx支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。并且支持很多第三方的模块扩展。

• Nginx作为Http代理、反向代理：

• Nginx通过配置实现灵活的转发功能：Nginx可以根据不同的正则匹配，采取不同的转发策略。

• Nginx可以对返回结果进行错误页跳转，异常判断等。

• 如果被分发的服务器存在异常，它可以将请求重新转发给另外一台服务器，然后自动去除异常服务器。

• Nginx作为负载均衡器：

• Nginx提供的负载均衡策略有2种：内置策略和扩展策略。

• 内置策略为轮询，加权轮询，Ip hash。

• 扩展策略由第三方实现。

• 轮询与加权轮询：

• Ip hash算法，对客户端请求的ip进行hash操作，然后根据hash结果将同一个客户端ip的请求分发给同一台服务器进行处理，可以解决session不共享的问题。

image

• Nginx作为Web缓存

• 可以把静态资源放在Nginx服务器上（比如前端页面资源）

• Nginx可以对不同的文件做不同的缓存处理，配置灵活。

• 配合着第三方的ngx_cache_purge，对指定的URL缓存内容可以的进行增删管理。

参考文章：http://tengine.taobao.org/book/chapter_02.html