Mainstream Java database connection pool analysis (C3P0,DBCP,TOMCATPOOL,BONECP,DRUID)

Mainstream database connection pool

Common open source database connection pools are c3p0, DBCP, Tomcat Jdbc pool, BONECP, druid, etc.

C3P0: Open source JDBC Connection pool, which implements the data source and Jndi bindings, supports the standard extension of the JDBC3 specification and JDBC2. The open source projects that currently use it are hibernate, spring, and so on. Single thread, poor performance, suitable for small systems, code around 600KB.

DBCP (Database Connection pool): A Java Database connection pool project developed by Apache, Jakarta Commons-pool object pooling mechanism, the connection pool component used by Tomcat is DBCP. Use of DBCP alone requires 3 packages: Common-dbcp.jar,common-pool.jar, Common-collections.jar, pre-placing the database connection in memory, the application needs to establish a database connection directly to the connection pool to apply for a line, run out and put back. Single thread, low concurrency, poor performance, suitable for small systems.

Tomcat Jdbc Pool:tomcat used common-dbcp as a connection pool component before 7.0, but DBCP is single-threaded, with poor performance, DBCP has more than 60 classes, and is relatively complex to ensure that the entire connection pool is locked for the line Shuo plenary. Tomcat introduced the new Connection pool module from 7.0, called the Tomcat JDBC Pool, based on Tomcat Juli, using the Tomcat Log framework, fully compatible with DBCP, getting connections asynchronously, supporting high concurrency applications, and a super simple core file with only 8 Supports JMX and supports XA Connection.

BONECP: Official statement BONECP is an efficient, free, open source Java database connection pool implementation library. Designed to improve database connection pool performance, according to some test data shows that the BONECP speed is the fastest, than the second fast connection pool at the time of about 25 times times faster, perfect integration into some persistent products such as Hibernate and DataNucleus. BONECP Features: Highly scalable, fast, callback mechanism for connection state switching, direct access connection, automatic reset capability, JMX support, lazy loading capability, support for XML and attribute file configuration, good Java Code organization, 100% Unit Test Branch code coverage; Code 40KB or so.

Druid:druid is the best database connection pool in the Java language, DRUID provides powerful monitoring and scaling capabilities, and is a highly fault-tolerant, high-performance, open-source distributed system for real-time query and analysis of big data, especially when code deployment occurs, Druid can still maintain 100% uptime when machine failures and other product systems are experiencing downtime. Main features: For analysis and monitoring design; Fast interactive query, high availability, expandable; Druid is an open source project, and the source is hosted on GitHub.

The main connection pool functions are compared as follows:

We'll see a group of HIKARICP.

HIKARICP Performance Analysis:

• HIKARICP improves concurrent read and write efficiency by optimizing (Concurrentbag,faststatementlist) collections.

• HIKARICP uses a threadlocal cache connection and a large number of CAS mechanisms to avoid lock. A single possible increase in CPU usage.

• Optimize the code from the dimensions of the bytecode. (the default inline threshold for a JVM running the server Hotspot compiler is a bytecodes) allows the method to be as low as 35 bytecode to improve the JVM's processing efficiency.

The optimization additions made by HIKARICP are as follows:

The MySQL connecter source uses the ping command.

A faster database connection pool than HIKARICP

A colleague told me that the connection pool, which was faster than Hikari, had been used and studied Https://github.com/mauricio/postgresql-async, which is something of the Scala biosphere. With Netty implementation of the MySQL protocol, no use of MySQL official connector, pure asynchronous, its connection pool is written more casually, but performance is still very good.

Looking forward, in the end is HIKARICP or Druid of the world?

Many people are asking, the second generation of connection pool standing on the shoulders of giants HIKARICP and Druid in the end what is the strong or weak? In fact, I think this is a problem that need not be discussed.

Let's take a look at the future trend: the single-machine operating system will be discarded and replaced by the container scheduling and orchestration of the cloud operating system. The runtime of a bare-metal or virtual machine will also be replaced by a container. Service Mesh will be used in communications.

That is to say, the final trend of middleware must be weakened to no sense, this is the ultimate road to Jane's direction. Those maven dependency issues, the two-party library written in the POM, monitoring and other code hard-coded into the application will be gradually weakened to no longer exist, the replacement of those Java agents (such as pinpoint, skywalking, etc.), or service mesh this side Car mode is capable of monitoring the middleware (including connection pooling).

A good friend told me that, in the likes of the core application, with HIKARICP replacement Durid, RT has a cliff-like decline (1.5ms ~ 1.2ms) and continuous stable burr less. After performance testing and pressure measurement, the performance of a core system increases by about one times compared to Druid.

Punks do the following statistical work, are based on the latest tag statistics, only statistics Java files and XML files, Druid (ALIBABA-DRUID) Total number of rows: 430289,HIKARICP (BRETTWOOLDRIDGE-HIKARICP) Total number of rows : 18372. Statistics Java code only, Druid (ALIBABA-DRUID) Total number of rows: 428749,HIKARICP (BRETTWOOLDRIDGE-HIKARICP) Total number of rows: 17556. Then filter the test directory, (ALIBABA-DRUID) Total number of rows: 215232, (BRETTWOOLDRIDGE-HIKARICP) Total number of rows: 7960. Light a druiddatasource on 3000 lines, and do not say performance, Druid is on the basis of JDBC, their own code to do the enhancement.

If so, Druid is precisely the process-oriented era of life in the first and second generation connection pools. Druid may have forgotten the concept of loose coupling, the monitoring and database connection pool in a project, itself is tightly coupled. Since microservices promote business isolation, shouldn't this be isolated? Is it okay to have the component tools do only one thing at a time? Monitoring things in the future of service mesh after all there are other natural ways of monitoring rather than hard coding in a small pool of connections. To sum up, put in the current or future trend to spell, the approximate rate than the Hug Springboot 2.0 and the road to Jane Concise to the extreme HIKARICP.

The middleware of the future must be the same as the spring ecosystem and Servich mesh, the boulevard to Jane, increasingly thin, upgrade middleware no longer requires users to forcibly upgrade Maven dependencies to resolve the dependency conflict, but through the mesh way to the extreme to the upgrade to the business party without perception. So the way to resolve conflict-dependent compromises, such as hot deployment, Pandora boot, and container isolation, will probably be replaced.

Looking into the future from the evolution of SHARDING-JDBC architecture

Database Mesh, a new vocabulary derived from the wave of Service mesh. As the name implies, database mesh uses a meshing layer to unify the databases scattered across every corner of the system. The interaction network between the application and the database, which is concentrated together through the meshing layer, is as complex and orderly as a spider web. Its primary goal is not to engage the data stored in the database, but to engage the interaction between the application and the database.

The focus of database Mesh is on how to combine distributed data access applications with databases, and it focuses more on interaction, which is an effective carding of the interaction between the cluttered application and the database.

Using database mesh, the applications and databases that access the databases will eventually form a huge grid system, and the application and database can only be reserved in the grid system, and they are all objects that are governed by the meshing layer.

SHARDING-JDBC has always been using JDBC layer fragmentation as its core concept. It has the following architectural diagram:

SHARDING-JDBC will implement the three different versions of Driver, Server and Sidecar, together with the SHARDING-JDBC ecosystem to provide differentiated services for different needs and environments.

Due to the advent of Sharding-jdbc-server, the original DBA through the Sharding-jdbc-driver can not operate the data to compensate for the shortcomings. Because the sharding-jdbc-driver does not need to be forwarded two times through the proxy layer, it performs better on-line and can use SHARDING-JDBC with the following hybrid deployment scenarios:

Online applications use the Sharding-jdbc-driver Direct database for optimal performance, using MySQL command line or UI client connections to sharding-jdbc-server convenient query data and execute various DDL statements. They use the same registry cluster to automatically push configuration changes to the Driver and Server apps by the registry by configuring the data in the registry through the management side. If there are too many database splits causing the number of connections to skyrocket, consider using sharding-jdbc-server directly online for the purpose of effectively controlling the number of connections.

In the near future, Sharding-jdbc-sidecar will also be available, and its deployment architecture is:

The SHARDING-JDBC-based Database mesh and Service mesh are mutually exclusive. The interaction between services is taken over by the service Mesh Sidecar, and SQL-based database access is taken over by Sharding-jdbc-sidecar.

For business applications, whether RPC or database access, there is no need to focus on their real physical deployment structure, to achieve a true 0 intrusion. Since Sharding-jdbc-sidecar is created and extinct as the host's life cycle,

Therefore, it is not a static IP, but a complete dynamic and elastic existence, the entire system does not exist any central node. For operations such as data operation, you can still operate through various command lines or UI clients by starting a sharding-jdbc-server process as a portal to the static IP.

This article turns from:https://www.toutiao.com/a6551532416505217539/?tt_from=mobile_qq&utm_campaign=client_share& Timestamp=1526087841&app=news_article&utm_source=mobile_qq&iid=32174471432&utm_medium=toutiao_ Android

Mainstream Java database connection pool analysis (C3P0,DBCP,TOMCATPOOL,BONECP,DRUID)