主流Java数据库连接池比较

Java提高 专栏收录该内容
27 篇文章 0 订阅

转载自:https://www.jianshu.com/p/b9b98ac3e010

一、主流数据库连接池

C3p0: 实现数据源和JNDI绑定,支持JDBC3规范和JDBC2的标准扩展。Hibernate、Spring使用。单线程,性能较差,适用于小型系统,代码600KB左右。

DBCP (Database Connection Pool):Apache的, commons-pool对象池机制,Tomcat使用。单独使用dbcp需要3个包:common-dbcp.jar,common-pool.jar,common-collections.jar,预先将数据库连接放内存中,建立数据库连接时,直接到连接池中申请,用完放回。单线程,并发量低,性能不好,适用于小型系统。

Tomcat Jdbc Pool:Tomcat在7.0以前都是使用,单线程,保证线程安全会锁整个连接池,性能差,超过60个类复杂。Tomcat从7.0开始叫做Tomcat jdbc pool,基于Tomcat JULI,使用Tomcat日志框架,完全兼容dbcp,异步方式获取连接,支持高并发应用环境,核心文件8个,支持JMX,支持XA Connection。

BoneCP:高效、免费。设计提高性能,速度最快,高度可扩展:集成Hibernate和DataNucleus中。连接状态切换的回调机制;允许直接访问连接;自动化重置能力;JMX支持;懒加载能力;支持XML和属性文件配置方式;较好的Java代码组织,100%单元测试分支代码覆盖率;代码40KB左右。

Druid:Java中最好,强大监控和扩展,可用于大数据实时查询和分析的高容错、高性能分布式系统,尤其是当发生代码部署、机器故障以及其他产品系统遇到宕机等情况时,100%正常运行。主要特色:分析监控;交互式查询快;高可用;可扩展;

主流连接池各项功能对比如下
img

有HikariCP的
img

二、HikariCP性能分析:

HikariCP通过优化**(concurrentBag,fastStatementList** )集合来提高并发的读写效率。
使用threadlocal缓存连接及大量使用CAS的机制,最大限度的避免lock。可能带来cpu使用率的上升。
字节码的维度优化代码。 (default inline threshold for a JVM running the server Hotspot compiler is 35 bytecodes )让方法尽量在35个字节码一下,提升jvm的处理效率。HikariCP做的优化补充如下:

img

img

mysql connecter 源码里用的就是ping命令

img

比HikariCP更快的数据库连接池:https://github.com/mauricio/postgresql-async

scala生态圈的。用netty实现mysql协议,没用mysql官方connector,纯异步,连接池写的随便,性能依然很好。

三、前瞻,未来到底是HikariCP还是Druid的天下?

容器调度加编排的云操作系统取而代单机的操作系统。裸机或者虚拟机的运行时也将会被容器取代。通信方面将会使用Service Mesh。

中间件趋势是弱化到无感知。maven依赖问题,把二方库写在pom里,监控等代码的硬编码进应用里都将逐渐弱化到不复存在,取而代之的那些java agent(如pinpoint、skywalking之类),或是service mesh这种side car模式都是可以做中间件(包括连接池)的监控的。

有赞用HikariCP替换durid后,RT出现断崖式下滑(1.5ms ~ 1.2ms) 并且持续稳定毛刺少。性能测试与压测之后,比druid性能提高一倍。

未来的中间件,一定是和spring生态圈、servich mesh一样,大道至简,越来越薄,升级中间件不再是需要用户强行升级maven依赖解决依赖冲突,而是通过mesh的方式极致到升级让业务方无感知。热部署、潘多拉boot、容器隔离等解决依赖冲突的妥协方式也将可能大概率被置换掉。

四、从Sharding-jdbc架构演进看未来

Database Mesh(搭乘 Service Mesh 新词):用啮合层将数据库(散落系统各个角落)统一治理。

首要目标:啮合应用与数据库间的交互(这样的交互网络像蜘蛛网一样复杂而有序),不是啮合db中的数据,将分布式数据访问应用与数据库有机串联。Sharding-JDBC 以 JDBC 层分片架构图如下:

img

Sharding-JDBC 分别实现 Driver、Server 、Sidecar 三个不同版本,组成 Sharding-JDBC 的生态圈,为不同的需求与环境提供差异化服务。

img

Sharding-JDBC-Server 使原来 DBA 通过 Sharding-JDBC-Driver无法对数据进行操作的缺憾得到了补偿。由于 Sharding-JDBC-Driver 无需通过代理层进行二次转发,因此线上性能更佳,可通过以下的混合部署方案使用 Sharding-JDBC:

img

Sharding-JDBC-Driver:
线上应用使用,直连数据库以获取最优性能;

用 MySQL 命令行或 UI 客户端,连接 Sharding-JDBC-Server 方便的查询数据和执行各种 DDL 语句。

同一注册中心集群,通过管理端配置注册中心中的数据,注册中心自动将配置变更推送至 Driver 和 Server 应用。若数据库拆分的过多而导致连接数会暴涨,则可以考虑直接在线上使用 Sharding-JDBC-Server,以达到有效控制连接数的目的。

Sharding-JDBC-Sidecar 将问世,部署架构:

img

基于 Sharding-JDBC 的 Database Mesh 与 Service Mesh 互不干扰,相得益彰。服务之间的交互由 Service Mesh Sidecar接管,基于 SQL 的数据库访问由 Sharding-JDBC-Sidecar接管(随着宿主机的生命周期创建和消亡的)。

非静态 IP,完全动态和弹性的存在,无中心节点。数据运维等操作,启动Sharding-JDBC-Server 进程作为静态 IP 入口,通过各种命令行或 UI 客户端进行操作。

  • 1
    点赞
  • 1
    评论
  • 4
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
©️2020 CSDN 皮肤主题: 技术黑板 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值