Druid est un pool de connexions JDBC (Java Database Connectivity). Cette rubrique explique comment se connecter à LindormTable avec Druid et exécuter les opérations CRUD de base.
Prérequis
Avant de commencer, assurez-vous d'avoir :
Le kit de développement Java (JDK) version 1.8 ou ultérieure installé
Une liste d'autorisation configurée pour votre instance Lindorm. Consultez Configurer les listes d'autorisation
LindormTable version 2.3.1 ou ultérieure. Pour mettre à niveau, consultez Mettre à niveau la version mineure du moteur d'une instance Lindorm
Notes d'utilisation
Cycle de vie des connexions
Les nœuds frontaux Lindorm utilisent Server Load Balancer (SLB) pour l'équilibrage de charge. Pour répartir uniformément les requêtes entre les nœuds frontaux, évitez de maintenir les connexions ouvertes pendant de longues périodes. Définissez les paramètres phyMaxUseCount et phyTimeoutMillis afin de contrôler la durée de vie des connexions.
Après chaque requête, appelez conn.close() pour rendre la connexion au pool. Si une connexion n'est pas rendue et devient invalide, Druid ne peut pas détecter cet état.
Résilience
Dans des environnements réseau complexes, des interruptions de connexion peuvent survenir en raison de goulots d'étranglement au niveau de la passerelle, de variations du réseau (jitter), de taux de retransmission élevés ou de pertes de paquets. Configurez le pool de connexions de manière appropriée et implémentez une logique de nouvelle tentative dans le code de votre application.
Lorsque le serveur est mis à niveau ou redémarré, les connexions peuvent être temporairement interrompues. Même avec un pool de connexions, votre application peut rencontrer des exceptions ; interceptez ces exceptions et implémentez des mécanismes de nouvelle tentative.
Observabilité
Surveillez votre pool de connexions à l'aide des méthodes DruidDataSource#getStatData() et DruidDataSource#dump(). Appelez ces méthodes périodiquement pour vérifier que vos configurations prennent effet, notamment en confirmant que phyMaxUseCount et phyTimeoutMillis recyclent bien les connexions et résolvent tout déséquilibre de charge.
Ajouter les dépendances
Ajoutez les éléments suivants au fichier pom.xml de votre projet Maven. Téléchargez le exemple de code pour exécuter un exemple fonctionnel en local.
Configuration Maven standard
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1.2.11</version>
</dependency>
<dependency>
<groupId>com.aliyun.lindorm</groupId>
<artifactId>lindorm-all-client</artifactId>
<version>2.2.1.3</version>
</dependency>
Configuration Spring Boot Starter
Lorsque vous utilisez druid-spring-boot-starter, excluez le composant druid intégré et ajoutez explicitement la version séparément. Cela permet d'éviter les conflits de version entre le module Druid intégré au starter et le pilote JDBC Lindorm.
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid-spring-boot-starter</artifactId>
<version>1.2.11</version>
<exclusions>
<exclusion>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1.2.11</version>
</dependency>
<dependency>
<groupId>com.aliyun.lindorm</groupId>
<artifactId>lindorm-all-client</artifactId>
<version>2.2.1.3</version>
</dependency>
Se connecter à LindormTable
Étape 1 : Configurer le pool de connexions
Dans le répertoire src/main/resources, créez le fichier druid.properties avec le contenu suivant. Les paramètres sont regroupés en trois catégories :
Remplacer par vos valeurs — obligatoire avant que l'application puisse se connecter
Ajuster selon votre charge de travail — adaptez en fonction de votre concurrence et de votre matériel
Conserver tel quel — les valeurs par défaut sont optimisées pour LindormTable ; les modifier peut provoquer des erreurs
# ── Replace with your values ─────────────────────────────────────────────────
# Driver class name — do not change this value.
driverClassName=com.aliyun.lindorm.table.client.Driver
# Endpoint for LindormTable. Get the value from the Lindorm console.
# See: https://www.alibabacloud.com/help/en/lindorm/user-guide/connect-to-an-apsaradb-for-lindorm-instance#section-xi3-1q0-gv0
url=jdbc:lindorm:table:url=http://ld-bp17j28j2y7pm****.lindorm.rds.aliyuncs.com:30060
# Username and password for LindormTable.
# View or reset credentials in the LindormTable cluster management system.
# See: https://www.alibabacloud.com/help/en/doc-detail/174671.html#topic2090
# To change your password, see: https://www.alibabacloud.com/help/en/doc-detail/174671.html#section-n3z-64v-v73
username=****
password=****
# Target database to connect to.
connectionProperties=database=****
# ── Tune for your workload ────────────────────────────────────────────────────
# Number of connections created at startup.
initialSize=10
# Minimum number of idle connections.
# For high-throughput scenarios, set this equal to maxActive.
# For workloads with significant traffic spikes, use a smaller value.
minIdle=40
# Maximum number of active connections.
# Set this to match your thread pool size.
maxActive=40
# Maximum usage count per connection before it is recycled.
# Recycling connections periodically prevents load imbalance across LDServer nodes.
druid.phyMaxUseCount=10000
# ── Keep as-is ────────────────────────────────────────────────────────────────
# Initialize the pool on startup.
init=true
# Maximum wait time (ms) to acquire a connection from the pool.
maxWait=30000
# Connection keep-alive settings.
# Changing these may cause unexpected disconnections (ConnectionDisconnectedException).
druid.keepAlive=true
druid.keepAliveBetweenTimeMillis=30000
minEvictableIdleTimeMillis=300000
maxEvictableIdleTimeMillis=600000
timeBetweenEvictionRunsMillis=5000
# Maximum connection lifetime (ms) before recycling.
# Together with phyMaxUseCount, this periodically refreshes connections
# to prevent uneven distribution across frontend nodes.
phyTimeoutMillis=1800000
# Connection validation settings.
validationQuery=SELECT 1
testWhileIdle=true
testOnBorrow=false
testOnReturn=false
# Prepared statement cache — disabled to avoid NoSuchStatement errors.
poolPreparedStatements=false
maxOpenPreparedStatements=-1
druid.maxPoolPreparedStatementPerConnectionSize=-1
Pour obtenir la liste complète des paramètres de configuration de Druid, consultez Configuration de DruidDataSource.
Étape 2 : Initialiser le pool de connexions
Chargez le fichier druid.properties et créez la source de données DataSource :
// Load configuration from druid.properties
Properties properties = new Properties();
InputStream inputStream = DruidPoolDemo.class.getClassLoader().getResourceAsStream("druid.properties");
properties.load(inputStream);
// Initialize the connection pool
DataSource dataSource = DruidDataSourceFactory.createDataSource(properties);
Étape 3 : Exécuter les opérations CRUD
Tous les exemples ci-dessous obtiennent une connexion depuis le pool avec dataSource.getConnection() et la rendent via un bloc try-with-resources. Utilisez PreparedStatement pour les requêtes paramétrées afin de prévenir les injections SQL.
Créer une table
String tableName = "sql_table_" + new Random().nextInt(1000);
try (Connection connection = dataSource.getConnection()) {
try (Statement statement = connection.createStatement()) {
String sql = "create table if not exists " + tableName
+ "(id VARCHAR, name VARCHAR, primary key(id))";
int ret = statement.executeUpdate(sql);
System.out.println(ret);
}
}
Insérer des données
try (Connection connection = dataSource.getConnection()) {
String sql = "upsert into " + tableName + "(id,name) values(?,?)";
try (PreparedStatement ps = connection.prepareStatement(sql)) {
ps.setString(1, "aa");
ps.setString(2, "bb");
int ret = ps.executeUpdate();
System.out.println(ret);
}
}
Interroger des données
try (Connection connection = dataSource.getConnection()) {
String sql = "select * from " + tableName + " where id=?";
try (PreparedStatement ps = connection.prepareStatement(sql)) {
ps.setString(1, "aa");
ResultSet rs = ps.executeQuery();
while (rs.next()) {
String id = rs.getString(1);
String name = rs.getString(2);
System.out.println("id=" + id);
System.out.println("name=" + name);
}
}
}
Supprimer des données
try (Connection connection = dataSource.getConnection()) {
String sql = "delete from " + tableName + " where id=?";
try (PreparedStatement ps = connection.prepareStatement(sql)) {
ps.setString(1, "aa");
ps.executeUpdate();
}
}
Annexe : Fonctionnement de l'équilibrage de charge du pool de connexions
Druid utilise des connexions TCP persistantes, plus efficaces que les connexions éphémères, mais qui peuvent entraîner une répartition inégale de la charge entre les nœuds LDServer dans deux scénarios :
Création soudaine de nombreuses connexions
Lorsque votre application crée rapidement un grand nombre de connexions, SLB peut ne pas actualiser suffisamment vite les statistiques des nœuds backend. Certains nœuds LDServer finissent par gérer plus de connexions, ce qui augmente la pression sur ces nœuds.
Anomalies lors des contrôles d'intégrité
SLB utilise des contrôles d'intégrité actifs pour détecter les nœuds backend défectueux. Des échecs temporaires de ces contrôles peuvent amener certains nœuds LDServer à recevoir moins de nouvelles connexions, réduisant ainsi leur utilisation.
Résolution
Les paramètres phyTimeoutMillis et phyMaxUseCount de Druid recyclent périodiquement les connexions du pool, par exemple après 30 minutes ou 10 000 exécutions. Cela force le pool à redistribuer les connexions entre les nœuds backend au fil du temps, résolvant ainsi les deux scénarios sans sacrifier le débit. Ajoutez ces deux paramètres à votre configuration par défaut.
Pour confirmer que les paramètres prennent effet, appelez périodiquement DruidDataSource#getStatData() et DruidDataSource#dump() et vérifiez que les connexions sont bien recyclées aux intervalles attendus.