学习swoole的方式建议

church

看到很多人舍本逐末去学习一堆的基于swoole的框架,真的是没有必要。

这些框架本质上都是swoole的api caller+composer第三方库整合商。不是说这些框架没有学习的价值,只是最核心的东西是swoole本身,而不是基于swoole的框架。弄明白了swoole为啥高效的原因,这些框架信手拈来就可以用,自己开发一个并非难事。

传统的phpfpm的工作方式,nginx+phpfpm,nginx转发给phpfpm,phpfpm一般监听9000端口,master+N个worker进程,收到nginx转发过来的request,由master调度worker进程进行处理。我们的请求一般是跟mysql、redis、elasticsearch、rabitmq等服务器进行交互,一堆的连接要建立,而且每次worker进程处理完请求都会释放这些连接资源。下个请求来时,又如此周而复始。

上面的工作流程,大家很容易看出来问题,每次请求都要建立连接,释放连接,这本身就是耗时的操作且没有必要。再者,如果请求一个web service,比如说你去调用一个查天气的接口,响应时间比较长时,整个worker进程是阻塞的,当N个worker进程都被阻塞时,下一个请求就无法响应。整个系统的响应时间就会非常长。

为了解决这两个问题,那相应的办法也就出来了,资源常驻内存+协程。server启动时,建立一堆的连接资源,处理完请求时不释放资源,下一次继续复用。在访问web service时,使用swoole提供的协程http客户端,不阻塞进程。下一个请求进来时,swoole调度器调度下一个协程占用CPU资源进行工作。所以说你用协程,客户端并不会感觉到访问速度加快了,什么意思呢?打个比方,你去银行柜台办事,传统的方式是,柜员一个一个来处理,上个人的事没办完,你就得等着。协程的方式就是,事情不由柜员来办,柜员交给其它人去办,完了让你一边呆着,柜员继续服务下一个人,当你的事情办完了时,办事人通知柜员,柜员再叫你过来给你反馈结果。很明显第二种方式,对办事人而言,服务效率看起来更高一点,但实际上你等的时间是一样的。

协程解决的IO密集型的问题,不是CPU密集型的问题。而互联网应用95%以上的场景都是IO密集型。

所以swoole如此高效的原因,就是因为它基本上等于nginx+go,用epoll技术hold住大量并发,连接资源常驻内存,再加上使用协程避免调用web service导致进程阻塞。这里我只提web service,是因为redis、mysql服务器和应用服务器通常是同一个局域网,传统方式其实也非常高效,不能突出协程的优势。而当你调用外网的web service时,一般响应时间会非常长,协程的优势才得以体现。

当然,这只是个人看法,并不能代表所有人,希望能带来一些启发。

韩大多年前写的《PHP并发IO编程之路》

关于PHP程序员技术职业生涯规划

学习其它语言优秀的地方,重视基础,舍本逐末花大量时间去学习新框架,个人觉得意义不大。

阅读 2k

shuizhuniurou
shuizhuniurou
3.6k 声望
63 粉丝
0 条评论
3.6k 声望
63 粉丝
文章目录
宣传栏