swoole 协程现状一览: 学不动? 实在是更大略了
利用 swoole 协程很大略: 开个协程, 协程里写非壅塞代码
展望 swoole 协程未来 swoole 协程现状一览 swoole 一贯保持着 颇为快速 的迭代速率, 快到什么程度呢 -- 「快别更新了, 学不动了」 半年前还是 v4.0 支持完全的协程编程(CSP, go+chan), 现在已经迭代到 v4.3.3
v4.3 版本做了一次大更新, 项目拆分成了 swoole 和 swoole_async
官方 wiki 修正了很多, 协程的部分的文档增加了不少, 而且提前到更加显眼的地方 来一句灵魂叩问: 改动这么大, 那是不是真的 「学不动了」? 并不是! swoole 是一贯在为 天下上最好的措辞 添砖加瓦: 更为完全的协程编程支持, 直不雅观的效果是更加 无缝无感 的编程切换体验(后面细说), 意味着须要理解 和把稳的语法细节更少, 编程更轻松 v4.3 版本做的一次大更新, 实际是优化 swoole 项目的架构, 主项目 focus 协程模式的网络编程, 更多网络编程干系的功能, 利用 扩展(ext) 的办法供应(详细可以参考 swoole 的 github 主页: https://github.com/swoole, 扫一眼下面有的项目, 就能有所启示) 官方 wiki 一贯以信息量著称(同时也意味着 可以学到很多东西), 但是如果具备了 网络编程 + 协程 的根本知识, 然后 focus 到 swoole 协程部分文档 上, 就会创造实在都是一些 编程语法, so easy~ 利用 swole 协程 如何利用协程: 利用 go()(\Swoole\Coroutine::create() 的简写) 创建一个协程 在 go() 的回调函数中, 加入协程须要实行的代码, 把稳是 非壅塞代码
如图所示
swoole 中协程便是这么大略: 开个协程, 协程里写非壅塞代码. 官方协程部分文档看起来很多, 牢记这两点, 实在很大略! 开协程 上文提到的, 利用 go() 创建一个协程 swoole server 中, 底层自动在 onRequet, onReceive, onConnect 等事宜回调之前自动创建一 个协程 开启 enable_coroutine 参数后的影响范围: 紧张还包括 Timer 定时器 利用 task_enable_coroutine 开启的协程版 Task 进程, 会在 onTask 回调之前自动创建一个协程
进程和进程池支持开启协程, 开启后创建的子进程会自动创建协程
如图所示
非壅塞代码 协程中必须编写 非壅塞代码, 看到上面 Co::sleep(1) 的小伙伴会有疑问了: 连个 sleep 都要 swoole 供应一个协程版, 我得节制多少 swoole 协程版 API 才够呀? 以是问题的关键点来了: 协程中一定要利用 非壅塞代码(一定要牢记, 多次重复了, 可以心里再默念三遍) 怎么区分哪些是壅塞的, 哪些是非壅塞的: 可以参考 官方wiki - runtime 随着 swoole 的迭代, 对协程的支持越来越完全, 区分哪些壅塞, 哪些非壅塞, 越来越无感 swoole 更新后, 添加了开启协程 runtime 功能:
如图所示
协程 runtime 开启后, 支持的列表: redis扩展 利用mysqlnd模式的pdo、mysqli扩展，如果未启用mysqlnd将不支持协程化 soap扩展 file_get_contents、fopen stream_socket_client (predis) stream_socket_server stream_select(须要4.3.2以上版本) fsockopen 文件操作 底层利用 AIO 线程池仿照实现fopen / fclose
fread / fwrite
fgets / fputs
file_get_contents / file_put_contents
unlink / mkdir / rmdir sleep系列函数
sleep / usleep
time_nanosleep / time_sleep_until 不支持的列表:
mysql：底层利用libmysqlclient
curl：底层利用libcurl （即不能利用CURL驱动的Guzzle）
mongo：底层利用mongo-c-client
pdo_pgsql / pdo_ori / pdo_odbc / pdo_firebird 协程 runtime 还不支持怎么办 须要的功能协程 runtime 下还没支持怎么办? 你有三种方法: 协程 runtime 之前, 官方和社区已经贡献了很多协程版 API 可供给用, 比如上面 Co::sleep(1), PostgreSQL Client Swoole\Coroutine\PostgreSQL
官方和社区没有, 可以利用 swoole 供应的协程版 client 进行封装, 可以参考 官方 amqp client 封装, 将 socket() 函数实现的 tcp client, 利用 swoole 协程版 tcp client 实现即可
如图所示
PS: 这里只是抛砖引玉, 原库中利用 stream_socket_client(), 现在 swoole 协程 runtime 已经支持了
传统的壅塞办理方案(当然是在现有的协程办法都弗成, 才会连续利用传统的办法): 抛给 swoole 的 task 进程, 利用 MQ 异步掉, 等等 展望 swoole 协程的未来 到目前为止, 希望小伙伴们已经 get 到了 swoole 中协程编程的要点(我喜好用 姿势, 人最紧要的是姿势好看~), 让我们展望一下未来: 解锁更多协程利用: chan, defer, select, waitgroup, 这些官方都供应了 demo( 韩天峰 - PHP 协程：Go + Chan + Defer), 看完后自己也能封装一份
并不是 完全(100%, one hundred percent) 的支持, 假如一欠妥心踩到不支持的怎么办? swoole 的后续版本将支持检测协程环境下是否有壅塞调用
随着 swoole 官方在协程编程上的持续发力, 基于 swoole 实现的全协程式 PHP 开拓框架也将更为大略, 从根本/底层的网络编程到全体微做事架构的道路也将更为平坦, 比如立时将要迎来大版本升级的 swoft2 写在末了 官方协程部分的文档看起来多, 实在多是对协程 API 的先容, 并没有在知识构造理解的繁芜度上有所增加. swoole 中协程的编程语法, 都在 \Swoole\Coroutine 命名空间下可以找到.
末了回到一个经典问题, 学习 swoole 的协程好, 还是学习 go 的协程好? 我谈谈我个人的不雅观点:
所须要的根本知识: 网络编程 + 协程, 不会由于你是用 swoole 还是 go 而有所减少, 根本不大好, 表现出来了便是学着学着就随意马虎卡住, 效率上不来
以为你写的是 swoole, 不不不, 写的是一个又一个功能的 API, go 也同样(要用到 redis/mysql/mq, 相应的 API 你还是得学得会), 差异在于, swoole 趋势是在底层实现支持(比如 协程runtime), 这样 PHPer 可以无缝切换过来, 而 Gopher 则须要学习一个又一个基于 go 协程封装好的 API. 当初在 PHP 中学习的这些 API, 到 go 里面, 一样须要再熟习一遍
末了来谈谈性能, 请许可我用一个傲娇一点的说, 你用 swoole 达不到的性能, 换个措辞, 呵呵呵.难易程度排行: 加机器 < 加程序员 < 加措辞. 在这里希望大家在学习过程中有一个好的思路。学习互换QQswoole群：486583931（严禁闲聊）
