swoole 协程初体验

2018年6月14日 216点热度 0人点赞 0条评论

内容概览:

  • 协程的执行顺序: 初窥 swoole 中协程的调度

  • 协程为什么快: 减少IO阻塞带来的性能损耗

  • swoole 协程和 go 协程对比: 单进程 vs 多线程


协程的执行顺序

先来看看基础的例子:

图片

go()\Swoole\Coroutine::create() 的缩写, 用来创建一个协程, 接受 callback 作为参数, callback 中的代码, 会在这个新建的协程中执行


(备注: \Swoole\Coroutine 可以简写为 \Co)


上面的代码执行结果:


图片


执行结果和我们平时写代码的顺序, 好像没啥区别. 实际执行过程:


  • 运行此段代码, 系统启动一个新进程

  • 遇到 go(), 当前进程中生成一个协程, 协程中输出 hello go1, 协程退出

  • 进程继续向下执行代码, 输出 hello main

  • 再生成一个协程, 协程中输出 hello go2, 协程退出


运行此段代码, 系统启动一个新进程. 如果不理解这句话, 你可以使用如下代码:

图片

执行并使用 ps aux 查看系统中的进程:

图片

我们来稍微改一改, 体验协程的调度:

图片

\Swoole\Coroutine::sleep() 函数功能和 sleep() 差不多, 但是它模拟的是 IO等待(IO后面会细讲). 执行的结果如下:

图片

怎么不是顺序执行的呢? 实际执行过程:

  • 运行此段代码, 系统启动一个新进程

  • 遇到 go(), 当前进程中生成一个协程

  • 协程中遇到 IO阻塞 (这里是 co::sleep() 模拟出的 IO等待), 协程让出控制, 进入协程调度队列

  • 进程继续向下执行, 输出 hello main

  • 执行下一个协程, 输出 hello go2

  • 之前的协程准备就绪, 继续执行, 输出 hello go1

到这里, 已经可以看到 swoole 中 协程与进程的关系, 以及 协程的调度, 我们再改一改刚才的程序:

图片

我想你已经知道输出是什么样子了:

图片

协程快在哪? 减少IO阻塞导致的性能损失


大家可能听到使用协程的最多的理由, 可能就是 协程快. 那看起来和平时写得差不多的代码, 为什么就要快一些呢? 一个常见的理由是, 可以创建很多个协程来执行任务, 所以快. 这种说法是对的, 不过还停留在表面

首先, 一般的计算机任务分为 2 种:

  • CPU密集型, 比如加减乘除等科学计算

  • IO 密集型, 比如网络请求, 文件读写等

其次, 高性能相关的 2 个概念:

  • 并行: 同一个时刻, 同一个 CPU 只能执行同一个任务, 要同时执行多个任务, 就需要有多个 CPU 才行

  • 并发: 由于 CPU 切换任务非常快, 快到人类可以感知的极限, 就会有很多任务 同时执行 的错觉

了解了这些, 我们再来看协程, 协程适合的是 IO 密集型 应用, 因为协程在 IO阻塞 时会自动调度, 减少IO阻塞导致的时间损失.

我们可以对比下面三段代码:

  • 普通版: 执行 4 个任务

图片

  • 单个协程版:

图片

  • 多协程版: 见证奇迹的时刻

图片

为什么时间有这么大的差异呢:

  • 普通写法, 会遇到 IO阻塞 导致的性能损失

  • 单协程: 尽管 IO阻塞 引发了协程调度, 但当前只有一个协程, 调度之后还是执行当前协程

  • 多协程: 真正发挥出了协程的优势, 遇到 IO阻塞 时发生调度, IO就绪时恢复运行

我们将多协程版稍微修改一下:

  • 多协程版2: CPU密集型

图片

只是将 co::sleep() 改成了 sleep(), 时间又和普通版差不多了. 因为:

  • sleep() 可以看做是 CPU密集型任务, 不会引起协程的调度

  • co::sleep() 模拟的是 IO密集型任务, 会引发协程的调度

这也是为什么, 协程适合 IO密集型 的应用.


再来一组对比的例子: 使用 redis

图片

性能对比:

图片

swoole 协程和 go 协程对比: 单进程 vs 多线程


接触过 go 协程的 coder, 初始接触 swoole 的协程会有点 , 比如对比下面的代码:

图片

刚写 go 协程的 coder, 在写这个代码的时候会被告知不要忘了 time.Sleep(time.Second), 否则看不到输出 hello go, 其次, hello gohello main 的顺序也和 swoole 中的协程不一样.

原因就在于 swoole 和 go 中, 实现协程调度的模型不同.

上面 go 代码的执行过程:

  • 运行 go 代码, 系统启动一个新进程

  • 查找 package main, 然后执行其中的 func mian()

  • 遇到协程, 交给协程调度器执行

  • 继续向下执行, 输出 hello main

  • 如果不添加 time.Sleep(time.Second), main 函数执行完, 程序结束, 进程退出, 导致调度中的协程也终止

go 中的协程, 使用的 MPG 模型:

  • M 指的是 Machine, 一个M直接关联了一个内核线程

  • P 指的是 processor, 代表了M所需的上下文环境, 也是处理用户级代码逻辑的处理器

  • G 指的是 Goroutine, 其实本质上也是一种轻量级的线程

图片

MPG 模型

而 swoole 中的协程调度使用 单进程模型, 所有协程都是在当前进程中进行调度, 单进程的好处也很明显 -- 简单 / 不用加锁 / 性能也高.

无论是 go 的 MPG模型, 还是 swoole 的 单进程模型, 都是对 CSP理论 的实现.

CSP通信方式, 在1985年时的论文就已经有了, 做理论研究的人, 如果没有能提前几年, 十几年甚至几十年的大胆假设, 可能很难提高了.


写在最后

今天从 go() 出发, 得以一瞥协程世界, 协程的世界里还有很多很有意思的东西, 需要我们去发现. 比如:

  • 我们普通版的代码是当前进程里执行的, 只是单个进程, 可我们现在可能有了很多协程, 会不会有什么奇遇呢?

还有一个细节: swoole 中有 co::sleep()sleep() 2个方法的, 而 go 中只有 time.Sleep() 一个方法?

这是 swoole 协程需要经历的一个阶段(毕竟 go 快 10 年了), 还不够 智能的判断 IO阻塞, 所以上面也使用了相应的协程版 redis co\Redis() -- 你得使用配套协程版, 才能达到协程调度的效果.

--------------伟大的分割线----------------


PHP饭米粒(phpfamily) 由一群靠谱的人建立,愿为PHPer带来一些值得细细品味的精神食粮!

饭米粒只发原创或授权发表的文章,不转载网上的文章

所发的文章,均可找到原作者进行沟通。

也希望各位多多打赏(算作稿费给文章作者),更希望大家多多投搞。

投稿请联系:

[email protected]


本文由 daydaygo授权 饭米粒 发布,转载请注明本来源信息和以下的二维码(长按可识别二维码关注)

图片

37130swoole 协程初体验

这个人很懒,什么都没留下

文章评论