标签：过程 bsp cache 工具 没有 load() cli man 一个
几个概念：
1） sapi：可以简单的理解为php引擎对外的一个统一接口，使得php可以和外部程序进行交互
2） php的生命周期中关键四个调用：MINT -> RINT -> RSHUTDOWN -> MSHUTDOWN
3) fpm : fastcgi进程管理器
那么fpm方式的流程就是： fpm通过sapi接口与php进程交互，也是普通PHP执行过程。
在fpm启动的时候，
第一步： 会调用各扩展的MINT方法，进行一些数据初始化（长驻内存），
第二步： 每个请求过来，先会执行RINT对单个请求行一个初始化，
第三步： 执行php脚本，
第四步： 执行RSHUTDOWN方法，
第五步： 如果你要停止fpm了，才会执行MSHUTDOWN。
fpm对每个请求的处理都是一直在在重复执行 2~4步 。
在第三步中， php的脚本是动态执行的，由于每次都要执行一次php脚本，而每次php脚本都要有一个把php文件翻译成opcode的流程（比较耗时）, 于是就产生的opcache工具。
opcache: 直接把php翻译后的opcode代码树保存到共享内存中，以便直接使用，从而减少每次都把php翻译成opcode的开销。
opcache的问题：按照他的描述，修改了php文件，并不能立即被更新，
opcache的解决方案：有一个配置来设置隔多长时间检测文件是否更新了，从而有机会在第二步重新来reload相关的文件.
当然，你也可以直接reload fpm，从而达到php热更新的效果(opcache扩展可以在第四步把相关的opcode cache给清空)。
swoole的问题：
swoole是以cli运行的，然后长驻内存的。整个生命周期只有在启动的时间可以一次执行RINT过程， 之后所有的请求都在第三步以内完成。（这也是swoole更快的原因之一），这样的话，相关的php脚本如果被执行了一次，就永久性的长驻内存了，更新代码就没有效果了。
swoole的解决方案：内置方法 $serv->reload()
前提：swoole是一个三层架构： master->manager->worker， master和manager是启动之后，就长驻内存的，所以这里reload的是worker进程，（而我们的业务逻辑正好都在worker进程）。
简单原理： 调用$server->reload()的时候：
要想加载代码则使用include_once 来加载代码 否则reload无效
// 每个 Worker 进程启动或重启时都会执行
$server->on(‘WorkerStart‘, function (\Swoole\Http\Server $server, int $workerId) {
// 通过重新加载外部文件来重载代码和释放之前占用的内存
include_once __DIR__ . DIRECTORY_SEPARATOR .‘workerstart.php‘;
// 下面这些直接写在当前文件中的代码即便重载也不会变化
echo ‘WorkerStart:‘ . PHP_EOL . PHP_EOL;
echo ‘ Worker ID: ‘ . $workerId . PHP_EOL . PHP_EOL;
// 启动服务器后, 去掉下面这行注释, 然后 reload , 该语句也不会执行的
echo ‘ reloaded ! ‘ . PHP_EOL . PHP_EOL;
// 应该把这里的回调事件代码写在另一个文件中来 include 而不是直接写在这里
// 注意即便是 include_once , reload 也会重新加载的, 但在你的逻辑控制中是有效的
});
第一步： 向manager进程发送USR1信号，
第二步： manager捕获到USR1信号，会向worker进程发送 TERM信号。
第三步：worker进程捕获这个TERM信号，做把一个running的标识设置0
第四步：woker的事件循环发现running标识为0，处理完当前逻辑就会自杀（自杀前会回调onWorkerStop函数），
第五步：manager再拉起一个新的worker (拉起后会回调onWorkerStart函数）
从这个流程中我们会发现，onWorkerStart 和 onWorkerStop非常像 sapi里的 RINT, RSHUTDOWN.
标签：过程 bsp cache 工具 没有 load() cli man 一个
原文地址：https://www.cnblogs.com/guokefa/p/13124503.html
