Anweisungen zur Verwendung des Datenbankverbindungspools Druid

Ersetzen Sie ihn durch den optimalen Datenbankverbindungspool, basierend auf umfassender Leistung, Zuverlässigkeit, Stabilität, Skalierbarkeit, Benutzerfreundlichkeit und anderen Faktoren.

Druide:druid-1.0.29

Datenbank Mysql.5.6.17

Ersatzziel: Ersetze C3P0 durch Druide

Ersatzgrund:

1. In Bezug auf die Leistung: hikariCP>druid>tomcat-jdbc>dbcp>c3p0. Die hohe Leistung von hikariCP beruht auf der maximalen Vermeidung von Sperrkonflikten.

2. Druid verfügt über die umfassendsten Funktionen, einschließlich SQL-Interception und anderer Funktionen, und verfügt über relativ umfassende statistische Daten und eine gute Skalierbarkeit.

3. Im Hinblick auf umfassende Leistung und Skalierbarkeit können Sie die Verwendung des Druid- oder HikariCP-Verbindungspools in Betracht ziehen, der für die Überwachung und Verfolgung von JDBC-Schnittstellen bequemer ist.

4. Sie können den PrepareStatement-Cache aktivieren, wodurch die Leistung um etwa 20 % verbessert wird.

psCache ist für die Verbindung privat, daher gibt es kein Thread-Konfliktproblem. Das Aktivieren von pscache führt nicht zu Leistungsverlusten aufgrund von Konflikten.

Der Schlüssel von psCache ist das von Prepare ausgeführte SQL und der Katalog, und der Wert entspricht dem PrepareStatement-Objekt. Durch die Aktivierung des Caching wird vor allem der Mehraufwand beim Parsen von SQL reduziert.

5. 3p0 hat eine lange Geschichte und sein Code ist äußerst komplex, was der Wartung nicht förderlich ist. Und es besteht das potenzielle Risiko einer Sackgasse.

6. Druid kann SQL- und langsame Abfrageprotokolle drucken

Druidenparameter

Und so geht's:

Der Datenbankverbindungspool erstellt während der Initialisierung initialSize-Verbindungen und wenn ein Datenbankvorgang stattfindet, wird eine Verbindung aus dem Pool genommen. Wenn die Anzahl der aktuell im Pool verwendeten Verbindungen gleich maxActive ist, wird eine Weile gewartet, bis andere Vorgänge eine Verbindung freigeben. Wenn die Wartezeit maxWait überschreitet, wird ein Fehler gemeldet. Wenn die Anzahl der aktuell verwendeten Verbindungen maxActive nicht erreicht, wird festgestellt, ob eine inaktive Verbindung vorhanden ist. Wenn dies der Fall ist, wird die inaktive Verbindung direkt verwendet. Wenn nicht, wird eine neue Verbindung hergestellt. Nachdem die Verbindung verwendet wurde, wird sie nicht physisch geschlossen, sondern in den Pool gelegt und wartet auf die Wiederverwendung durch andere Vorgänge. Gleichzeitig gibt es im Verbindungspool einen Mechanismus, der ermittelt, ob die aktuelle Gesamtzahl der Verbindungen kleiner als miniIdle ist. Dann wird eine neue inaktive Verbindung hergestellt, um sicherzustellen, dass die Anzahl der Verbindungen miniIdle beträgt. Wenn eine Verbindung im aktuellen Verbindungspool nach einer Leerlaufzeit von timeBetweenEvictionRunsMillis immer noch nicht verwendet wird, wird sie physisch geschlossen. Einige Datenbankverbindungen haben Timeout-Begrenzungen (MySQL-Verbindungen werden nach 8 Stunden getrennt) oder die Verbindung zum Verbindungspool kann aufgrund von Netzwerkunterbrechungen und anderen Gründen ungültig werden. In diesem Fall kann durch Setzen eines testWhileIdle-Parameters auf true sichergestellt werden, dass der Verbindungspool regelmäßig die Verfügbarkeit von Verbindungen erkennt. Nicht verfügbare Verbindungen werden verworfen oder neu aufgebaut, und das aus dem Verbindungspool erhaltene Verbindungsobjekt ist im besten Fall garantiert verfügbar. Um absolute Verfügbarkeit sicherzustellen, können Sie natürlich auch testOnBorrow auf „true“ setzen (d. h. die Verfügbarkeit des Verbindungsobjekts beim Abrufen prüfen), dies wirkt sich jedoch auf die Leistung aus.

Wenn Sie eine SQL-Überwachung durchführen möchten, können Sie den folgenden Code hinzufügen:

Log4j2Filter log4j2 = neuer Log4j2Filter(); 
log4j2.setResultSetLogEnabled(false); 
log4j2.setStatementSqlPrettyFormat(false); 
log4j2.setStatementExecutableSqlLogEnable(true); 
 
log4j2.setDataSourceLogEnabled(false); 
log4j2.setConnectionLogEnabled(false); 
log4j2.setStatementLogEnabled(false); 
log4j2.setResultSetLogEnabled(false); 
ret.setProxyFilters(Arrays.asList(log4j2));

Die Leerlauferkennung, der Verbindungsaufbau und die Bereinigung abgebrochener Verbindungen werden von diesen drei Threads verwaltet.

Daemon-Thread [Thread zur Bereinigung abgebrochener Verbindungen] 
Daemon-Thread [Druid-ConnectionPool-Create-1184124073] 
Daemon-Thread [Druid-ConnectionPool-Destroy-1184124073]

Zusammenfassen

Dies ist der gesamte Inhalt dieses Artikels zur Verwendung des Datenbankverbindungspools Druid. Ich hoffe, er wird für alle hilfreich sein. Interessierte Freunde können sich auf Folgendes beziehen: Detaillierte Erläuterung der MySQL-Vorbereitungsprinzipien und anderer verwandter Themen. Wenn Sie Fragen haben, können Sie jederzeit eine Nachricht hinterlassen und der Herausgeber wird Ihnen rechtzeitig antworten.