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的IO通常使用epoll,epoll函数使用了I/O复用模型。与I/O阻塞模型比较,I/O复用模型的优势在于可以同时等待多个(而不只是一个)套接字描述符就绪。Nginx的epoll工作流程如下:
- 首先,master 进程接受到信号(如nginx -s reload)后启动,读取配置文件,建好需要listen的socket后,然后再fork出多个woker进程,这样每个work进程都可以去accept这个socket
2 . 当一个client连接到来时,所有accept的work进程都会受到通知,但只有一个进程可以accept成功,其它的则会accept失败,Nginx提供了一把共享锁accept_mutex来保证同一时刻只有一个work进程在accept连接,从而解决惊群问题
-
当一个worker进程accept这个连接后,就开始读取请求,解析请求,处理请求,产生数据后,再返回给客户端,最后才断开连接,这样一个完成的请求就结束了
-
一个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不共享的问题。
-
Nginx作为Web缓存
-
可以把静态资源放在Nginx服务器上(比如前端页面资源)
-
Nginx可以对不同的文件做不同的缓存处理,配置灵活。
-
配合着第三方的ngx_cache_purge,对指定的URL缓存内容可以的进行增删管理。
网友评论