cleey
望着那一丝海线,若隐若现。落日下的海霞,数不尽的美,看不完的醉
PHP扩展Swoole的代码重载机制

大家都知道Swoole的性能在PHP界还算不错,同样都是PHP为什么呢,我专门研究了下。

几个概念: 
  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()的时候:

  第一步: 向manager进程发送USR1信号,
  第二步: manager捕获到USR1信号,会向worker进程发送 TERM信号。
  第三步:worker进程捕获这个TERM信号,做把一个running的标识设置0
  第四步:woker的事件循环发现running标识为0,处理完当前逻辑就会自杀(自杀前会回调onWorkerStop函数),
  第五步:manager再拉起一个新的worker (拉起后会回调onWorkerStart函数)

 从这个流程中我们会发现,onWorkerStart 和 onWorkerStop非常像 sapi里的 RINT, RSHUTDOWN.


这个问题参考了swoole热更新的机制,guangla.com/post/swoole-reload,有兴趣的同学可以看看。

<< 上一篇 C、PHP中 define ,const ,static区别 MQTT协议的定义和特点 下一篇 >>
文章标签
随意 | Created At 2014 By William Clinton | 蜀ICP备14002619号-4 |