Aujourd'hui, j'ai découvert que la méthode de connexion par défaut de Jedis est jedis=new Jedis("localhost",6379), et le délai de connexion se produit toujours. Plus tard, j'ai découvert que le package de classe jedis dispose également d'un moyen de définir le temps de connexion maximum.
1->L'obtention d'une instance Jedis doit être obtenue auprès de JedisPool ;
2->Après avoir utilisé l'instance Jedis, vous devez la renvoyer à JedisPool ;
3->Si Jedis fait une erreur lors de l'utilisation, elle doit également être renvoyée à JedisPool ;
Le code est le suivant
Copiez le code comme suit :
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxActive(100);
config.setMaxIdle(20);
config.setMaxWait(1000l);
Piscine JedisPool ;
pool = nouveau JedisPool(config, "2xx.xx.xx.14", 6379);
booléen empruntOrOprSuccess = true ;
essayer {
jedis = pool.getResource();
// faire Redis opte par instance
} catch (JedisConnectionException e) {
empruntOrOprSuccess = faux ;
si (jedis != nul)
pool.returnBrokenResource(jedis);
} enfin {
si (emprunterOuOprSuccès)
pool.returnResource(jedis);
}
jedis = pool.getResource();
JedisPool dépend du package de classe Apache
commons-pool-1.5.6.jar
1->Bien que JedisConnectionException soit levée, il existe en fait deux types d'erreurs. L'une est pool.getResource(), qui ne peut pas obtenir une instance jedis disponible ; l'autre est que les erreurs pendant jedis.set/get lanceront également cette exception ; Afin de réaliser la distinction, il est implémenté selon que l'instance est nulle. Si elle est nulle, cela prouve que l'instance n'a pas été initialisée du tout, il n'est donc pas nécessaire de la renvoyer au pool si l'instance est nulle. n'est pas nul, cela prouve qu'il faut le remettre dans le pool ;
2->Lorsqu'une erreur d'instance se produit, returnBrokenResource doit également être appelé pour la renvoyer au pool, sinon il se peut qu'il y ait encore des données dans le tampon de l'instance obtenue via getResource la prochaine fois, et un problème peut survenir !
Les paramètres de configuration de JedisPool dépendent en grande partie des exigences réelles de l'application et des capacités logicielles et matérielles. Je n'ai jamais utilisé commons-pool auparavant, donc cette fois j'ai passé toute une pièce à examiner la signification de ces paramètres. . . La plupart des paramètres de configuration de JedisPool sont attribués par les éléments correspondants de JedisPoolConfig.
maxActive : contrôle le nombre d'instances jedis qu'un pool peut être alloué, obtenu via pool.getResource(); si la valeur est -1, cela signifie qu'il n'y a pas de limite si le pool a alloué des instances jedis maxActive, l'état du pool à ; cette fois devient épuisé, dans JedisPoolConfig
maxIdle : contrôle le nombre maximum d'instances jedis à l'état inactif qu'un pool peut avoir ;
whenExhaustedAction : Indique l'action à entreprendre par le pool lorsque toutes les instances jedis du pool ont été allouées ; il existe trois types de WHEN_EXHAUSTED_FAIL par défaut (ce qui signifie que lorsqu'il n'y a pas d'instance jedis, elle sera lancée directement
NoSuchElementException), WHEN_EXHAUSTED_BLOCK (signifie qu'il est bloqué ou qu'une JedisConnectionException est levée lorsque maxWait est atteint), WHEN_EXHAUSTED_GROW (signifie qu'une nouvelle instance de jedis est créée, ce qui signifie que l'ensemble maxActive est inutile) ;
maxWait : indique le temps d'attente maximum lors de l'emprunt d'une instance Jedis. Si le temps d'attente est dépassé, JedisConnectionException sera levée directement ;
testOnBorrow : lors de l'emprunt d'une instance jedis, s'il faut effectuer l'opération Alidate à l'avance si vrai, les instances jedis obtenues sont disponibles ;
testOnReturn : s'il faut effectuer l'opération de validation à l'avance lors du retour au pool ;
testWhileIdle : si vrai, cela signifie qu'il existe un thread d'évitement d'objet inactif analysant l'objet inactif. Si la validation échoue, l'objet sera supprimé du pool ; cet élément n'a de sens que lorsque timeBetweenEvictionRunsMillis est supérieur à 0 ;
timeBetweenEvictionRunsMillis : indique le nombre de millisecondes dont l'éviteur d'objet inactif a besoin pour dormir entre deux analyses ;
numTestsPerEvictionRun : indique le nombre maximum d'objets analysés par l'éviteur d'objets inactifs à chaque fois ;
minEvictableIdleTimeMillis : indique la durée minimale pendant laquelle un objet reste à l'état inactif au moins avant de pouvoir être analysé et expulsé par l'éviteur d'objet inactif ; cet élément n'a de sens que lorsque timeBetweenEvictionRunsMillis est supérieur à 0 ;
softMinEvictableIdleTimeMillis : sur la base de minEvictableIdleTimeMillis, au moins les objets minIdle sont ajoutés au pool. Si -1, expulsé n'expulsera aucun objet en fonction du temps d'inactivité. Si minEvictableIdleTimeMillis>0, ce paramètre n’a aucun sens et n’a de sens que lorsque timeBetweenEvictionRunsMillis est supérieur à 0 ;
lifo : lorsque BoreObject renvoie un objet, DEFAULT_LIFO (dernier entré, premier sorti, la file d'attente la plus fréquemment utilisée similaire au cache) est utilisée. S'il est False, cela signifie une file d'attente FIFO ;
Les paramètres par défaut de JedisPoolConfig pour certains paramètres sont les suivants :
testWhileIdle = vrai
minEvictableIdleTimeMills=60000
timeBetweenEvictionRunsMillis=30000
numTestsPerEvictionRun=-1