Swoole 5.0 版本请求意见稿

[twose]

Swoole 5.0 版本请求意见稿

项目方向

Swoole项目从创建至今已经有超过6年的历史了, 但Swoole协程却是一个全新的事物, 随着4.0版本Swoole的有栈协程问世, Swoole的协程化才真正步入了稳定发展阶段.

Swoole从4.0开始一直致力于提升底层代码的稳定性, 不断地做代码精简与优化, 但异步时代的Swoole遗留下来的历史包袱积重难返, 制约了Swoole的进一步发展, 因此我们Swoole开发组决定面对这些历史问题, 做出一个大胆的决定, 从内核中剔除掉一些会导致协程生态混乱的模块, 只保留纯协程的编码模式, 直接提供PHP协程的最佳实践方案, 开发者无需再去纠结于各种复杂繁琐的配置, 甚至在同步, 异步和协程之中迷茫. Swoole后续的生态将完全建立在协程之上, 并且我们会基于5.0版本重新书写文档, 提供Swoole的最佳实践指南, 最大程度减小Swoole开发者的学习成本.

如果你的应用已经完全基于协程实现(如你正在使用Swoft/EasySwoole3等纯协程框架/组件), 那么5.0的改动不会对你造成多少影响.

我将会在下方列出所有涉及删除或改动的内容, 以重要程度优先级排序, 如果你赞同某部分提案, 请点👍 以表明支持

[fdreamsu]

1. 希望能够监听协程的创建和销毁，以便管理上下文
2. 协程MySQL和协程Redis是否也可以砍掉，直接上PDO和phpredis，减少不必要的维护工作，因为有很多新特性，可能不能及时去支持，虽然一键协程化后的性能要比Swoole实现的差一些
3. xdebug调试不兼容，如果用gdb那根本不现实，也不利于推广swoole
4. 如果禁止协程中跑阻塞代码，那如果有某个sdk不支持协程，一键协程化也不能支持，那想要在项目里将就用都做不到，那肯定很难受

@Yurunsoft

• “协程销毁“的监听，可以用钩子实现。
• 协程MySQL和协程Redis可以直接开启defer特性，这个是传统client不能比拟的。

[TonyChen-SH]

@TonyChen-SH

不支持xdebug，代码怎么读。好像关于调试的便捷性问题，各位大佬好像都不怎么关注。

Xdebug设计上大量依赖了全局变量导致无法支持协程, swoole现在有协程迭代器, 协程调用栈跟踪, 协程gdb调试工具, 基本能满足一般的调试或者断点, 可能你只是固守了xdebug的方式, 没有了解. https://wiki.swoole.com/wiki/page/968.html https://wiki.swoole.com/wiki/page/967.html https://wiki.swoole.com/wiki/page/1011.html

能支持PHPSTORM断点调试么？

[cariers]

@twose 是不是对现有的API及对象进行抽像，目前的Server感觉是一个巨无霸。

[twose]

@twose 是不是对现有的API及对象进行抽像，目前的Server感觉是一个巨无霸。

@ewenlaz 目前的Server配置的确过于复杂, 未来会有全新的协程Co\Server, 不再是异步回调模式

[twose]

支持 CURL 协程

这个关键性就不说了，很多工具库都直接用了 curl，改是很难，如果底层直接支持协程，效果非同凡响。

已在计划中

[ganl]

有Windows的支持计划吗？

[twose]

有Windows的支持计划吗？

有Windows下的开发环境支持: https://www.swoole.com/page/download

[pengbotao]

现在想迁移到swoole碰到的两个痛点，一个是全局变量/类静态变量，一个是大量的CURL请求。第一个看起来只能调整，第二个curl的支持有计划发布时间吗？

[windrunner414]

@pengbotao 是第三方库用的curl？不然可以考虑把curl替换一下

[pengbotao]

@pengbotao 是第三方库用的curl？不然可以考虑把curl替换一下

第三方的库有使用，也有很多自己调用。这个跟业务有关系，业务决定需要大量调用不同类型的第三方接口，当第三方接口超时时简直是灾难，但系统用其他语言重构成本更高，相比swoole协程方案改动还算少的了。看前面说支持已经有几个月了，不支持什么时间可以支持。

[yankeys]

弱弱地问一下 啥时候出 从入门到精通的教程 如果能像thinkphp的文档一样牛皮 推进速度会快100倍

tp不是因为文档牛皮，而是因为tp简单

[hpp321]

弱弱地问一下 啥时候出 从入门到精通的教程 如果能像thinkphp的文档一样牛皮 推进速度会快100倍

tp不是因为文档牛皮，而是因为tp简单

如果不能出入门到精通，出个入门到放弃也可以啊

[fdreamsu]

弱弱地问一下 啥时候出 从入门到精通的教程 如果能像thinkphp的文档一样牛皮 推进速度会快100倍

tp不是因为文档牛皮，而是因为tp简单

如果不能出入门到精通，出个入门到放弃也可以啊

这个应该是swoft/es等框架的工作，swoole是一种扩展。
就相当于thinkphp会有很直观的教程，但是php本身需要很长时间精通。

[pricemok]

请问5.0现在什么情况了？

[qq475281441]

去掉 SWOOLE_PROCESS 模式，是否就是现在使用 addProcess 不能使用了，创建 Process 需要在 server start 之前手动 start?　那这个自定义 process 怎么和 server 进行通信？刚才试了一下 4.x 的 BASE 模式下，好像 $server->sendMessage 也不能使用了。

可以使用swoole_event_add给process添加eventLoop

[munggruel]

感觉调试还是太难，如果有断点调试 我就用了

[niwsmbulai1989]

目前学习成本还是太大了，官方的demo太少，以及文档看起来不是很方便，文档建议参考 看云，看起来很舒服，找起来也很方便！

[bnubobby]

链接池优化 目前的链接池，每个进程各自独立 是否可增加一个进程间链接池？ 主要目的是减少数据库和redis的链接数量

是否可以共用 1 个 redis 或 mysql 连接 ？
绝对不可以。必须每个进程单独创建 Redis、MySQL、PDO 连接，其他的存储客户端同样也是如此。原因是如果共用 1 个连接，那么返回的结果无法保证被哪个进程处理，持有连接的进程理论上都可以对这个连接进行读写，这样数据就发生错乱了。

如果有进程间链接池，那应用可以自行取出链接对象，处理完毕后再压入队列 类似现在的的swoole\table ，增加一个 swoole\queue

[twose]

链接池优化 目前的链接池，每个进程各自独立 是否可增加一个进程间链接池？ 主要目的是减少数据库和redis的链接数量

是否可以共用 1 个 redis 或 mysql 连接 ？
绝对不可以。必须每个进程单独创建 Redis、MySQL、PDO 连接，其他的存储客户端同样也是如此。原因是如果共用 1 个连接，那么返回的结果无法保证被哪个进程处理，持有连接的进程理论上都可以对这个连接进行读写，这样数据就发生错乱了。

如果有进程间链接池，那应用可以自行取出链接对象，处理完毕后再压入队列 类似现在的的swoole\table ，增加一个 swoole\queue

你说的这个就是proxy, 各个数据库生态都有类似的东西

https://github.com/louislivi/SMProxy https://github.com/twitter/twemproxy

[bnubobby]

链接池优化 目前的链接池，每个进程各自独立 是否可增加一个进程间链接池？ 主要目的是减少数据库和redis的链接数量

是否可以共用 1 个 redis 或 mysql 连接 ？
绝对不可以。必须每个进程单独创建 Redis、MySQL、PDO 连接，其他的存储客户端同样也是如此。原因是如果共用 1 个连接，那么返回的结果无法保证被哪个进程处理，持有连接的进程理论上都可以对这个连接进行读写，这样数据就发生错乱了。

如果有进程间链接池，那应用可以自行取出链接对象，处理完毕后再压入队列 类似现在的的swoole\table ，增加一个 swoole\queue

你说的这个就是proxy, 各个数据库生态都有类似的东西

https://github.com/louislivi/SMProxy https://github.com/twitter/twemproxy

还是有点不同的， 理论上，我只需要全局保存socket就可以了，不需要第三方做那么工作，比如解析协议，路由，注解 那一大套，特别协议解析，用官方的就挺好。

[limingxinleo]

你说的这个单进程模型是ok的，在多进程模型的情况下，应该做不到吧。

不过，这里我水平有限，不是很懂

[twose]

@bnubobby 不可能的, MySQL/Redis都是请求响应的流式协议, 一个连接只能同时处理一个请求, 多少并发就得有多少连接, 这是不可改变的, 除非你重新造一套支持并发的协议并且自己写一套客户端

跨进程连接池解决的问题只能是把远程连接减少, 转化为更高效的本地连接

没有万能的技术

[bnubobby]

@bnubobby 不可能的, MySQL/Redis都是请求响应的流式协议, 一个连接只能同时处理一个请求, 多少并发就得有多少连接, 这是不可改变的, 除非你重新造一套支持并发的协议并且自己写一套客户端

跨进程连接池解决的问题只能是把远程连接减少, 转化为更高效的本地连接

没有万能的技术

你说的没错，MySQL/Redis都是请求响应的流式协议，在多进程间使用同一个socket链接，带来的后果是数据错乱， 而不是完全没法使用， 我的意思是，是否能解决数据错乱这个问题，比如说通过多进程共享的队列，应用在request的时候中取出socket链接，使用完后再压进队列 SMProxy 做的事情太多了，我对它协议解析和长期维护方面，是抱有有怀疑态度的

[flyinghail]

多进程开发,数据同步问题, 比golang还考虑的多; 很多需要借助第三方工具,希望5.0能有好的解决方案;

同意，多进程用于 web 很简便。 但是如果想扩大到更广泛的服务（例如 ws），涉及到跨进程，就需要做进程间通信，额外引入了复杂度。这方面 golang 反而更简单。 同样这也造成连接池的问题，因为要给每个进程开一个池。