php fastcgi和php-fpm

聊到PHP开发，就一定会提到fastcgi和php-fpm。这两个东西对PHP性能的影响，可以说是决定性的。但很多人对它们的理解一直停留在“听说过名字”的阶段，对整个PHP的运行机制也模模糊糊。今天正好借这个机会，把PHP的底层交互逻辑好好捋一捋。

PHP是专门为Web开发而生的服务端语言，它的运行必须依赖Web服务器。常见的架构有LAMP和LNMP，下面这张图就直观展示了PHP被访问的完整流程。

可以看到，请求先到达Apache，然后由Apache负责解析PHP代码，最终把结果返回给客户端。在LAMP架构下，需要修改Apache的配置文件httpd.conf，通过LoadModule加载phpx_module（x是PHP版本号）。说白了，就是把PHP作为Apache的一个子模块来运行。当有PHP请求进来，Apache就调用这个模块去解析代码。

那phpx_module到底是怎么解析PHP的呢？关键就在SAPI（Server Application Programming Interface）。Apache、PHP和SAPI的关系，看下面这张图就清楚了。

SAPI就是中间层，负责提供与外部通信的接口，类似Socket，让PHP能和其他应用交换数据。PHP提供了多种SAPI实现，比如给Apache和Nginx用的php_module，给IIS用的ISAPI等。Apache调用PHP的执行过程，就是通过SAPI这个桥梁完成的。总而言之，Web服务器通过php_module模式解析执行PHP，这种模式就叫mod_php。

PHP的SAPI还有另一种实现方式——CGI模式。不过当年那个老CGI已经被FastCGI取代了。CGI全称Common Gateway Interface，工作流程是：Web服务器收到请求后，交给CGI程序（比如PHP的FastCGI），CGI处理完PHP再返回结果，服务器再返回给客户端。问题是，每次请求都要经历启动和退出，也就是著名的“fork-and-execute”模式，一旦并发量上来，服务器直接崩溃。

FastCGI的诞生正好补上了这个坑。它的原理是提前启动好进程，等待请求，处理完一个请求后不退出，继续等待下一个。基于FastCGI的运行方式叫mod_fastcgi。对比一下mod_php和mod_fastcgi的区别：前者把PHP嵌入Web服务器作为模块运行，结合度高；后者则把FastCGI作为中间层，PHP和Web服务器只通过FastCGI完成请求和响应。

在mod_php模式下，Apache每接受一个请求，就会创建一个进程去连接PHP，通过SAPI完成处理。高并发下，服务器显然扛不住。

再看mod_fastcgi模式：请求到达时，httpd调用SAPI把请求扔给PHP，处理完不退出，直接等待下一个请求。这样并发性能就大幅提升了。

磨刀不误砍柴工，前面铺垫这么多，其实就是为了引出今天的重头戏——php-fpm。

php-fpm是干什么的？简单说，它就是专门用来辅助FastCGI的。FastCGI本身是一种与平台、语言无关的接口规范，不同语言只要按规则实现，就能和Web服务器通信。上面图中提到的php-cgi，就是PHP自带的FastCGI管理器。不过网上对php-cgi的吐槽主要集中在两点：

（此处原文未列出具体两点，但核心意思明确——php-cgi存在不足，而php-fpm正是为了解决这些问题而生的专用FastCGI管理器。）

总之，php-fpm的职责就是专门管理PHP里的FastCGI进程，让PHP在高并发场景下也能稳如泰山地和Web服务器配合，完成每一次请求响应。这才是整个PHP高性能架构的基石所在。