比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。
DruidDataSource
3000行
,
druid
是在jdbc的基础上,自己编码做得增强。druid生活在第一、二代连接池的面向过程的年代,忘了松耦合,
监控
和数据库
连接池
做在一个项目里(紧耦合没隔离)。监控在service mesh的。
未来的中间件,一定是和spring生态圈、servich mesh一样,大道至简,越来越薄,升级中间件不再是需要用户强行升级maven依赖解决依赖冲突,而是通过
mesh的方式
极致到升级让业务方
无感知
。热部署、潘多拉boot、容器隔离等解决依赖冲突的妥协方式也将可能大概率
被置换掉
。
四、从Sharding-jdbc架构演进看未来
Database Mesh(
搭乘 Service Mesh 新词
):
用
啮合层
将数据库(散落系统各个角落)
统一治理
。
首要目标:啮合应用与数据库
间的交互(这样的
交互网络
像蜘蛛网一样
复杂而有序
),不是啮合db中的数据,将
分布式
数据访问
应用
与
数据库
有机
串联。
Sharding-JDBC 以 JDBC 层分片架构图如下: