Nginx----高级

Nginx请求流程

Nginx进程结构

  Nginx有两种进程结构,一种是单进程(可以用于测试),一种是多进程(用于生产,默认)

  Nginx会按需同时运行多个进程:一个主进程(master)和几个工作进程(worker),配置了缓存时还会有缓存加载器进程(cache loader)和缓存管理器进程(cache manager)等。Nginx主要通过“共享内存”的机制实现进程间通信。worker 进程数,一般会设置成机器 cpu 核数。因为更多的worker 数,只会导致进程相互竞争 cpu,从而带来不必要的上下文切换。

  请求的缓存处理还是由work进程来执行的。CM:缓存的管理,CL:缓存的载入。

                    

进程结构测试

  1、ps -ef | grep nginx:可以查看到所有的work进程和cache进程
  2、../sbin/nginx -s reload:重新加载配置
  3、ps -ef | grep nginx:可以查看到之前所有的work进程和cache进程全部退出,重新生成新的work进程和cache进程
  4、kill -SIGHUP 9170:向master进程发送hub信号,结果和reload一样
  5、ps -ef | grep nginx:可以查看到之前所有的work进程和cache进程全部退出,重新生成新的work进程和cache进程
  6、kill -SIGTERM 16982:向work进程发送退出信号
  7、ps -ef | grep nginx:16982进程退出,会重新生成一个work进程

Nginx采用多进程而不是多线程,目的?

  Nginx 的进程就是线程,即每个进程里只有一个线程,但这一个线程可以服务多个客户端。

  Nginx需要保证高可用和高可靠性,多线程线程之间共享某一快地址空间,如果某一个第三方某块引发了一个地址空间导致的断错误时,在地址越界出现时,会导致整个Nginx整个进程挂掉。

  nginx采用多进程的方式,既可以避免因某个线程故障导致整个服务不可用的问题,也可以实现配置热加载,不停服升级版本。

Nginx实现高并发原理?

  参考:https://blog.csdn.net/m0_38110132/article/details/75126316

多进程之间通讯

  多进程通讯可以使用共享内存,信号等,Nginx做进程管理通常只使用信号

  Master进程可以监控wrok进程是否像master发送CHLD信号,因为子进程终止的时候回向父进程发送CHLD信号,如果work由于意外发生终止(认为输入命令终止,但是我们一般不这么做,我们通过发送命令给master,让master来终止work进程),此时master进程就会知道。

reload详解

1、向master进程发送HUP信号(reload命令)
2、master进程校验配置语法是否正确
3、master进程打开新的监听端口(配置文件可能添加了新的端口)
4、master进程用新配置启动新的worker子进程
5、master进程向老worker子进程发送QUIT信号
6、老worker进程关闭监听句柄,处理完当前连接后结束进程

热升级流程详解

1、将旧Nginx文件换成新Nginx文件(注意备份)
2、向master进程发送USR2信号
3、master进程修改pid文件名,加后缀.oldbin
4、master进程用新Nginx文件启动新master进程
5、向老master进程发送QUIT信号,关闭老master进程
6、回滚:向老master发送HUP,向新master发送QUIT

  

如果优雅的关闭work进程(缓慢的关闭)

如果当前的work已经在处理请求,立刻关闭连接,就会造成用户接受错误消息

1、设置定时器:worker shutdown timeout
2、关闭监听句柄
3、关闭空闲连接
4、在循环中等待全部连接关闭
5、退出进程

 

Nginx异步框架工作流程

 Nginx事件循环

epoll使用优势

在大并发情况下,100万个请求,往往活跃连接数就几百个,所以epoll只需要处理这几百个连接,而select和poll需要将这100万个连接统统扔给操作系统,操作系统依次判断哪些连接有事件进来,所以操作系统做了大量的无用功

非堵塞调用

 

Nginx如果通过连接池来处理网络请求

欲分配的连接数目

参考:http://nginx.org/en/docs/ngx_core_module.html#worker_connections

Syntax:	worker_connections number;
Default:	worker_connections 512; //512:512个数组,对应512个连接,生产中需要配置更大的
Context:	events

  一个客户端请求,需要使用一个connect连接(struct ngx_connection_s结构体占空间232个字节),一个连接对应两个事件读和写(struct ngx_event_s结构体占空间96个字节),所以worker_connections分配越大,初始化就会占用232+96*2个字节

补充:读和写超时时间配置:http://nginx.org/en/docs/http/ngx_http_core_module.html#client_header_timeout

   一个请求到来,work占用连接数是2个或者4个,如果请求访问的是静态资源,nginx可以直接给用户返回,此时占用两个,如果请求的是动态资源,nginx需要将请求转发给tomcat,此时占用连接数是4个。

  nginx有一个master,如果有4个work,每一个work支持的最大连接数是1024,支持的最大的并发数是多少?

    (1) 4*1024/2

    (2) 4*1024/4

nginx内存池

  内存池是在真正使用内存之前,预先申请分配一定数量的、大小相等(一般情况下)的内存块留作备用。当有新的内存需求时,就从内存池中分出一部分内存块,若内存块不够用时,再继续申请新的内存。

  内存池的好处有减少向系统申请和释放内存的时间开销,解决内存频繁分配产生的碎片,提示程序性能,减少程序员在编写代码中对内存的关注等

  目前一些常见的内存池实现方案有STL中的内存分配区,boost中的object_pool,nginx中的ngx_pool_t,google的开源项目TCMalloc等。

   在分配的内存上,nginx有小块内存和大块内存的概念,小块内存 nginx在分配的时候会尝试在当前的内存池节点中分配,而大块内存会调用系统函数malloc向操作系统申请

  在释放内存的时候,nginx没有专门提供针对释放小块内存的函数,小块内存会在ngx_destory_pool 和 ngx_reset_pool的时候一并释放

  分配时怎么判断是小块内存还是大块内存呢?
    p->max=(size < NGX_MAX_ALLOC_FROM_POOL) ? size : NGX_MAX_ALLOC_FROM_POOL;
    #define NGX_MAX_ALLOC_FROM_POOL (ngx_pagesize - 1)
    Pagesize为内存一页的大小,x86结构通常为4k
    Max为内存池可分配大小和pagesize中较小的一个
    如果需要分配的内存大于max,则认为是较大内存,否则为较小内存

Nginx分配内存的配置

  连接内存池的大小:http://nginx.org/en/docs/http/ngx_http_core_module.html#connection_pool_size(默认512|516,需要保存大量的上下文,比如很长的url,header)

  请求内存池的大小:http://nginx.org/en/docs/http/ngx_http_core_module.html#request_pool_size(默认4k,因为保存的上下文比较少,只需要帮组后面的请求读取最初的一部分字节就可以了)

参考:https://www.cnblogs.com/magicsoar/p/6040238.html

Work进程之间协同工作

work之间如果需要共享数据,需要使用共享内存

信号量:会导致进程发生休眠状态,比如当某一个块内存被1号进程使用,那么2号就会进行休眠,等待1号通知2号锁已经释放

自旋锁:比如当某一个块内存被1号进程使用,那么2号就会不断的试图去解锁,要求所有的Nginx模块需要快速的使用共享内存

Slab内存管理

下载Tengine:http://tengine.taobao.org/download_cn.html (slab没有独立的模块,我们需要将tengin整个下载下来)

使用(编译nginx)

make之后对nginx进行热部署...

Nginx容器

  数组
  链表
  队列
  哈希表
  红黑树
  基数树

原文地址:https://www.cnblogs.com/yanxiaoge/p/11561448.html