关于nginx架构探究(2)

  • nginx 数据结构

  1.Hash table

  nginx 对虚拟主机的管理使用到了HASH数据结构,假设配置文件里有如下的配置。

  Server{

  listen 192.168.0.1

  server_name xxxx

}

....

Server{

  listen 192.168.0.2

  server_name xxx1

}

  当Nginx以此配置文件正常启动后,如果来了一个客户端请求192.168.0.1的80端口,那么Nginx肯定要查询,看是使用哪个Server配置。为了提高查找效率,所以在启动开始后,Nginx就将根据这些server_name建立起一个Hash数据结构,如下图所示:

  

  上图中,字段buckets指向的就是Hash节点所对应的存储空间,不过这里具体实现时用的是二级指针,那么*buckets本身是一个数组,每一个数组元素用来存储映射到此的Hash节点。由于可能有多个实际元素映射到同一个Hash节点(发生Hash冲突),所以对实际元素再次进行数组形式的组织存储在一个bucket内,这个数组的结束以哨兵元素NULL作为标记,而前面的每一个ngx_hash_elt_t结构对应一个实际元素的存储。这里的实例,整体上也就形成上面所示那样的结构图。对于4个实际元素的Hash  数据结构,只有5个Hash节点,并且正好没有冲突,这主要是归功与ngx_hash_init()函数,通过它的提前测试,确定了Hash节点的个数。具体过程:逐步增加Hash节点数目(对应bucket数目同步增加),然后把所有的实际元素往这些bucket里添加,这有可能发生冲突,但只要冲突的次数可以容忍(即任意一个bucket都还没满),那么就继续填,如果发生有任何一个bucket满溢了,就必须增加Hash节点、增加bucket。如果所有的实际元素都填完没有发生满溢,那么当前的size就是最终的节点数目值。

  2. Radix tree

   Radix tree(基树),是一种基于二进制表示健值的二叉查找树,正是由于其健值的这个特点,所以只有在特定的情况下才会使用,典型的应用场景有文件系统、路由表等。Nginx提供的基树仅被geo模块使用,这个模块使用基树来处理IP地址的匹配查找。其次key与节点的对应是从高位向地位逐步匹配的。这是因为geo模块里真正使用的IP网络地址,比如192.168.0.0/16,它们前面bit为才是有效区分位,如果从后往前匹配,会产生大量bit 0,那么导致任何一个IP地址插入到基数上都是32层。ngx_radix32tree_insert()和ngx_radix32tree_delete()中,引入mask就是告诉插入函数只需匹配前多少位。这就是最长前缀匹配。

     

  • nginx配置解析

  Nginx配置文件可以认为是一种上下文相关的,高度可扩展的,有作用域。Ngix配置项有简单配置项和复杂配置项,对于复杂配置项而言,Nginx并不做具体的解析与赋值操作,一般只是申请对应的内容空间、切换解析状态,然后递归调用解析函数,而真正将用户配置信息转换为Nginx内控制变量的值,还是依靠那些简单配置项所对应的处理函数来做。

  无论是简单配置项还是复杂配置项,他们的项目名和项目值都是有标记(token:这里是指一个配置文件字符串内容中被空格、引号、分号、tab号、括号等)组成的,配置项目名就是一个token,而配置项目值可以是一个、两个和多个token组成。比如:

error_page 404 /404.html;

  其项目名为error_page,其项目值为404及404.html两个。Nginx配置文件里的注释信息以#作为开头标记。根据Nginx应用本身的特点,我们可以对配置文件作上下文识别和区分,或者说是配置项的作用域。因为虽然某项配置项在同一个上下恩里只可以设置一次,但却可以在不同的上下文里设置多次,以便达到更细粒度的控制。

  目前Nginx预定义的配置上下文主要包括main、http、server、location4种(还有其他几种,比如event、upstream、if、mail等)这些上下文相当于一个独立的作用域。Ngix_conf_parse()函数是解析配置文件的关键函数,这个函数是一个间接递归函数,也就是说虽然我们在该函数体内看不到直接的对其本身的调用,但是它执行的一些其它函数(比如ngx_conf_hander()里面会调用ngx_conf_parse()函数),从而形成递归。ngx_conf_parse()解析配置内容的过程分为三个步骤:

  1. 判断当前解析状态
  2. 读取配置标记token
  3. 读取合适数量的token后对其进行实际的处理,也就是将配置值准换为nginx内对应控制变量(nginx转换很简单,直接转换key/value)

  所有的配置信息按照模块进行管理,转换之后的变量也按照模块进行管理。同事配置信息还可以继承,如果location中还有location,那么对于在某个层次没有设置的配置选项,它的值应该来自上一层。    

  

  

时间: 2024-10-06 08:59:45

关于nginx架构探究(2)的相关文章

关于nginx架构探究(1)

nginx的架构主要是有一个主监控进程:master;三个工作进程:worker:还有Cache的两个进程.back-end-server是后端服务器,主要是处理后台逻辑.nginx作为代理服务器需要和前端web以及后端server通讯 master大多数情况下是挂起的,直到有信号来,比如worker进程down掉了,那么会产生singnal给master进程,直到回复到初始状态,然后又被挂起. worker主要做的就是和后台及web端的I/O进程操作,做的是利用select,epoll_wai

关于nginx架构探究(3)

Nginx 模块综述 Nginx 所有的代码都是以模块的新式组织的,包括核心模块和功能模块.Nginx加载模块的时候不想Apache一样动态加载,它是直接被编译到二进制执行文件中,所以,如果想要加载新的模块,需要我们重新编译Nginx源码.比如:  ./configure --with-http_flv_module  执行上述编译选项后,就可以生成http_flv功能模块了.根据模块的功能性质,Nginx的模块大致可以分为以下四类:    1. handlers:协同完成客户端请求的处理.产生

关于nginx架构探究(4)

事件管理机制 Nginx是以事件驱动的,也就是说Nginx内部流程的向前推进基本都是靠各种事件的触发来驱动,否则Nginx将一直阻塞在函数epoll_wait()或suspend函数,Nginx事件一般分为I/O事件和定时事件,当一个事件到来后,监听FD的工作进程就开始处理事件,并执行回调函数,开始处理与响应. I/O多路复制机制,Nginx封装了各种系统平台下的I/O事件处理机制,使得在跨平台时高效运行.下图列举了一些常见的I/O事件处理机制: 上图中,epoll模型是目前最高效的机制,它相比

Keepalived+Nginx架构详解

Keepalived+Nginx架构 keepalived是一个类似于layer3.4.7交换机制的软件,也就是我们平时说的第3层.第4层和第7层交换.Keepalived的作用是检测web服务器的状态,如果有一台web服务器.Mysql服务器宕机,或工作出现故障,Keepalived将检测到后,会将有故障的web服务器或者Mysql服务器从系统中剔除,当服务器工作正常后Keepalived自动将web.Mysql服务器加入到服务器群中,这些工作全部自动完成,不需要人工干涉,需要人工做的只是修复

[转载] 深入 nginx 架构

原文: http://www.cnbeta.com/articles/402709.htm 了解 nginx 架构帮助我们学习如何开发高性能 web 服务. 为了更好地理解设计,你需要了解NGINX是如何工作的.NGINX之所以能在性能上如此优越,是由于其背后的设计.许多web服务器和应用服务器使用简单的线程的(threaded).或基于流程的 (process-based)架构, NGINX则以一种复杂的事件驱动(event-driven)的架构脱颖而出,这种架构能支持现代硬件上成千上万的并发

Nginx架构的企业级应用

Nginx架构的企业级应用 ==================================================== 实现HA高可用集群 实现LB负载均衡集群 Nginx实现反向代理 Nginx实现动静分离 ================================================== 需求: 客户端访问静态的请求,由nginx反向代理给后端的Apache服务器: 客户端访问动态的请求,由nginx反向代理给后端的php-fpm(fastCGI)服务器,而且

2.nginx架构及工作流程

nginx是模块化设计: 模块大致可以分为: 1.核心模块(core) 2.基础模块(http,mail) 3.第三方模块(upstream,proxy,fastcgi) 功能:1.核心模块为nginx作为webserver,web or mail proxy提供一个大的基础 2.基础模块是核心模块与扩展模块的抽象衔接,同时完成某协议的功能 3.第三方模块,在对应基础模块的基础上,完成特定功能 nginx架构: nginx对于一个http请求的处理流程: 1.tcp/ip连接建立 2.woerk

Nginx 架构和基础原理

Nginx 的应用场景 Nginx 的应用场景主要有三个: 静态资源服务 反向代理服务 API 服务 静态资源服务 Nginx 可以通过本地文件系统提供静态资源的服务,例如纯静态的 HTML 页面等. 反向代理服务 很多应用服务的运行效率是很低的,QPS,TPS,并发等都是受限的,所以需要把很多应用服务组成一个集群,向用户提供高可用性的服务,这个时候需要 Nginx 的反向代理功能,而应用服务的动态扩容需要负载均衡功能,另外一个,Nginx 层还需要做缓存.因此反向代理服务主要是三个功能: 反向

nginx架构特性及编译安装

一.架构特性 nginx会按需同时运行多个进程:一个主进程(master)和几个工作进程(worker),配置了缓存时还会有缓存加速器进程(cache loader)和缓存管理器进程(cache manager)等,所有进程是仅含有一个线程,并主要通过"共享内存"的机制实现进程间通信,主进程以root用户身份运行,而worker.cacher loader和cache manager均应以非特权用户身份运行. 主进程主要完成如下工作: 读取并验证配置信息: 创建.绑定及关闭套接字: 启