搭错车的小火柴

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
nginx笔记-2

nginx的请求处理流程

 nginx处理的流量是其他应用服务处理流量的数倍。

 

 nginx的三个状态机：传输层状态机、http状态机、mail状态机。

核心部分由非阻塞的事件驱动处理引擎（epoll）实现，利用线程池处理阻塞的磁盘调用。最后通过应用层的协议，比如http、mail、stream、FastCGI等协议代理到响应的应用服务器。

nginx的进程结构

1.单进程结构

不适用于生产环境。

2.多进程结构：https://tengine.taobao.org/book/chapter_02.html#id1

 

利用服务器多核的特性，实现健壮的nginx。为什么不是多线程呢？因为nginx要保持他的高可用性，高可靠性。进程是资源调度的基本单位，线程之间是共享内存的，容易导致内存错误。

worker处理真正的请求，master主要是监控worker进程，master和worker之间通过signal进行通信。

缓存要被cachemanager、cacheloader、多个worker进程之间共享。

worker进程间通讯都是通过共享内存实现的，每个worker独占一颗cpu内核，减少缓存失效的命中率。

nginx重新启动配置文件：  nginx -s reload 

查看本地示例：

# 查看当前的nginx进程
➜ nginx ps -ef | grep nginx
  501 13775     1   0  8:42下午 ??         0:00.00 nginx: master process /Users/xiaohuochai/Desktop/nginx/sbin/nginx
  501 13776 13775   0  8:42下午 ??         0:00.00 nginx: worker process
  501 13785   885   0  8:42下午 ttys005    0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn nginx
# 给父进程发送hup信号（其实结果是会reload
➜ nginx kill -SIGHUP 13775 
# 查看hup之后的进程结果（worker进程们的pid变了，说明worker们 reload了 子进程无论是新启还是kill 都会给master发送信号
➜ nginx ps -ef | grep nginx
  501 13775     1   0  8:42下午 ??         0:00.00 nginx: master process /Users/xiaohuochai/Desktop/nginx/sbin/nginx
  501 13942 13775   0  8:46下午 ??         0:00.00 nginx: worker process
  501 13948   885   0  8:46下午 ttys005    0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn nginx
➜ nginx

 

nginx使用信号管理父子进程

（进程间交换数据必须通过内核，常见的多进程间通信方式：共享内存、信号、匿名管道、有名管道、高级管道、消息队列、信号量、套接字） 

master、worker、nginx命令行都可以发送信号，控制进程。

linux规定，当子进程终止的时候，会向父进程发送‘chld’ 信号。

master从worker接收到的消息，分别表示：

  • TERM/INT 表示立刻停止nginx进程
  • QUIT 优雅的停止nginx进程
  • HUP 重载配置文件
  • USR1 重新打开日志文件，做日志文件的切割
  • USR2 热部署使用，见下面热部署流程
  • WINCH  热部署使用

reload重载配置文件的真相

当配置文件发生改变的时候，都会nginx -s reload，在不影响现有业务不宕机的情况下，如何平滑的更新nginx配置。

 

老配置worker如果长时间不优雅退出，也不会影响新worker，但是会占用系统资源。nginx提供了一个配置shutdown_timeout，可以在worker进程timeout时候强制关闭。

 

热升级的完整流程 

 

 

reload --重新加载，reload会重新加载配置文件，Nginx服务不会中断，master进程不会退出。而且reload时会测试conf语法等，如果出错会rollback用上一次正确配置文件保持正常运行。

restart --重启（先stop后start），会重启Nginx服务，新启master，关闭旧的master，如果配置文件出错会导致服务启动失败，那就是更长时间的服务中断了。

 

 优雅的关闭worker进程

worker关闭连接池的所有连接后，才会退出进程。如果超时，所有链接会被强制关闭。

 

网络收发与nginx事件间的对应关系

 

wireshark和charles抓包有什么优缺点？

（感觉wireshark复杂一些？？

 

nginx的事件驱动模型， 事件循环+分发

当有新事件到达时，push进事件队列，但是如果事件队列中的时间长时间得不到处理，引发恶性循环，大量的cpu计算资源都会消耗在不正常的事件。

 

epoll（网络事件收集器模型）的优劣以及原理

 

 这张图比较了几种常见的事件处理模型，横轴是连接句柄也就是并发数量，纵轴是随着并发增加分发事件所消耗的时间，图中曲线代表着不同的事件分发模型的效率。

epoll的事件处理时间与句柄数增加几乎是无关的，适合做大并发连接的处理，在linux 2.5.44内核中被引入（深入浅出nodejs里面有讲

 

nginx的请求切换

 

 

传统web服务，如tomcat等，会在多进程间切换，切换的损耗很大。nginx的worker，只要在cpu分配的时间片内，就不会在多个process之间切换，在本进程时间片结束前处理多个请求。

 

同步&异步、阻塞&非阻塞之间的区别

 

 

 

 

阻塞和非阻塞，其实指的是底层的系统调用，是否会引起sleeping。非阻塞，即使时间片用完，也不会被切换掉。 

如何在非阻塞情况下处理同步与异步？（开发效率与运行效率的平衡

 

nginx的模块究竟是什么？

nginx官方模块说明(modules reference)：http://nginx.org/en/docs/

nginx有很多模块，编译的时候，可以选择需要哪些模块，比如压缩（ngx_http_gzip_filter_module）模块，然后这个模块就会被编译进nginx。 

有些模块默认会被使用，有些模块需要手动配置才会被使用。

大模块也会有子模块，比如ngx_http_gzip_filter_module，就是http模块的子模块.

怎么知道该模块支持哪些命令呢？

进 /src/http/ngx_http_gzip_filter_module.c文件找到 ngx_command_t 结构体片段，ngx_command_t是一个数组，数组中列出了该模块支持的指令名和参数。

 

// ngx_http_gzip_filter_module 的 ngx_command_t 说明该模块有那些指令
static ngx_command_t  ngx_http_gzip_filter_commands[] = {

    { ngx_string("gzip"),
      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF
                        |NGX_CONF_FLAG,
      ngx_conf_set_flag_slot,
      NGX_HTTP_LOC_CONF_OFFSET,
      offsetof(ngx_http_gzip_conf_t, enable),
      NULL },

    { ngx_string("gzip_buffers"),
      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE2,
      ngx_conf_set_bufs_slot,
      NGX_HTTP_LOC_CONF_OFFSET,
      offsetof(ngx_http_gzip_conf_t, bufs),
      NULL },

    { ngx_string("gzip_types"),
      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_1MORE,
      ngx_http_types_slot,
      NGX_HTTP_LOC_CONF_OFFSET,
      offsetof(ngx_http_gzip_conf_t, types_keys),
      &ngx_http_html_default_types[0] },

    { ngx_string("gzip_comp_level"),
      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1,
      ngx_conf_set_num_slot,
      NGX_HTTP_LOC_CONF_OFFSET,
      offsetof(ngx_http_gzip_conf_t, level),
      &ngx_http_gzip_comp_level_bounds },

    { ngx_string("gzip_window"),
      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1,
      ngx_conf_set_size_slot,
      NGX_HTTP_LOC_CONF_OFFSET,
      offsetof(ngx_http_gzip_conf_t, wbits),
      &ngx_http_gzip_window_p },

    { ngx_string("gzip_hash"),
      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1,
      ngx_conf_set_size_slot,
      NGX_HTTP_LOC_CONF_OFFSET,
      offsetof(ngx_http_gzip_conf_t, memlevel),
      &ngx_http_gzip_hash_p },

      ngx_null_command
};


static ngx_http_module_t  ngx_http_gzip_filter_module_ctx = {
    ngx_http_gzip_add_variables,           /* preconfiguration */
    ngx_http_gzip_filter_init,             /* postconfiguration */

    NULL,                                  /* create main configuration */
    NULL,                                  /* init main configuration */

    NULL,                                  /* create server configuration */
    NULL,                                  /* merge server configuration */

    ngx_http_gzip_create_conf,             /* create location configuration */
    ngx_http_gzip_merge_conf               /* merge location configuration */
};


// ngx_http_gzip_filter_module 的 ngx_module_t  说明该模块
ngx_module_t  ngx_http_gzip_filter_module = {
    NGX_MODULE_V1,
    &ngx_http_gzip_filter_module_ctx,      /* module context */
    ngx_http_gzip_filter_commands,         /* module directives */
    NGX_HTTP_MODULE,                       /* module type 属于哪一个类型的模块 */
    NULL,                                  /* init master */
    NULL,                                  /* init module */
    NULL,                                  /* init process */
    NULL,                                  /* init thread */
    NULL,                                  /* exit thread */
    NULL,                                  /* exit process */
    NULL,                                  /* exit master */
    NGX_MODULE_V1_PADDING
};

模块分类，下图中包含6个大模块，每个大模块又包含很多子模块，比如响应过滤模块可以对响应做二次处理压缩等、upstream模块，当nginx代理请求时，将请求传递给相关的上有服务处理时，就需要upstream模块

 

 

 现在来看看nginx源码里面子模块的位置：

http下子模块，modules里面放的是一些非必须的模块：

 

 

 

nginx如何通过连接池处理网络请求 

 连接和事件是怎么对应在一起的？

 每一个worker进程下面都会有 ngx_cycle_t 这个结构体(源码里面都可以找到)，里面定义了预留connection的数量（http://nginx.org/en/docs/ngx_core_module.html#worker_connections），每个connection会自动对应到客户端上下游的连接，比如一个read_event | write_event，所以read_events 和 write_events的数量和connections一样，index也是对应的。

每个connection所占用的内存资源，根据操作系统位数不同而有差异。在64位操作系统中，每个ngx_connection_s大约占用232字节，再加上两个读事件和写事件，一共是232B + 96*2B.

假设一个worker进程连接池预留512个连接，name初始化时候大概需要 512*（232B + 96*2B）=212KB。当然，所有这些配置都是可配的。

 

内存池对性能的影响

上一节中讲到了 ngx_connection_s 这个结构体，里面有一个变量叫做“ngx_pool_t *pool;”，由connection_pool_size指定，指的就是这个连接所要使用的内存池，默认size是256|512（http://nginx.org/en/docs/http/ngx_http_core_module.html#connection_pool_size）。

请求内存池，默认size是4K（http://nginx.org/en/docs/http/ngx_http_core_module.html#request_pool_size），因为请求需要保存大量的上下文信息，比如url、header等所以预分配内存较大。

 

所有worker进程协同工作的关键

worker进程之间只能通过共享内存进行数据共享。

 

 

 

 用好共享内存的工具slab管理器

 

nginx容器，下面重点说一下哈希表

 

 

 哈希表的max_size与bucket_size如何配置

 

 

 

 nginx的哈希表一般用来存放静态的不变的内容，一旦确定，就不会有插入和删除操作。上图右边树图列出了部分使用哈希表的模块，

nginx中最常用的容器--红黑树

nginx进程间内存共享时，经常使用红黑树进行对象管理。

红黑树是一个查找二叉树，左子节点都小于右子节点，高度差不会太大，

 

红黑树优点：

 

部分使用红黑树的模块：

 

 

 使用动态模块提升运维效率

 

posted on 2020-08-03 14:36  搭错车的小火柴  阅读(219)  评论(0)  编辑  收藏  举报