Fond de recherche:
L'établissement d'une connexion à la base de données est une opération relativement coûteuse (au moins pour OLTP). Non seulement il faut établir une connexion TCP, mais il faut également effectuer des opérations d'authentification de connexion, de sorte que le client enregistre généralement la connexion à la base de données dans le pool de connexions pour la réutiliser. . Le pool de connexions maintient de longues connexions à la base de données élastique (JED). Par défaut, la base de données élastique ne fermera pas activement la connexion client (sauf si une erreur est signalée), mais il y aura généralement des agents d'équilibrage de charge entre le client et la base de données élastique. . Ils sont généralement utilisés pour économiser les ressources de connexion. Après que la connexion soit inactive pendant 10 minutes, la connexion sera activement nettoyée et libérera les ressources de connexion inutiles. Par conséquent, les paramètres de vérification du pool de connexions de certains utilisateurs sont mal configurés, et ils obtiennent alors des connexions non valides. Le client signalera l'erreur suivante :
Sur la base du contexte ci-dessus, nous avons mené une recherche sur les fonctions liées à la détection des pools de connexions et à l'activité des versions courantes des pools de connexions couramment utilisés dans les applications Java, et avons fourni des modèles de configuration JED pour chaque version. Actuellement, les versions de pool de connexions couramment utilisées sont les suivantes :
HikariCP 3.2.0, 3.4.5, 4.0.3
DRUIDE 1.1.10, 1.1.9, 1.0.9
DBCP 1.4, 2.2.0, 2.1.1
HikariCP
Dans notre premier chapitre, introduisons le contenu lié à la détection du pool de connexions HikariCP :
Le pool de connexions HikariCP vérifiera d'abord l'état de l'objet de connexion lorsqu'il devra allouer l'objet de connexion à l'application. Pour détecter si une connexion est disponible, le pool de connexions appelle isConnectionAlivedes méthodes. Si l'objet de connexion est disponible, le pool de connexions attribuera l'objet de connexion à l'application ; si l'objet de connexion n'est pas disponible, le pool de connexions créera un nouvel objet de connexion et allouera le nouvel objet de connexion à l'application.
Par conséquent, lorsque l'objet de connexion du pool de connexions HikariCP échoue, le pool de connexions affichera uniquement un message d'avertissement dans le journal. Il est recommandé de raccourcir la durée de vie maximale de l'objet de connexion (« maxLifetime »). Cependant, cela n'affectera pas l'exécution normale du programme, car le pool de connexions recréera automatiquement un nouvel objet de connexion et l'attribuera à l'application. Par conséquent, les applications peuvent continuer à utiliser les objets de connexion dans le pool de connexions sans être affectées par des connexions obsolètes.
Bien que lors de l'utilisation du pool de connexions HikariCP, si la sonde de connexion n'est pas configurée, l'application ne signalera pas d'erreur lorsqu'elle obtient une connexion non valide, mais lorsque l'application doit exécuter SQL, elle peut rencontrer une connexion non valide, ce qui nécessite de nouveau établissement de la connexion.Ajout d'une surcharge de performances supplémentaire. Cela ne permet pas de tirer pleinement parti du pool de connexions, car son objectif principal est d'améliorer les performances et l'évolutivité de l'application en réutilisant les objets de connexion.
Afin de maximiser la valeur du pool de connexions, examinons le contenu lié au sondage HikariCP et voyons comment utiliser les paramètres de sondage pertinents pour utiliser le pool de connexions plus efficacement.
Les paramètres suivants sont communs à la détection HikariCP :
| le nom du paramètre | illustrer | Valeurs par défaut |
|---|---|---|
| minimumInactif | Le nombre minimum de connexions inactives maintenues par le pool de connexions | 5 |
| taille maximale de la piscine | Le nombre maximum de connexions pouvant être hébergées dans le pool de connexions | dix |
| durée de vie maximale | Ce paramètre est utilisé pour contrôler le cycle de vie maximum de la connexion dans le pool de connexions. Lorsque le temps de connexion établi dépasse ce paramètre, elle sera détruite à l'état inactif. | 1 800 000 (30 minutes) |
| délai d'inactivité | Ce paramètre est utilisé pour contrôler le temps d'inactivité de la connexion dans le pool de connexions. S'il est défini sur 8 minutes, la connexion inactive dépassant le minimumIdle sera nettoyée toutes les 8 minutes. | 600 000 (10 minutes) |
| connexionTestQuery | Ce paramètre dans les versions inférieures exécutera uniquement le SQL configuré avant de fournir une connexion depuis le pool. Ce paramètre s'applique à l'API qui ne prend pas en charge JDBC4 Connection.isValid() et il est recommandé de ne pas configurer le pilote prenant en charge JDBC4 ou supérieur. | aucun |
| keepaliveTime | Cet attribut sert à empêcher l'infrastructure réseau sous-jacente de se déconnecter au fil du temps, à vérifier périodiquement la validité de la connexion et à la supprimer du pool de connexions en cas d'échec de la connexion. Cette valeur doit être inférieure à la valeur maxLifetime. 4. Les nouveaux paramètres introduits dans la version 0.1 et supérieure peuvent être combinés avec le paramètre connectionTestQuery pour tester. | 0 (désactivé) |
Le code de détection du pool de connexion HikariCP est le suivant. On peut voir que lors du sondage, le pool de connexions décidera d'utiliser ou non l'API JDBC pour le sondage en fonction de la valeur de l'attribut isUseJdbc4Validation. La valeur de l'attribut isUseJdbc4Validation est attribuée selon que l'attribut connectionTestQuery est vide lorsque la source de données est initialisé. Si l'attribut connectionTestQuery est vide et que la valeur de l'attribut isUseJdbc4Validation est vraie, le pool de connexions utilisera l'API JDBC pour la détection. Par conséquent, dans JDBC 4.0 et versions ultérieures, il n'est pas recommandé de configurer l'attribut connectionTestQuery pour la vérification, car cela affecterait l'efficacité de la vérification.
Dans les versions inférieures de HikariCP, la connexion ne peut pas être maintenue active et la validité de la connexion ne peut être vérifiée qu'à chaque fois que la connexion est obtenue. Dans la version 4.0.1, le paramètre keepaliveTime est introduit, qui permet de détecter régulièrement la connexion. Par conséquent, afin d'éviter d'obtenir des connexions fermées, dans les versions inférieures, vous ne pouvez ajuster le paramètre maxLifetime qu'à moins de 10 minutes pour éviter complètement d'obtenir des connexions fermées depuis la passerelle. Dans la version 4.0.1 et versions ultérieures, vous pouvez utiliser le paramètre keepaliveTime conjointement avec le paramètre connectionTestQuery pour effectuer une détection de connexion, afin que la détection puisse être effectuée avant l'obtention de la connexion. Cela améliore la fiabilité et la stabilité de la connexion, empêchant les applications de rencontrer des connexions non valides.
Après avoir configuré keepaliveTime, nous pouvons voir que le journal de détection sera imprimé à chaque fois que l'heure configurée est atteinte.
Par conséquent, il est recommandé d'utiliser une version supérieure à 4.0.1 prenant en charge keepaliveTime pour les applications qui utilisent HikariCP en ligne.
Modèle de configuration JED :
HikariCP3.2.0
spring.datasource.hikari.minimumIdle=5
spring.datasource.hikari.maximumPoolSize=10
spring.datasource.hikari.maxLifetime=540000
spring.datasource.hikari.idleTimeout=480000
#JDBC4以上的版本不建议配置connectionTestQuery
spring.datasource.hikari.connectionTestQuery=select 1
Dans la version inférieure, il est principalement garanti que maxLifetime est inférieur à 10 minutes pour éviter complètement d'obtenir la connexion que la passerelle a fermée, mais cela peut entraîner des créations et des destructions fréquentes de connexions, il est donc recommandé d'utiliser une version qui prend en charge keepaliveTime supérieur à 4.0.1.
HikariCP3.4.5
Identique à la version 3.2.0.
HikariCP4.0.3
spring.datasource.hikari.minimumIdle=5
spring.datasource.hikari.maximumPoolSize=10
spring.datasource.hikari.maxLifetime=1800000
spring.datasource.hikari.idleTimeout=600000
#JDBC4以上的版本不建议配置connectionTestQuery
spring.datasource.hikari.connectionTestQuery=select 1
spring.datasource.hikari.keepaliveTime=300000
Dans les versions supérieures à 4.0.1, vous pouvez définir le paramètre keepaliveTime sur moins de 10 minutes pour détecter la connexion, afin d'éviter que la connexion soit fermée par la passerelle, et la durée maxLifetime peut être prolongée pour éviter la création et la destruction fréquentes de connexions. .
Document de référence : https://github.com/brettwooldridge/HikariCP#readme
L'élève de troisième année du secondaire a écrit la version Web de Windows 12 deepin ." -IDE qui a officiellement fait ses débuts, connue sous le nom de "recherche et développement véritablement indépendants "Père de Hongmeng" Wang Chenglu : Le système de version Hongmeng PC sera lancé l'année prochaine et Wenxin sera ouvert à l'ensemble de la société .Officiellement publié 3.2.0 Green Language V1.0 Officiellement publiéAuteur: Jingdong Retail Wang Leixin
Source : Réimprimé par la communauté des développeurs JD Cloud, veuillez indiquer la source