swoole之代码热更新实现 转自https://blog.csdn.net/nep_tune/article/details/81329918

随着swoole的版本迭代更新,已经足够稳定了,在阿里,腾讯,yy等各大公司都有着使用,也有不少游戏圈里的朋友也在使用,这些朋友常常会提到一个问题,每次代码更新还须要中止服务,而后从新启动,来达到更新代码,然而这种作法,是比较粗暴的。其实swoole里提供reload的特性,彻底支持代码的热更新。

在介绍swoole的reload以前,先简要的讲讲web方式是如何改了文件就当即生效的:

  几个概念: 
  1) sapi:能够简单的理解为php引擎对外的一个统一接口,使得php能够和外部程序进行交互
  2) php的生命周期中关键四个调用:MINT -> RINT -> RSHUTDOWN -> MSHUTDOWN

  3)  fpm : fastcgi进程管理器

  那么fpm方式的流程就是: fpm经过sapi接口与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()的时候:php

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

 从这个流程中咱们会发现,onWorkerStart 和 onWorkerStop很是像 sapi里的 RINT, RSHUTDOWN.

  因此到了这里,实现代码热更新的的方案就是:

  把业务逻辑的脚本文件的载入放到onWorkerStart方法里,若是用了opcache,那么把一些opcache的清理逻辑放到onWorkerStop方法里。

示例:web

 function onWorkerStart($serv,$worker_id) {api

     include"hot_update_class.php";swoole

     $class=newHotUpdate();  架构

 }框架

 

 function onWorkerStop($serv, $worker_id) {curl

      opcache_reset(); //zend_opcache的opcache清理函数异步

 }函数


这时若是咱们修改了hot_update_class.php里的相关文件,再执行$serv->reload(),就能够实现热更新了。

ps: 因此,咱们能够把onWorkerStart当成个人业务逻辑的入口。


   若是你使用了autoloader, 那么你把autoloader的注册放到onWorkerStart里来。
   若是你使用了框架,那么你能够把框架的入口文件放到onWorkerStart里来。工具



若是你开启了opcache,那么,你能够在onWorkerStop的时候,执行相关的opcache清理工做。
(zend_opcache,直接调用opcache_reset()方法便可)

示例:

 function onWorkerStop($serv,$worker_id) {

     opcache_reset(); //zend_opcache的      

     //apc, xcache, eacc等其余方式,请调用相关函数  

 }

 

最后但愿这篇博客能给你带来一些帮助。(注:若是你的worker里挂了异步事件,好比把某个curl挂到swoole_event_add里,那么worker的reload会把这些都清理掉,可能致使一些逻辑错误,解决方案正在酝酿中)

swoole官方交流群:321637118

相关文章
相关标签/搜索