关于 non-blocking 数据库 Connector 大家是怎么看待的？

[OldCarMan]

rt

• 最近浏览到一些 IO 多路复用的文章时，有人指出现有高并发场景很多时候瓶颈在于 Connector （比如 JDBC ），这点个人也赞同，毕竟高并发时，对于 IO 密集型的服务，需要进行大量的磁盘 IO 请求。
• 但假如确实是这样，个人好奇为啥像 mysql 这样的数据库，为啥到现在还采用连接池的方式来实现连接管理而不是 NIO ，这点跟我上面的看法又有点矛盾，所以请问一下大家是怎么看待的？
• 最后大家觉得 non-blocking reactive connector 的必要性，另外现在有没有相对成熟的解决方案了？

[echoless]

python 是有的 https://github.com/MagicStack/asyncpg

主要是 async io 传染, 写起来更麻烦, python 语言层级支持 async, 用的人还不多.

大部分应用不需要 async 带来的好处, 当然不愿意付出代价.

[dreamlike]

我上面的评论有些跳跃了
https://juejin.cn/post/7181664513559625788
其实可以扩大一些说 client 是否有必要都是 non blocking 的 我之前写过一篇文章来表述自己的观点
我觉得 api 是没必要的 但是底层实现是有必要的 这种应该交由 runtime 全做了

[OldCarMan]

@wuhaoecho 嗯嗯，不过个人感觉未来 non-blocking 数据库客户端将会是趋势，现在麻烦主要是，语言生态没有整体发力，就如 java ，最近版本才支持 virtual Thread,市面上又缺乏一整套从控制层到数据访问层的成熟框架，所以推广起来稍微麻烦，不过随着 reactive coding 的发展，未来大概率各个环节都趋向于 reactive 的风格。
@dreamlike 谢谢补充，话说你这里提的 runtime 是指 java 运行时吗？意思是通过重返 runtime 环境，使用 mounting /unmounted （虚拟线程） 来控制程序 blocking 的方式吗？

[dreamlike]

@OldCarMan 可以理解为语言的 runtime 的一部分
我用 rust 举个例子，所谓的协程 runtime 就是指的从 io 轮询器(eventloop)，到基于这些 eventloop 做的 io api(async read) 一整套包揽，提供一组同步风格但是底层为异步的 io 操作

[OldCarMan]

@dreamlike 你意思是语言层面要支持异步 io ，对吧？