本篇文章给大家谈谈phpnginx运行原理，以及php nginx运行原理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
Nginx：基本原理篇
Nginx的IO通常使用epoll，epoll函数使用了I/O复用模型。与I/O阻塞模型比较，I/O复用模型的优势在于可以同时等待多个（而不只是一个）套接字描述符就绪。Nginx的epoll工作流程如下：
2 . 当一个client连接到来时，所有accept的work进程都会受到通知，但只有一个进程可以accept成功，其它的则会accept失败，Nginx提供了一把共享锁accept_mutex来保证同一时刻只有一个work进程在accept连接，从而解决惊群问题
惊群现象：惊群效应就是当一个fd的事件被触发时，所有等待这个fd的线程或进程都被唤醒。一般都是socket的accept()会导致惊群，很多个进程都block在server socket的accept()，一但有客户端进来，所有进程的accept()都会返回，但是只有一个进程会读到数据，就是惊群。
Nginx 采用accept-mutex来解决惊群问题：当一个请求到达的时候，只有竞争到锁的worker进程才会惊醒处理请求，其他进程会继续等待，结合 timer_solution 配置的最大的超时时间继续尝试获取accept-mutex
I/O 复用接口有select 和 epoll 两种模型，首先介绍一下这两种模型的执行方式：
由于网络响应时间的延迟使得大量TCP连接处于非活跃状态，但调用select()还是会对 所有的socket进行一次线性扫描 ，会
调用一次epoll_wait()获得就绪文件描述符时，返回的并不是实际的描述符，而是一个代表就绪描述符数量的值，拿到这些值去epoll指定的一个数组中依次取得相应数量的文件描述符即可，这里使用内存映射（mmap）技术， 避免了复制大量文件描述符带来的开销。
在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。
epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统，把原先的select/poll调用分成了3个部分：
调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
调用epoll_ctl向epoll对象中添加这100万个连接的套接字
调用epoll_wait收集发生的事件的连接
只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。
apache 采用的select模型，nginx采用epoll模型，nginx 处理请求是异步非阻塞的，而apache则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能。在Apache+PHP（prefork）模式下，如果PHP处理慢或者前端压力很大的情况下，很容易出现Apache进程数飙升，从而拒绝服务的现象。
Nginx 常用功能
参考文章：
Nginx运行原理和配置详解（个人总结笔记）
话不多说，撸起键盘就是干！正所谓知其然知其所以然，个人总结了下Nginx运行原理和配置详解，便于理解和后续复盘。
先来看这一张图。
nginx启动后会有 一个master进程和多个worker进程 。master进程用来管理worker进程， 一个worker进程处理一个请求 ，一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。 worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致 ，这里面的原因与nginx的进程模型以及事件处理模型是分不开的 ，过多的worker数，只会导致进程来竞争cpu资源，从而带来不必要的上下文切换。
PHP WEB服务器目前最佳方式之一就是： Nginx + FastCGI（解决CGI并发重复fork问题） + PHP-FPM（管理PHP-CGI进程） 。nginx是怎么做到把请求抛给PHP解释来处理的呢？这个过程又是怎么实现的呢？稍后我们来看一下参数配置。
代理，反向代理，负载均衡是Nginx常用功能。
Http代理，反向代理：作为web服务器最常用的功能之一，尤其是反向代理。如果你和小马之前一样还是分不清代理和反向代理的区别，下面这个图对理解会有所帮助。
它们的区别就是，前者知道我要找的人并知道地址在哪，代理服务器按这个地址代为请求一下然后把他说的话返回给我。后者就是，我知道我要找谁问话但不知道地址在哪，我也不想管，代理服务你自己去找，只要帮我返回他要说的话就可以了。
负载均衡：其实也是 反向代理 的一种。负载均衡，热备等等其实都属于高可用范畴，Nginx提供的负载均衡策略有2种：内置策略和扩展策略。内置策略为 轮询，加权轮询，Ip hash 等等。扩展策略，就天马行空，只有你想不到的没有他做不到的啦，你可以参照所有的负载均衡算法，给他做下实现。思考一个问题，IP hash真的能解决session共享的问题么？
我们来简单看下两个 配置示例 。
这个配置将请求转发转向mysvr 定义的服务器列表。 注意proxy_pass配置。其实这块也是负载均衡的配置 。如下：
在访问网站时，由于配置了proxy_pass地址，所有请求都会先通过nginx反向代理服务器，在服务器将请求转发给目的主机时，读取upstream为 tomcatsever1的地址，读取分发策略，配置tomcat1权重为3，所以nginx会将大部分请求发送给49服务器上的tomcat1，也就是8080端口；较少部分给tomcat2来实现有条件的负载均衡，当然这个条件就是服务器1、2的硬件指数处理请求能力。
负载均衡配置 还有其他的相关参数，这是只是打个样，不赘述。
可以认为fastcgi_pass这个配置非常关键，将Nginx + FastCGI + PHP-FPM串连 。这个配置将PHP请求都交给 fastcgi_pass配置的PHP-FPM处理。 location分别通过正则过滤和转发配置决定了各个请求URL将要转发交与的处理方式 ，location /表示默认请求，location ~\.php(.*)$ 表示PHP 脚本请求全部转发到 FastCGI处理。 使用FastCGI默认配置.。
以上配置指定了这些 静态文件要nginx自己处理 。
NGINX负载均衡可以用于很多服务负载均衡的实现，比如做Redis服务的负载均衡，配置upstream的IP列表再配置 proxy_pass 代理即可。那要实现负载均衡除了NGINX，还有哪些呢？
根据7层OSI模型可将负载均衡分为 ：
1）二层负载均衡（一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应）；
2）三层负载均衡（一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应）；
3）四层负载均衡（在三次负载均衡的基础上，用 ip+port 接收请求，再转发到对应的机器）；
4）七层负载均衡（根据虚拟的url或是IP，主机名接收请求，再转向相应的处理服务器）。
这其中，最常见的是四层和七层负载均衡。思考一下，NGINX的负载均衡是属于哪一种？
关于负载均衡的架构
502 Bad Gateway
502badgateway要先找到nginx配置的路径。
然后找到nginx所在的error日志文件来查看具体原因。
如果是客户端浏览器配置的问题，以360浏览器为例，出现502BadGateway可能是设置了代代理导致的。
取消浏览器代理之后，刷新一下就可以访问了。
502BadGateway是一种报错提示，这一错误并不意味着上游服务器已关闭（无响应网关/代理），而是上游服务器和网关/代理不同意的协议交换数据。
鉴于互联网协议是相当清楚的，它往往意味着一个或两个机器已不正确或不完全编程。
nginx和php-fpm之间是怎样通信的
FastCGI原理
FastCGI是一个运用于Http Server和动态脚本语言间通信的接口，多数流行的Http Server都支持FastCGI，包括Apache、Nginx和lighttpd等。同时，FastCGI也被许多脚本语言支持，其中就有PHP。
FastCGI接口方式采用C/S结构，可以将HttP服务器和脚本解析服务器分开，同时在脚本解析服务器上启动一个或者多个脚本解析守护进程。当HttP服务器每次遇到动态程序时，可以将其直接交付给FastCGI进程来执行，然后将得到的结果返回给客户端。这种方式可以让HttP服务器专一地处理静态请求或者将动态脚本服务器的结果返回给客户端，这在很大程度上提高了整个应用系统的性能。
Nginx+php-fpm实现原理
Nginx本身不会对PHP进行解析，终端对PHP页面的请求将会被Nginx交给FastCGI进程监听的IP地址及端口，由php-fpm作为动态解析服务器处理，最后将处理结果再返回给nginx。其实，Nginx就是一个反向代理服务器。Nginx通过反向代理功能将动态请求转向后端php-fpm，从而实现对PHP的解析支持，这就是Nginx实现PHP动态解析的原理。
Nginx不支持对外部程序的直接调用或者解析，所有的外部程序（包括PHP）必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket（这个socket可以是文件socket，也可以是ip socket）。为了调用CGI程序，还需要一个FastCGI的wrapper（wrapper可以理解为用于启动另一个程序的程序），这个wrapper绑定在某个固定socket上，如端口或者文件socket。当Nginx将CGI请求发送给这个socket的时候，通过FastCGI接口，wrapper接收到请求，然后派生出一个新的线程，这个线程调用解释器或者外部程序处理脚本并读取返回数据；接着，wrapper再将返回的数据通过FastCGI接口，沿着固定的socket传递给Nginx；最后，Nginx将返回的数据发送给客户端。
Nginx 简单配置
location ~ \.php$ {
root /home/admin/web/nginx/html/;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/admin/web/nginx/html/$fastcgi_script_name;
include fastcgi_params;
}
phpnginx运行原理的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于php nginx运行原理、phpnginx运行原理的信息别忘了在本站进行查找喔。
