学习swoole的方式建议

看到不少人舍本逐末去学习一堆的基于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程序员技术职业生涯规划

学习其它语言优秀的地方，重视基础，舍本逐末花大量时间去学习新框架，我的以为意义不大。