nginx学习笔记（1）：nginx平台架构

nginx在启动后，在Unix系统中会议daemon方式在后台运行，包含一个master进程和多个worker进程。当然，也可以关闭后台模式，让其在前台运行。并且可以通过配置让nginx取消master进程，从而让nginx以单进程方式运行。nginx以多进程方式进行运行，但它也同时支持多线程，只是主流方式和默认方式都是前者。

       nginx采用多进程有诸多好处，下面将对多进程进行详细讲解。

nginx进程模型：

      

master进程主要用来管理worker进程，工作内容包括接受来自外界的信号，向worker进程发送信号，监控worker进程的运行状况，在worker进程退出后（异常情况下），会重新启动worker进程。

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

       我们要控制nginx，只需要通过kill向master进程发送信号就行了。比如kill-HUP pid，则是告诉nginx，从容地重启nginx，我们一般用这个信号来重启nginx，或重新加载配置，因为是从容地重启，因此服务是不中断的。master进程在接收到HUP信号后是怎么做的呢？首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的进程，并向所有老的进程发送信号，告诉他们可以光荣退休了。新的进程在启动后，就开始接收新的请求，而老的进程在收到来自master的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出。当然，直接给master进程发送信号，这是比较老的操作方式，nginx在0.8版本之后，引入了一系列命令行参数，来方便我们管理。比如，./nginx -s reload，就是来重启nginx，./nginx-s stop，就是来停止nginx的运行。如何做到的呢？我们还是拿reload来说，我们看到，执行命令时，我们是启动一个新的nginx进程，而新的nginx进程在解析到reload参数后，就知道我们的目的是控制nginx来重新加载配置文件了，它会向master进程发送信号，然后接下来的动作，就和我们直接向master进程发送信号一样了。

worker进程是如何处理我们的http请求的？

master（master进程会先建立好需要listen的socket）--------fork生成子进程workers，继承socket（此时workers子进程们都继承了父进程master的所有属性，当然也包括已经建立好的socket，当然不是同一个socket，只是每个进程的这个socket会监控在同一个ip地址与端口，这个在网络协议里面是允许的）------当一个连接进入，产生惊群现象（惊群现象：指一个fd的事件被触发后，等候这个fd的所有线程/进程都被唤醒。虽然都被唤醒，但是只有一个会去响应。）。

Nginx对惊群现象的处理：共享锁

nginx提供了一个accept_mutex这个东西，从名字上，我们可以看这是一个加在accept上的一把共享锁。有了这把锁之后，同一时刻，就只会有一个进程在accpet连接，这样就不会有惊群问题了。accept_mutex是一个可控选项，我们可以显示地关掉，默认是打开的。

worker进程工作：

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

采用这种方式的好处：

1）节省锁带来的开销。对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查上时，也会方便很多

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

Nginx的事件处理机制，采用异步非阻塞事件处理机制，一个worker进程只有一个主线程，通过异步非阻塞的事件处理机制，实现了循环处理多个准备好的事件，从而实现轻量级和高并发。

异步非阻塞事件处理机制：

同步和异步的概念,这两个概念与消息的通知机制有关.同步的情况下,是由处理消息者自己去等待消息是否被触发,而异步的情况下是由触发机制来通知处理消息者。

阻塞和非阻塞,这两个概念与程序等待消息(无所谓同步或者异步)时的状态有关.

当读写事件没有准备好时，就放入epoll里面。如果有事件准备好了，那么就去处理；如果事件返回的是EAGAIN，那么继续将其放入epoll里面。从而，只要有事件准备好了，我们就去处理，只有当所有时间都没有准备好时，才在epoll里面等着。这样，我们就可以并发处理大量的并发了，当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请求当然只有一个了，只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里的切换是没有任何代价，你可以理解为循环处理多个准备好的事件。

与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。更多的并发数，只是会占用更多的内存而已.

之前我们提到nginx的负载均衡功能，那么和LVS的负载均衡有什么区别呢？

负载均衡分为：

L4 switch（四层交换），即在OSI第4层工作，就是TCP层啦。此种LoadBalance不理解应用协议（如HTTP/FTP/MySQL等等）。例子：LVS，F5

L7 switch（七层交换），OSI的最高层，应用层。此时，该LoadBalancer能理解应用协议。例子：haproxy，MySQL Proxy。

很多LoadBalancer（例如F5）既可以做四层交换，也可以做七层交换。

LVS 工作在网络4层仅做请求分发之用没有流量，可配置性低，几乎可对所有应用做负载均衡，对网络依赖大，没有健康检查机制。

nginx的7层(应用层)，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，对网络依赖小，可检测服务器内部错误。

nginx可以根据URL进行负载均衡的请求转发，而LVS只能根据ip:port进行请求转发

一般情况下，LVS会被放在最前端做负载均衡，nginx可作为lvs的节点服务器。

 

 来源：http://tengine.taobao.org/book/chapter_02.html

来源：http://www.uml.org.cn/itil/201405275.asp