一、主流数据库连接池
C3p0: 实现数据源和JNDI绑定,支持JDBC3规范和JDBC2的标准扩展。Hibernate、Spring使用。单线程,性能较差,适用于小型系统,代码600KB左右。
DBCP (Database Connection Pool):Apache的, Jakarta 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%正常运行。主要特色:分析监控;交互式查询快;高可用;可扩展;
主流连接池各项功能对比如下:
有HikariCP的
二、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做的优化补充如下:
mysql connecter 源码里用的就是ping命令
比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性能提高一倍。
阿飞基于最新tag统计java、xml文件,druid(alibaba-druid)总行数:430289,HikariCP(brettwooldridge-HikariCP)总行数:18372。
只统计java代码,druid(alibaba-druid)总行数:428749,HikariCP(brettwooldridge-HikariCP)总行数:17556。
再过滤一下test目录,(alibaba-druid)总行数:215232,(brettwooldridge-HikariCP)总行数:7960。
DruidDataSource3000行,druid是在jdbc的基础上,自己编码做得增强。druid生活在第一、二代连接池的面向过程的年代,忘了松耦合,监控和数据库连接池做在一个项目里(紧耦合没隔离)。监控在service mesh的。
未来的中间件,一定是和spring生态圈、servich mesh一样,大道至简,越来越薄,升级中间件不再是需要用户强行升级maven依赖解决依赖冲突,而是通过mesh的方式极致到升级让业务方无感知。热部署、潘多拉boot、容器隔离等解决依赖冲突的妥协方式也将可能大概率被置换掉。
四、从Sharding-jdbc架构演进看未来
Database Mesh(搭乘 Service Mesh 新词):用啮合层将数据库(散落系统各个角落)统一治理。
首要目标:啮合应用与数据库间的交互(这样的交互网络像蜘蛛网一样复杂而有序),不是啮合db中的数据,将分布式数据访问应用与数据库有机串联。Sharding-JDBC 以 JDBC 层分片架构图如下:
Sharding-JDBC 分别实现 Driver、Server 、Sidecar 三个不同版本,组成 Sharding-JDBC 的生态圈,为不同的需求与环境提供差异化服务。
Sharding-JDBC-Server 使原来 DBA 通过 Sharding-JDBC-Driver 无法对数据进行操作的缺憾得到了补偿。由于 Sharding-JDBC-Driver 无需通过代理层进行二次转发,因此线上性能更佳,可通过以下的混合部署方案使用 Sharding-JDBC:
Sharding-JDBC-Driver:
线上应用使用,直连数据库以获取最优性能;
用 MySQL 命令行或 UI 客户端,连接 Sharding-JDBC-Server 方便的查询数据和执行各种 DDL 语句。
同一注册中心集群,通过管理端配置注册中心中的数据,注册中心自动将配置变更推送至 Driver 和 Server 应用。若数据库拆分的过多而导致连接数会暴涨,则可以考虑直接在线上使用 Sharding-JDBC-Server,以达到有效控制连接数的目的。
Sharding-JDBC-Sidecar 将问世,部署架构:
基于 Sharding-JDBC 的 Database Mesh 与 Service Mesh 互不干扰,相得益彰。服务之间的交互由 Service Mesh Sidecar 接管,基于 SQL 的数据库访问由 Sharding-JDBC-Sidecar 接管(随着宿主机的生命周期创建和消亡的)。
非静态 IP,完全动态和弹性的存在,无中心节点。数据运维等操作,启动Sharding-JDBC-Server 进程作为静态 IP 入口,通过各种命令行或 UI 客户端进行操作。
硬编码
scala
Sharding-JDBC
JNDI绑定,JDBC3规范和JDBC2的标准,
用netty实现mysql协议,没用mysql官方connector
二方库