最近突然听起了校园歌曲

想到了自己的高中、大学生活好像也没留下太多深刻的回忆,不像很多电视或者别人描述的那么多姿多彩

不过听起了这些校园歌曲,还是特别的有感觉

最后吐槽下QQ音乐的歌单,一般都只有10几首

不像网易云音乐,一个歌单可以有上百首歌曲

但网易云音乐里的很多音乐都没有版权,播放不了

从07年开始正式进入互联网行业,真是见证了一拔又一拔的互联网浪潮,也无一例外的没抓住任何一次,之前一直归为运气不佳,实则是能力太差。

刚入互联网的时候,马上就是社交网络的兴起,见证了校内到人人、见证了QQ空间,尤其是Facebook的开放平台概念出来后,一头扎进了开放平台应用的开发中,一开始是一些小的工具内的应用,到后面被证明还是游戏传播性、收益最大,于是乎,偷菜一夜席卷整个互联网,作者也投身这个方向,做过几个大几百万DAU的游戏,但最终还是没能抓住逆袭翻身的机会,遗憾错过了这一拔,但也见证了身边很多的屌丝盆友,屌丝团队逆袭,比如:智明星通、胡莱、恺英、博雅等等

而后接下来是一拔O2O的浪潮,从千团大战到洗车、美甲、吃饭、出行等等,一时是满大街的扫码,这一拔最终成就了美团,滴滴等目前的巨头,其他的都基本烟消云散,当时有机会加入美团前身的饭否团队,又是遗憾的错过了这一个大机会。

接下来是轰轰烈烈的互联网金融浪潮了,但如今已经是一地鸡毛,当时入场了很短的一段时间,选择的赛道是校园分期,这个赛道反而跑出来了两家:趣店和分期乐,话说当时趣店和分期乐当时竞争还是很激烈了,当时我们创业的一开始也做的不错,后面有人撮合我们和趣店合并,如果合并成功,月GMV就会超过分期乐而成为第一,但当时的CEO没同意合并的方案,最后的故事就是我们融资不利,迅速败下阵来,而趣店后面绑上阿里而一飞冲天,很快就上市了,又是一次遗憾的错失,这也是离成功最近的一次了。

现在已经进入移动互联网时间,随着年龄越来越大,顾及越来越多,选择和折腾的成本太高了,只能选择大厂稳定了,所以见证了微信生态、短视频生态的此起彼伏,只能是望洋生叹了。

不过好在技术一直没有放下,内心还是一个技术爱好者,期望能蛰伏一段时间,沉淀一下,提升更多的非技术的认识,期待还有机会抓住一拔浪潮。

本人参与的swoole项目有幸被很多朋友使用,我也大力向周边的一些朋友推荐,随着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()的时候:

第一步: 向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方法里。

示例:

function onWorkerStart($serv,$worker_id) {

 include"hot_update_class.php";

 $class=newHotUpdate();  

}

function onWorkerStop($serv, $worker_id) {

  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会把这些都清理掉,可能导致一些逻辑错误,解决方案正在酝酿中)