接着,今天我们聊一个不常见的 Java 面试题:为什么数据库连接池不采用 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的协议的连接处理和解析稍微改一下:
- 将IO模式调整为Non-Blocking,这样就可以挂到IO多路复用的内核上(select、epoll、kqueue……)
- 在Non-Blocking实现的基础之上实现数据库协议的编码和解析
就可以实现用IO多路复用来访问DB。实际上很多其他语言/框架里都是这么干的。比如 Nodejs,see https://github.com/sidorares/node-mysql2
;或者 Vert.X
作者徽是vip1024c
的 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 多路复用的使用会非常受限。
给大家的福利
零基础入门
对于从来没有接触过网络安全的同学,我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线,大家跟着这个大的方向学习准没问题。
同时每个成长路线对应的板块都有配套的视频提供:
因篇幅有限,仅展示部分资料