Tous les produits
Search

Ce produit

    Tair (Redis® OSS-Compatible):Connection pool best practices for cluster proxy mode

    Centre de documentation

    Tair (Redis® OSS-Compatible):Connection pool best practices for cluster proxy mode

    Dernière mise à jour :Aug 08, 2026

    Le pool de connexions en mode proxy de cluster réutilise les connexions entre le proxy et la base de données, empêchant l'épuisement des connexions backend dû aux commandes avec état et garantissant la stabilité de votre instance Tair (Redis OSS-compatible).

    Scénarios

    En mode proxy de cluster cloud natif, les commandes standard utilisent des connexions partagées ; ainsi, l'augmentation du nombre de connexions client n'affecte pas les connexions à la base de données backend. Toutefois, certaines commandes avec état font basculer la connexion du proxy vers le nœud de données d'un mode partagé vers un mode exclusif.

    En mode exclusif, chaque connexion client crée une connexion dédiée sur le nœud de données. En cas de forte concurrence, le nombre de connexions aux nœuds de données augmente linéairement avec celui des connexions client, ce qui peut déclencher une erreur max number of clients reached et provoquer des interruptions de service.

    L'ajout de shards (mise à l'échelle horizontale) ne résout pas l'épuisement des connexions par shard causé par les commandes WATCH ou les requêtes bloquantes.

    Commandes qui déclenchent le mode exclusif :

    • Commandes de transaction : MULTI/EXEC (après WATCH)

    • Commandes bloquantes : BLPOP, BRPOP, BRPOPLPUSH et XREAD ... BLOCK ...

    Le pool de connexions réutilise les connexions exclusives entre le proxy et le nœud de données, réduisant ainsi le nombre de connexions aux nœuds de données et prévenant les pannes liées au dépassement de la limite de connexions.

    Architecture

    Chaque instance enfant du proxy exécute un pool de connexions indépendant et maintient un pool dédié pour chaque nœud de données.

    image

    Exemple :

    Sans pool de connexions, chaque connexion client-proxy établit une connexion distincte vers chaque shard backend. Par exemple, 10 connexions client accédant à 5 shards créent 10 × 5 = 50 connexions.

    Avec le pooling de connexions activé, le proxy maintient un pool limité pour chaque shard et les requêtes client réutilisent les connexions mises en pool. Par exemple, les mêmes 10 connexions client peuvent nécessiter seulement 2 connexions en pool par shard, soit un total de 2 × 5 = 10 connexions.

    Flux de travail :

    1. Lorsqu'un client initie une requête en mode exclusif, le proxy récupère une connexion inactive dans le pool de connexions du shard cible.

    2. Succès du pool (hit) : une connexion inactive est attachée à la connexion client pour la requête. Une fois la requête terminée, la connexion est détachée et renvoyée au pool pour réutilisation.

    3. Échec du pool (miss) : le proxy crée une nouvelle connexion. Une fois la requête terminée :

      1. Si le pool n'a pas atteint sa limite (private_conn_pool_max_idle_per_db), la connexion est ajoutée au pool.

      2. Si le pool est plein, la connexion est libérée immédiatement (mode de connexion éphémère).

    Cela réduit la surcharge de gestion des connexions, diminue la consommation de ressources sur la base de données et améliore la stabilité ainsi que le débit.

    Prérequis

    Votre instance doit répondre aux exigences suivantes :

    Activer le pooling de connexions

    Activez le pooling de connexions en modifiant un paramètre de l'instance. Il s'agit d'une mise à jour à chaud qui ne nécessite aucun redémarrage et n'affecte pas les services en cours d'exécution.

    1. Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez une région. Cliquez ensuite sur l'ID de l'instance cible.

    2. Dans le volet de navigation de gauche, cliquez sur Parameter Settings.

    3. Recherchez private_conn_pool_enabled et cliquez sur Modify dans la colonne Actions.

    4. Dans la boîte de dialogue, définissez la valeur sur 1 et cliquez sur OK.

    Pour vérifier, consultez la métrique Connections from Proxy to DB sous Infrastructure Monitoring dans la console Cloud Monitor afin de comparer les données avant et après l'activation de la fonctionnalité.

    Configuration et optimisation

    Nom de la configuration

    Description

    Valeur par défaut

    Plage de valeurs

    private_conn_pool_enabled

    Active ou désactive le pooling de connexions. 1 : activé. 0 : désactivé.

    0

    `[0

    1]`

    private_conn_idle_time_sec

    Durée de vie (TTL) des connexions inactives dans le pool, en secondes. Les connexions inactives au-delà de ce seuil sont fermées. 0 : fermeture immédiate.

    60

    [0-4294967295]

    private_conn_pool_max_idle_per_db

    Nombre maximal de connexions inactives que chaque nœud proxy maintient par nœud de données. Lorsque cette limite est atteinte, les connexions libérées sont fermées au lieu d'être renvoyées au pool.

    1000

    [0-4294967295]

    private_conn_pool_min_idle_per_db

    Nombre minimal de connexions inactives que chaque nœud proxy maintient par nœud de données. Les connexions en dessous de ce seuil sont conservées même si elles dépassent private_conn_idle_time_sec.

    0

    [0-4294967295]

    Recommandations d'optimisation

    • Scénarios généraux : utilisez les valeurs par défaut. Elles conviennent à la plupart des charges de travail.

    • Scénarios de transactions à forte concurrence et courte durée (comme les ventes flash)

      • Caractéristiques : connexions éphémères avec des cycles d'emprunt et de retour fréquents.

      • Recommandation : définissez private_conn_pool_max_idle_per_db à une valeur suffisamment élevée pour couvrir les pics de requêtes concurrentes, maximisant ainsi la réutilisation et évitant les connexions éphémères. Vous pouvez éventuellement réduire private_conn_idle_time_sec pour libérer plus rapidement les ressources pendant les heures creuses.

    • Scénarios de services à blocage long (comme les consommateurs de file d'attente)

      • Caractéristiques : connexions détenues longtemps et rarement renvoyées au pool.

      • Recommandation : augmentez private_conn_pool_max_idle_per_db pour qu'il corresponde au nombre de consommateurs concurrents. Définissez private_conn_pool_min_idle_per_db légèrement au-dessus du nombre moyen de connexions concurrentes pour précharger les connexions et réduire la latence pour les nouveaux consommateurs.

    • Scénarios à mémoire limitée ou petites instances

      • Caractéristiques : budget mémoire strict.

      • Recommandation : réduisez private_conn_pool_max_idle_per_db et private_conn_pool_min_idle_per_db. Cela permet de sacrifier une partie de l'efficacité de réutilisation pour réduire la consommation de mémoire sur les nœuds de données.

    Remarques d'utilisation

    • **Définissez une valeur raisonnable pour private_conn_pool_min_idle_per_db**

      Chaque connexion inactive consomme de la mémoire sur le nœud de base de données backend. Avec plusieurs shards et nœuds proxy, une valeur élevée de private_conn_pool_min_idle_per_db peut entraîner une utilisation excessive de la mémoire.

    • Évitez les changements de contexte de base de données inutiles

      Lorsqu'une connexion en pool est réutilisée par un client accédant à un index de base de données différent, le proxy exécute une commande SELECT pour changer de contexte, ce qui augmente la charge de la base de données et la latence. Concevez votre application pour utiliser un seul index de base de données (généralement DB 0).

    • Non applicable aux commandes de publication/abonnement

      Le pooling de connexions ne s'applique pas aux commandes SUBSCRIBE et PSUBSCRIBE. Ces commandes occupent une connexion de manière permanente et ne sont pas gérées par le pool.

    Références