运行中的Nginx进程间的关系
- 格式:docx
- 大小:96.95 KB
- 文档页数:4
Nginx和Keepalived的组合常用于实现高可用性(High Availability, HA)的Web服务。
下面简要介绍Nginx和Keepalived的工作原理以及它们如何一起提供高可用性。
Nginx工作原理1. 反向代理:Nginx作为一个反向代理服务器,接受客户端的请求,然后将请求转发到后端服务器(如Apache、Tomcat等)。
它可以根据配置将请求分发到不同的后端服务器上,实现负载均衡。
2. 热重载:Nginx能够在不重启的情况下动态更新配置,这使得它能够快速适应服务变化,如后端服务器的故障或新增。
3. 高性能:Nginx使用异步事件驱动的方法处理请求,这使得它在处理大量并发请求时具有很高的性能。
Keepalived工作原理1. VRRP(Virtual Router Redundancy Protocol):Keepalived实现VRRP协议,用于提供IP地址(虚拟IP,VIP)的高可用性。
VRRP允许多个路由器(或Keepalived实例)协同工作,共同提供虚拟IP的服务,其中一个是主路由器,负责处理所有的请求,其他的是备份路由器。
2. 健康检查:Keepalived可以配置健康检查脚本来监控Nginx实例的状态。
如果主Nginx实例发生故障,Keepalived将自动将VIP切换到备份Nginx实例上。
3. 故障转移:当主Nginx实例不可用时,Keepalived会根据配置的策略(如抢占式或非抢占式)将VIP转移给备用实例。
Nginx与Keepalived的结合1. 配置Nginx:在Nginx配置中,通常会设置一个监听端口,并将请求代理到Keepalived管理的VIP上。
2. 配置Keepalived:Keepalived配置中定义了VIP和两个Nginx 实例(主备关系)。
它使用VRRP协议确保VIP的高可用性,并使用健康检查来监控Nginx实例。
3. 故障切换:当主Nginx实例发生故障时,Keepalived会自动将VIP切换到备用Nginx实例,这样就可以确保Web服务的连续性。
nginx详细配置Nginx内容概览1、nginx简介(1)介绍 nginx的应⽤场景和具体可以做什么事情(2)介绍什么是反向代理(3)介绍什么是负载均衡(4)介绍什么是动静分离2、nginx安装(1)介绍 nginx在 linux系统中如何进⾏安装3、nginx常⽤的命令和配置⽂件(1)介绍 nginx启动、关闭、重新加载命令(2)介绍 nginx的配置⽂件4、nginx配置实例-反向代理5、nginx配置实例-负载均衡6、nginx配置实例-动静分离7、nginx原理与优化参数配置8、搭建 nginx⾼可⽤集群(1)搭建 nginx⾼可⽤集群(主从模式)(2)搭建 nginx⾼可⽤集群(双主模式)第 1 章 Nginx 简介1.1 Nginx 概述Nginx ("engine x") 是⼀个⾼性能的 HTTP 和反向代理服务器,特点是占有内存少,并发能⼒强,事实上 nginx的并发能⼒确实在同类型的⽹页服务器中表现较好,中国⼤陆使⽤ nginx⽹站⽤户有:百度、京东、新浪、⽹易、腾讯、淘宝等1.2 Nginx 作为 web 服务器Nginx 可以作为静态页⾯的 web 服务器,同时还⽀持 CGI 协议的动态语⾔,⽐如 perl、php等。
但是不⽀持 java。
Java程序只能通过与tomcat配合完成。
Nginx专为性能优化⽽开发,性能是其最重要的考量,实现上⾮常注重效率,能经受⾼负载的考验,有报告表明能⽀持⾼达50,000个并发连接数。
1.3 正向代理Nginx 不仅可以做反向代理,实现负载均衡。
还能⽤作正向代理来进⾏上⽹等功能。
正向代理:如果把局域⽹外的 Internet 想象成⼀个巨⼤的资源库,则局域⽹中的客户端要访问Internet,则需要通过代理服务器来访问,这种代理服务就称为正向代理。
1.4 反向代理反向代理,其实客户端对代理是⽆感知的,因为客户端不需要任何配置就可以访问,我们只需要将请求发送到反向代理服务器,由反向代理服务器去选择⽬标服务器获取数据后,在返回给客户端,此时反向代理服务器和⽬标服务器对外就是⼀个服务器,暴露的是代理服务器地址,隐藏了真实服务器 IP地址。
nginx底层原理Nginx,全称为“engine x”(发音为“engine-ex”),是一款高性能的HTTP和反向代理服务器,也是一款由俄罗斯的程序员Igor Sysoev所开发的自由及开放源代码的Web服务器软件。
Nginx能够出色地处理高并发、静态文件服务以及反向代理,可实现负载均衡,还能充当反向代理服务器和正向代理服务器,同时支持多种协议,如IMAP/POP3/SMTP/HTTP/HTTPS等。
Nginx的底层原理是基于事件驱动的架构,它的核心是一个引擎,它将客户端发送过来的请求分发给各个worker process,worker process再根据不同的类型的请求处理相应的逻辑,最终返回给客户端响应信息。
Nginx的底层原理分为三个部分:master 进程、工作进程和事件循环机制。
1. Master进程Master进程是Nginx的核心,它负责监听端口,当有请求进来时,它会将请求分发给相应的工作进程,并定期检查工作进程的运行状况,如果发现某个工作进程出现异常,它会重新启动一个新的工作进程来替换掉原来的工作进程,以保证服务的正常运行。
2. Worker进程Worker进程是Nginx服务的真正实现者,它负责接收Master进程分发的请求,并对请求进行处理,最后将结果返回给客户端,同时它还负责解析配置文件、编译模块、更新日志等。
3. 事件循环机制事件循环机制是一种特殊的机制,用于管理Nginx中的各种事件,它能够有效地帮助Nginx提高处理请求的效率。
Nginx采用了一种叫做“Reactor模式”的事件循环机制,它将Nginx服务程序分解成多个小模块,每个模块负责处理一种事件,当有事件发生时,会以消息的方式将事件分发给各个模块,然后每个模块处理完消息后,将结果返回给Nginx,从而使Nginx能够高效地处理大量的请求。
Nginx具有高性能、高可用性、低资源消耗等优点,它的底层原理是基于事件驱动的架构,它的核心是一个引擎,它将客户端发送过来的请求分发给各个worker process,worker process再根据不同的类型的请求处理相应的逻辑,最终返回给客户端响应信息;同时Nginx还采用了一种叫做“Reactor模式”的事件循环机制,它将Nginx服务程序分解成多个小模块,每个模块负责处理一种事件,从而使Nginx能够高效地处理大量的请求。
Nginx性能优化有这篇就够了!⽬录:1、Nginx运⾏⼯作进程数量Nginx运⾏⼯作进程个数⼀般设置CPU的核⼼或者核⼼数x2。
如果不了解cpu的核数,可以top命令之后按1看出来,也可以查看/proc/cpuinfo ⽂件 grep ^processor /proc/cpuinfo | wc -l[root@lx~]# vi/usr/local/nginx1.10/conf/nginx.confworker_processes 4;[root@lx~]# /usr/local/nginx1.10/sbin/nginx-s reload[root@lx~]# ps -aux | grep nginx |grep -v greproot 9834 0.0 0.0 47556 1948 ? Ss 22:36 0:00 nginx: master processnginxwww 10135 0.0 0.0 50088 2004 ? S 22:58 0:00 nginx: worker processwww 10136 0.0 0.0 50088 2004 ? S 22:58 0:00 nginx: worker processwww 10137 0.0 0.0 50088 2004 ? S 22:58 0:00 nginx: worker processwww 10138 0.0 0.0 50088 2004 ? S 22:58 0:00 nginx: worker process2、Nginx运⾏CPU亲和⼒⽐如4核配置:worker_processes 4;worker_cpu_affinity 0001 0010 0100 1000⽐如8核配置:worker_processes 8;worker_cpu_affinity 00000001 00000010 00000100 0000100000010000 00100000 01000000 10000000;worker_processes最多开启8个,8个以上性能提升不会再提升了,⽽且稳定性变得更低,所以8个进程够⽤了。
ingress-nginx工作原理Ingress-Nginx是Kubernetes集群中用于管理流量和进行负载均衡的一个常用工具。
它是基于Nginx的反向代理服务器,通过将外部流量路由到集群内部的服务,实现了高性能的负载均衡和流量控制。
Ingress-Nginx的工作原理如下:1. 定义Ingress规则:管理员通过Ingress资源定义了一组规则,指定了外部请求如何访问集群中的服务。
每个Ingress规则包含了一个或多个路径和相应的服务。
2. 部署Ingress-Nginx控制器:在集群中部署Ingress-Nginx控制器,它会监听Kubernetes API Server上的Ingress资源的变化。
3. Nginx配置生成:Ingress-Nginx控制器会根据Ingress资源的定义,生成相应的Nginx配置文件。
4. 负载均衡和流量路由:Nginx根据生成的配置文件进行负载均衡和流量路由。
当外部请求到达Ingress-Nginx的Load Balancer时,它会根据配置将请求路由到对应的后端服务上进行处理。
5. SSL/TLS支持:Ingress-Nginx支持通过自签名或使用公共证书来提供加密通信,可以在Ingress规则中配置相应的TLS相关信息。
6. 日志和监控:Ingress-Nginx控制器会记录请求和回复的详细日志,可以通过这些日志来进行监控和排查问题。
7. 动态配置:管理员可以通过更新对应的Ingress资源来进行动态配置,例如更改路径、添加新的服务等,这些更改会被Ingress-Nginx控制器自动更新并应用到Nginx配置中。
总结起来,Ingress-Nginx的工作流程是定义Ingress规则 -> 部署Ingress-Nginx控制器 -> Nginx配置生成 -> 负载均衡和流量路由。
它通过控制器和Nginx的配合,使得流量可以根据规则进行分发和路由,从而实现了高效的负载均衡和流量控制。
nginx reload原理nginx reload的原理是,当执行reload命令时,nginx会将当前的配置文件进行备份,然后使用备份的配置文件来重新加载nginx,这样就可以实现在不停止服务的情况下更新nginx的配置。
在重新加载配置的过程中,nginx会先读取新的配置文件,然后根据新的配置文件来重新启动nginx,从而更新服务器的配置。
此外,nginx还支持在重新加载配置时进行平滑升级,即逐步更新nginx的各个模块,以保证服务的连续性。
nginx的平滑升级是通过在升级过程中将新的配置文件和旧的配置文件进行合并来实现的。
nginx reload的原理是通过备份和重新加载配置文件来实现在不停止服务的情况下更新nginx的配置,并且支持平滑升级以保证服务的连续性。
在实现nginx reload的过程中,还有一些关键的步骤需要注意。
首先,当nginx接收到reload命令时,它会先保存当前的配置文件到一个临时文件中,然后读取新的配置文件。
这个过程通常需要一些时间,因为nginx需要解析新的配置文件并更新其内部的数据结构。
其次,nginx在重新加载配置文件时,会先关闭当前正在运行的worker进程,然后根据新的配置文件启动新的worker进程。
这个过程中,nginx会尽可能地减少对客户端的影响,例如在关闭worker进程之前,nginx会先处理完当前正在处理的请求。
最后,nginx在重新启动worker进程之后,会进行一次自检,以确保新的配置文件没有问题。
如果自检成功,nginx就会继续提供服务;否则,nginx会恢复到旧的配置文件,并重新启动worker进程。
nginx reload的原理是通过备份和重新加载配置文件来实现不停止服务的情况下更新nginx的配置。
这个过程中,nginx 会尽可能地减少对客户端的影响,并保证服务的连续性。
除了重新加载配置文件,nginx还支持配置文件的自动重新加载。
进程之间的逻辑关系进程是计算机系统中的基本概念,是操作系统进行资源分配和调度的基本单位。
在一个多进程的系统中,各个进程之间存在着不同的逻辑关系,这些关系对于系统的正常运行和协调工作起着至关重要的作用。
本文将从进程之间的逻辑关系展开讨论,包括进程的同步与互斥、进程的通信以及进程调度等方面。
一、进程的同步与互斥进程的同步与互斥是指多个进程之间在执行过程中的协调与合作关系。
在多进程的系统中,不同的进程可能会共享同一资源,为了保证资源的正确使用和避免冲突,进程之间需要进行同步与互斥操作。
同步操作是指多个进程按照一定的顺序执行,保证程序的正确性。
常见的同步机制有信号量、互斥锁等。
例如,在生产者-消费者模型中,生产者进程负责生产产品,消费者进程负责消费产品,两者之间需要进行同步操作,以保证生产与消费的顺序和数量的一致性。
互斥操作是指多个进程之间对共享资源的访问进行互斥控制,避免出现资源冲突。
互斥锁是实现互斥操作的常见机制,通过对共享资源进行加锁和解锁操作,保证同一时间只有一个进程可以访问共享资源。
例如,在多线程的环境中,多个线程可能同时访问同一个全局变量,通过互斥锁机制可以实现对全局变量的互斥访问,避免出现数据不一致的情况。
二、进程的通信进程的通信是指多个进程之间进行信息交换和共享资源的过程。
在一个多进程的系统中,进程之间可能需要进行数据的传递、共享内存、消息传递等操作,以实现信息的交流和共享资源的利用。
常见的进程通信方式包括管道、共享内存、消息队列、信号量等。
例如,在分布式系统中,不同的进程之间可能需要共享内存中的数据,可以通过共享内存的方式实现数据的共享和协作。
进程通信的目的是为了实现进程之间的协作与合作,共同完成任务。
通过进程通信,不同的进程可以共享资源、传递消息、协调工作,提高系统的整体性能和效率。
三、进程的调度进程调度是指操作系统根据一定的策略和算法来决定进程的执行顺序和调度方式。
在一个多进程的系统中,各个进程之间的调度关系直接影响着系统的性能和响应速度。
Nginx由内核和模块组成,其中,内核的设计非常微小和简洁,完成的工作也非常简单,仅仅通过查找配置文件将客户端请求映射到一个location block(location是Nginx配置中的一个指令,用于URL匹配),而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。
Nginx的模块从结构上分为核心模块、基础模块和第三方模块:核心模块:HTTP模块、EVENT模块和MAIL模块基础模块:HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite 模块,第三方模块:HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。
用户根据自己的需要开发的模块都属于第三方模块。
正是有了这么多模块的支撑,Nginx 的功能才会如此强大。
Nginx的模块从功能上分为如下三类。
Handlers(处理器模块)。
此类模块直接处理请求,并进行输出内容和修改headers 信息等操作。
Handlers处理器模块一般只能有一个。
Filters (过滤器模块)。
此类模块主要对其他处理器模块输出的内容进行修改操作,最后由Nginx输出。
Proxies (代理类模块)。
此类模块是Nginx的HTTP Upstream之类的模块,这些模块主要与后端一些服务比如FastCGI等进行交互,实现服务代理和负载均衡等功能。
图1-1展示了Nginx模块常规的HTTP请求和响应的过程。
图1-1展示了Nginx模块常规的HTTP请求和响应的过程。
Nginx本身做的工作实际很少,当它接到一个HTTP请求时,它仅仅是通过查找配置文件将此次请求映射到一个location block,而此location中所配置的各个指令则会启动不同的模块去完成工作,因此模块可以看做Nginx真正的劳动工作者。
通常一个location中的指令会涉及一个handler模块和多个filter模块(当然,多个location可以复用同一个模块)。
Nginx源码分析:3张图看懂启动及进程⼯作原理编者按:⾼可⽤架构分享及传播在架构领域具有典型意义的⽂章,本⽂由陈科在⾼可⽤架构群分享。
转载请注明来⾃⾼可⽤架构公众号「ArchNotes」。
导读:很多⼯程师及架构师都希望了解及掌握⾼性能服务器开发,阅读优秀源代码是⼀种有效的⽅式,nginx 是业界知名的⾼性能 Web 服务器实现,如何有效的阅读及理解 nginx?本⽂⽤图解的⽅式帮助⼤家来更好的阅读及理解 nginx 关键环节的实现。
陈科,⼗年⾏业从业经验,曾在浙江电信、阿⾥巴巴、华为、五⼋同城任开发⼯程及架构师等职,⽬前负责河狸家后端架构和运维。
博客地址:/wiki/doku.php图⼀:nginx 启动及内存申请过程分析任何程序都离不开启动和配置解析。
ngx 的代码离不开 ngx_cycle_s 和 ngx_pool_s 这两个核⼼数据结构,所以我们在启动之前先来分析下。
内存申请过程分为 3 步1. 假如申请的内存⼩于当前块剩余的空间,则直接在当前块中分配。
2. 假如当前块空间不⾜,则调⽤ ngx_palloc_block 分配⼀个新块然后把新块链接到 d.next中,然后分配数据。
3. 假如申请的⼤⼩⼤于当前块的最⼤值,则直接调⽤ ngx_palloc_large 分配⼀个⼤块,并且链接到 pool→large 链表中内存分配过程图解如下(图⽚来⾃⽹络)为了更好理解上⾯的图,可以参看⽂末附 2 的⼏个数据结构:ngx_pool_s 及 ngx_cycle_s。
知道了这两个核⼼数据结构之后,我们正式进⼊ main 函数,main 函数执⾏过程如下调⽤ ngx_get_options() 解析命令参数;调⽤ ngx_time_init() 初始化并更新时间,如全局变量ngx_cached_time;调⽤ ngx_log_init() 初始化⽇志,如初始化全局变量 ngx_prefix,打开⽇志⽂件ngx_log_file.fd;清零全局变量 ngx_cycle,并为 ngx_cycle.pool 创建⼤⼩为 1024B 的内存池;调⽤ ngx_save_argv() 保存命令⾏参数⾄全局变量 ngx_os_argv、ngx_argc、ngx_argv 中;调⽤ ngx_os_init() 初始化系统相关变量,如内存页⾯⼤⼩ ngx_pagesize , ngx_cacheline_size ,最⼤连接数 ngx_max_sockets 等;调⽤ ngx_crc32_table_init() 初始化 CRC 表 ( 后续的 CRC 校验通过查表进⾏,效率⾼ );调⽤ ngx_add_inherited_sockets() 继承 sockets:解析环境变量 NGINX_VAR = 'NGINX' 中的 sockets,并保存⾄ ngx_cycle.listening 数组;设置 ngx_inherited = 1;调⽤ ngx_set_inherited_sockets() 逐⼀对 ngx_cycle.listening 数组中的 sockets 进⾏设置;初始化每个 module 的 index,并计算 ngx_max_module;调⽤ ngx_init_cycle() 进⾏初始化;该初始化主要对 ngx_cycle 结构进⾏;若有信号,则进⼊ ngx_signal_process() 处理;调⽤ ngx_init_signals() 初始化信号;主要完成信号处理程序的注册;若⽆继承 sockets,且设置了守护进程标识,则调⽤ ngx_daemon() 创建守护进程;调⽤ ngx_create_pidfile() 创建进程记录⽂件;( ⾮ NGX_PROCESS_MASTER = 1 进程,不创建该⽂件 )进⼊进程主循环;若为 NGX_PROCESS_SINGLE=1模式,则调⽤ ngx_single_process_cycle() 进⼊进程循环;否则为 master-worker 模式,调⽤ ngx_master_process_cycle() 进⼊进程循环;在 main 函数执⾏过程中,有⼀个⾮常重要的函数 ngx_init_cycle,这个阶段做了什么呢?下⾯分析 ngx_init_cycle,初始化过程:1. 更新 timezone 和 time2. 创建内存池3. 给 cycle 指针分配内存4. 保存安装路径,配置⽂件,启动参数等5. 初始化打开⽂件句柄6. 初始化共享内存7. 初始化连接队列8. 保存 hostname9. 调⽤各 NGX_CORE_MODULE 的 create_conf ⽅法10. 解析配置⽂件11. 调⽤各NGX_CORE_MODULE的init_conf⽅法12. 打开新的⽂件句柄13. 创建共享内存15. 创建socket进⾏监听16. 调⽤各模块的init_module图⼆:master 进程⼯作原理及⼯作⼯程以下过程都在ngx_master_process_cycle 函数中进⾏,启动过程:1. 暂时阻塞所有 ngx 需要处理的信号2. 设置进程名称3. 启动⼯作进程4. 启动cache管理进程5. 进⼊循环开始处理相关信号master 进程⼯作过程1. 设置 work 进程退出等待时间2. 挂起,等待新的信号来临3. 更新时间4. 如果有 worker 进程因为 SIGCHLD 信号退出了,则重启 worker 进程5. master 进程退出。
nginx reload原理摘要:1.nginx简介2.nginx reload原理3.常用nginx配置文件参数4.nginx reload的实际应用5.nginx reload注意事项正文:## 1.nginx简介ginx是一款高性能的HTTP服务器和反向代理服务器,广泛应用于网站后端服务。
它具有高性能、稳定性强、易于配置等优点,受到许多开发者和运维人员的喜爱。
## 2.nginx reload原理ginx reload是指在不重启服务器的情况下,加载新的配置文件并生效。
nginx reload的原理主要是通过发送信号给正在运行的nginx进程,使其重新加载配置文件。
常用的信号有HUP(SIGHUP)和USR1(SIGUSR1)。
## 3.常用nginx配置文件参数- worker_processes:设置工作进程数,用于处理并发请求。
- worker_connections:设置每个工作进程可处理的并发连接数。
- events:设置事件模块相关参数,如事件循环器、连接队列等。
- timeout:设置客户端和服务器超时时间。
- keepalive:设置keep-alive参数,提高服务器资源利用率。
## 4.nginx reload的实际应用1.修改配置文件:当需要修改nginx配置文件时,可以通过发送HUP信号使nginx进程重新加载配置文件。
这样,无需重启服务器,便能实现配置文件的更新。
2.动态加载模块:通过发送USR1信号,可以动态加载或卸载nginx模块。
这对于在运行时切换模块,实现功能扩展十分方便。
3.重启集群:当需要对nginx集群进行升级或维修时,可以通过发送HUP 信号使所有工作进程重新加载配置文件。
此时,集群将进入热备状态,待维修完成后,重新发送HUP信号使集群恢复正常运行。
## 5.nginx reload注意事项1.确保新的配置文件语法正确,否则可能导致nginx无法正常加载配置文件。
运行中的Nginx进程间的关系
《深入理解Nginx:模块开发与架构解析》第2章Nginx的配置,本章的目的是熟悉Nginx的配置文件,包括配置文件的语法格式、运行所有Nginx服务必须具备的基础配置以及使用HTTP核心模块配置静态Web服务器的方法,最后还会介绍反向代理服务器。
本节为大家介绍运行中的Nginx进程间的关系。
Nginx的配置
Nginx拥有大量官方发布的模块和第三方模块,这些已有的模块可以帮助我们实现Web服务器上很多的功能。
使用这些模块时,仅仅需要增加、修改一些配置项即可。
因此,本章的目的是熟悉Nginx的配置文件,包括配置文件的语法格式、运行所有Nginx服务必须具备的基础配置以及使用HTTP核心模块配置静态Web服务器的方法,最后还会介绍反向代理服务器。
通过本章的学习,读者可以:熟练地配置一个静态Web服务器;对影响Web服务器性能的各个配置项有深入的理解;对配置语法有全面的了解。
通过互联网或其他途径得到任意模块的配置说明,然后可通过修改nginx.conf文件来使用这些模块的功能。
2.1 运行中的Nginx进程间的关系
在正式提供服务的产品环境下,部署Nginx时都是使用一个master进程来管理多个worker进程,一般情况下,worker 进程的数量与服务器上的CPU核心数相等。
每一个worker进程都是繁忙的,它们在真正地提供互联网服务,master进程则很“清闲”,只负责监控管理worker进程。
worker进程之间通过共享内存、原子操作等一些进程间通信机制来实现负载均衡等功能(第9章将会介绍负载均衡机制,第14章将会介绍负载均衡锁的实现)。
部署后Nginx进程间的关系如图2-1所示。
Nginx是支持单进程(master进程)提供服务的,那么为什么产品环境下要按照master-worker方式配置同时启动多个进程呢?这样做的好处主要有以下两点:
由于master进程不会对用户请求提供服务,只用于管理真正提供服务的worker进程,所以master进程可以是唯一的,它仅专注于自己的纯管理工作,为管理员提供命令行服务,包括诸如启动服务、停止服务、重载配置文件、平滑升级程序等。
master进程需要拥有较大的权限,例如,通常会利用root用户启动master进程。
worker进程的权限要小于或等于master进程,这样master进程才可以完全地管理worker进程。
当任意一个worker进程出现错误从而导致coredump 时,master进程会立刻启动新的worker进程继续服务。
多个worker进程处理互联网请求不但可以提高服务的健壮性(一个worker进程出错后,其他worker进程仍然可以正常提供服务),最重要的是,这样可以充分利用现在常见的SMP多核架构,从而实现微观上真正的多核并发处理。
因此,用一个进程(master进程)来处理互联网请求肯定是不合适的。
另外,为什么要把worker进程数量设置得与CPU核心数量一致呢?这正是Nginx与Apache服务器的不同之处。
在Apache上每个进程在一个时刻只处理一个请求,因此,如果希望Web服务器拥有并发处理的请求数更多,就要把Apache的进程或线程数设置得更多,通常会达到一台服务器拥有几百个工作进程,这样大量的进程间切换将带来无谓的系统资源消耗。
而Nginx则不然,一个worker进程可以同时处理的请求数只受限于内存大小,而且在架构设计上,不同的worker进程之间处理并发请求时几乎没有同步锁的限制,worker进程通常不会进入睡眠状态,因此,当Nginx上的进程数与CPU核心数相等时(最好每一个worker进程都绑定特定的CPU核心),进程间切换的代价是最小的。
举例来说,如果产品中的服务器CPU核心数为8,那么就需要配置8个worker进程(见图2-2)。
如果对路径部分都使用默认配置,那么Nginx运行目录为/usr/local/nginx,其目录结构如下。
1.|---sbin
2.| |---nginx
3.|---conf
4.| |---koi-win
5.| |---koi-utf
6.| |---win-utf
7.| |---mime.types
8.| |---mime.types.default
9.| |---fastcgi_params
10.| |---fastcgi_params.default
11.| |---fastcgi.conf
12.| |---fastcgi.conf.default
13.| |---uwsgi_params
14.| |---uwsgi_params.default
15.| |---scgi_params
16.| |---scgi_params.default
17.| |---nginx.conf
18.| |---nginx.conf.default
19.|---logs
20.| |---error.log
21.| |---access.log
22.| |---nginx.pid
23.|---html
24.| |---50x.html
25.| |---index.html
26.|---client_body_temp
27.|---proxy_temp
28.|---fastcgi_temp
29.|---uwsgi_temp
30.|---scgi_temp。