专栏首页大宽宽的碎碎念为什么DB连接管理一般不采用IO多路复用?

为什么DB连接管理一般不采用IO多路复用?

这是一个非常好的问题。IO多路复用被视为是非常好的性能助力器。但是一般我们在使用DB时,还是经常性采用c3p0,tomcat connection pool等技术来与DB连接,哪怕整个程序已经变成以Netty为核心。这到底是为什么?

首先纠正一个常见的误解。IO多路复用听上去好像是多个数据可以共享一个IO(socket连接),实际上并非如此。IO多路复用不是指多个服务共享一个连接,而仅仅是指多个连接的管理可以在同一进程。在网络服务中,IO多路复用起的作用是一次性把多个连接的事件通知业务代码处理。至于这些事件的处理方式,到底是业务代码循环着处理、丢到队列里,还是交给线程池处理,由业务代码决定。

对于使用DB的程序来讲,不管使用多路复用,还是连接池,都要维护一组网络连接,支持并发的查询。

为什么并发查询一定要使用多个连接才能完成呢?因为DB一般是使用连接作为Session管理的基本单元。在一个连接中,SQL语句的执行必须是串行、同步的。这是由于对于每一个Session,DB都要维护一组状态来支持查询,比如事务隔离级别,当前Session的变量等。只有单Session内串行执行,才能维护查询的正确性(试想一下一组sql在不断的增减变量,然后这组sql乱序执行会发生什么)。维护这些状态需要耗费内存,同时也会消耗CPU和磁盘IO。这样,限制对DB的连接数,就是在限制对DB资源的消耗。

因此,对DB来说,关键是要限制连接的数目。这个要求无论是DB连接池还是NIO的连接管理都能做到。

这样问题就绕回来了,为什么DB连接不能放到IO多路复用里一并执行吗?为啥大家都用连接池?

答案是,可以用IO多路复用——但是使用JDBC不行。JDBC是一个出现了近20年的标准,它的设计核心是BIO(因为199X年时还没有别的IO可以用):调用者在通过JDBC时执行比如query这样的API,在没有执行完成之前,整个调用线程被卡住。而类似于Mysql Connector/J这样的driver完备的实现了这套语义。

当然如果DB Client的协议的连接处理和解析稍微改一下:

  1. 将IO模式调整为Non-Blocking,这样就可以挂到IO多路复用的内核上(select、epoll、kqueue……)
  2. 在Non-Blocking实现的基础之上实现数据库协议的编码和解析

就可以实现用IO多路复用来访问DB。实际上很多其他语言/框架里都是这么干的。比如Nodejs,see https://github.com/sidorares/node-mysql2;或者Vert.X 的db客户端(https://github.com/mauricio/postgresql-async,不要在意这个名字,它实际上同时支持mysql和postgres)。只不过对于IO多路复用,数据库官方似乎都没做这种支持——他们只支持JDBC、ODBC等等这些标准协议。

那么为什么基于IO多路复用的实现不能成为默认的,官方的,而要成为偏门呢?

对于数据库开发者来说。这种用法在整体的用户里占有量非常小,所以也许不值当的花大力气。只需要把协议写清楚(比如https://dev.mysql.com/doc/internals/en/client-server-protocol.html),就可以做实现。那么社区的有兴趣的人自然就可以去做。

另外一个原因是体系的支持。简单来讲,如果没有一个大的Reactive的运行环境,IO多路复用的使用会非常受限。

IO多路复用之所以能成立,是需要整个程序要有一个IO多路复用的驱动代码——就是select那句调用——等待事件来临,一个blocking的API。整个程序必须以这个驱动代码为核心。这样就对整个代码的结构产生重大的影响。这种影响是没法用简单的接口抽象的。

Java Web容器之所以可以使用NIO是因为NIO可以被封装到容器内部。Web容器对外暴露的还是传统的多线程形式的Java EE接口。

如果DB和Web容器同时使用NIO,那么调用的DB连接库与必须与容器有一个约定描述DB的连接管理如何接入Web容器的NIO的驱动代码。在Java这个大环境下,不同人,不同的容器写的代码不同;又或者,不使用任何常见的容器,而是自己用NIO去封装一个。这样是无法形成代码上的约定的。那么多个独立的组件就不能很好的共享NIO的驱动代码。

上面这个用法假设整个程序应该共享一个NIO驱动代码。那么Web和DB可不可以各用各的呢?也是可以的,但是为了保证这两个NIO驱动代码不会相互block,最好要分开两个线程。这样一来就会打破一般Web服务一个请求处理用一个线程的一般做法,会让程序边的更复杂——你的业务代码和DB查询之间必须做跨线程数据交换。

相反,连接池的实现就相对独立的多,也简单的多。外界只要配好DB URL,用户名密码和连接池的容量参数,就可以做到自行管理连接。

而Nodejs和Vert.X是完全不同的。他们本质就是Reactive的。他们的NIO的驱动方式是其运行时的基础——所有要在这个基础上开发的代码都必须遵守同样的NIO+异步开发规范,使用同一个NIO的驱动。这样DB与NIO的协作就不成问题了。

最后,有大量场景是需要BIO的DB查询支持的。批处理数据分析代码都是这样的场景。这样的程序写成NIO就会得不偿失——代码不容易懂,也没有任何效率上的优势。类似于Nodejs这样的运行时在此场景下,反而要利用async或等价的语法来让代码看起来是同步的,这样才容易写。

总结一下。DB访问一般采用连接池这种现象是生态造成的。历史上的BIO+连接池的做法经过多年的发展,已经解决了主要的问题。在Java的大环境下,这个方案是非常靠谱的,成熟的。而基于IO多路复用的方式尽管在性能上可能有优势,但是其对整个程序的代码结构要求过多,过于复杂。当然,如果有特定的需要,希望使用IO多路复用管理DB连接,是完全可行的。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 聊聊BIO,NIO和AIO (1)到底什么是“IO Block”BIONIOIO多路复用用epoll实现的IO多路复用epoll的优势水平触发和边沿触发再来思考一下什么是“Block”总结

    大宽宽
  • 如何避免下重复订单为啥会下重了呢?用幂等防止重复订单客户端的流程后端数据表设计下单的实现技术搞定幂等就足够了吗?通知如果还拦不住……这么麻烦,有必要吗?结论

    大宽宽
  • 谈谈自己的大数据迁移经历背景问题规模数据迁移要考虑的问题最后

    大宽宽
  • CSS3 3D旋转立方体 原

    主要用到动画css3  animation,特别注意当完成正方体的过程中,每个面旋转时这个面的坐标系是跟着变换的,只是他们的相对位置不变,默认的变换基点是(50...

    tianyawhl
  • codeforces 438D

    在某位不知名的大大推荐下做了这题,和我上一篇的线段树很像,于是怒拍,思想基本相同,记录区间最大值,当最大值小于取模时可以剪枝。 今后再遇到此类问题算是能解决了 ...

    triplebee
  • 1088 三人行 (20 分)

    本题给定甲、乙、丙三个人的能力值关系为:甲的能力值确定是 2 位正整数;把甲的能力值的 2 个数字调换位置就是乙的能力值;甲乙两人能力差是丙的能力值的 X 倍;...

    可爱见见
  • 主席树POJ2104

    求区间第k大数是多少 用我惯用的线段树写法似乎不适合写主席树,看别人的代码好半天才看懂 用root表示每一个前缀树的根,思想大致是由第i-1个树构成的树建第i个...

    triplebee
  • 十二月——没有寒冬,只有开始

    Rainbond开源
  • Oracle相关提问的智慧技巧

    很久以前的一篇对初学Oracle建议的文章曾提到了提问的智慧,这个问题确实很值得说,我在学生时期,尤其是在本硕阶段中,作为非科班出身,要接触很多新的计算机技术,...

    bisal
  • 开发 | 这六段代码隐藏着深度学习的前世今生!

    AI科技评论按:本文作者Emil Wallner用六段代码解释了深度学习的前世今生,这六段代码覆盖了深度学习几十年来的重大创新和突破,作者将所有代码示例都上传了...

    AI科技评论

扫码关注云+社区

领取腾讯云代金券