4.nginx原理

2022-05-26 20:00:20 阅读：167 来源： 互联网

https://blog.csdn.net/liupeifeng3514/article/details/79857060

https://www.cnblogs.com/chenjfblog/p/8715580.html
    
https://blog.csdn.net/hhhzua/article/details/79294735
1.Nginx在启动后，会有一个master进程和多个worker进程：
  worker进程的数量如何控制呢？
     nginx.conf配置文件中有一个worker_processes配置项，默认配置为：
         worker_processes 1
    worker进程的数量会直接影响性能。
    每一个worker进程都是单线程进程，它们调用各个模块以实现多种多样的功能，如果这些模块确认不会出现阻塞式调用，
    那么，有多少个CPU内核就配置多少个worker进程，如果有可能出现阻塞式调用，就需要稍多一些worker进程 
    
    例如 ：
    如果业务需要大量读取磁盘上的静态文件，而且服务器上的内存较小，以至于大部分的请求访问静态文件时都必须读取磁盘，
    而不是内存中的磁盘缓存，那么磁盘I/O调用可能会阻塞住worker进程少量时刻，进而导致服务整体性能下降。
    多worker进程可以充分利用多核系统架构，但若worker进程的数量多于CPU内核数，那么会增大进程间切换带来的消耗（Linux是抢占式内核）。 
    一般情况下，用户配置与内核数相等的worker进程，并使用worker_cpu_affinity配置来绑定CPU内核


1.master进程
    master进程主要用来管理worker进程，包含
        1.接收来自外界的信号；
        2.向各worker进程发送信号；
        3.监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。
master进程充当整个进程组与用户的交互接口，同时对进程进行监护。它不需要处理网络事件，不负责业务的执行，
只会通过管理worker进程来实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。
我们要控制nginx，只需要通过kill向master进程发送信号就行了。比如kill -HUP pid，则是告诉nginx，从容地重启nginx，
我们一般用这个信号来重启nginx，或重新加载配置，因为是从容地重启，因此服务是不中断的。

master进程在接收到HUP信号后是怎么做的呢？首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的worker进程，
并向所有老的worker进程发送信号，告诉他们可以光荣退休了。新的worker在启动后，就开始接收新的请求，而老的worker在收到来自master的信号后，
就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出。当然，直接给master进程发送信号，这是比较老的操作方式，
nginx在0.8版本之后，引入了一系列命令行参数，来方便我们管理。比如，./nginx -s reload，就是来重启nginx，./nginx -s stop，就是来停止nginx的运行。
如何做到的呢？我们还是拿reload来说，我们看到，执行命令时，我们是启动一个新的nginx进程，而新的nginx进程在解析到reload参数后，
就知道我们的目的是控制nginx来重新加载配置文件了，它会向master进程发送信号，然后接下来的动作，就和我们直接向master进程发送信号一样了。

worker进程
而基本的网络事件，则是放在worker进程中来处理了。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。
一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。
worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致，这里面的原因与nginx的进程模型以及事件处理模型是分不开的。
worker进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？
首先，每个worker进程都是从master进程fork过来，在master进程里面，先建立好需要listen的socket（listenfd）之后，然后再fork出多个worker进程。
所有worker进程的listenfd会在新连接到来时变得可读，为保证只有一个进程处理该连接，所有worker进程在注册listenfd读事件前抢accept_mutex，
抢到互斥锁的那个进程注册listenfd读事件，在读事件里调用accept接受该连接。当一个worker进程在accept这个连接之后，
就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。
我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。

标签：请求,worker,nginx,master,信号,进程,原理
来源： https://www.cnblogs.com/wmd-l/p/16314748.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

4.nginx原理