学习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程序员技术职业生涯规划

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