Tair (Redis® OSS-Compatible):Retry mechanisms for Redis clients

Effectuez uniquement des nouvelles tentatives pour les opérations idempotentes

Un dépassement de délai peut survenir à n'importe quelle étape de l'exécution d'une commande :

• La commande n'a pas atteint le serveur.

• La commande a atteint le serveur, mais son exécution a expiré.

• La commande a été exécutée sur le serveur, mais la réception de la réponse a expiré.

Étant donné qu'une opération relancée peut s'exécuter plusieurs fois, effectuez des nouvelles tentatives uniquement pour les opérations idempotentes.

Idempotent -- SET a b : l'exécution multiple de cette commande produit toujours le même résultat.

Non idempotent -- LPUSH mylist a : l'exécution multiple de cette commande ajoute des éléments a en double à mylist.

Définissez un nombre de nouvelles tentatives et un intervalle appropriés

Définissez le nombre de nouvelles tentatives et l'intervalle en fonction de votre charge de travail :

• Trop peu de nouvelles tentatives ou un intervalle trop long : l'application risque de ne pas parvenir à achever les opérations lors de pannes transitoires brèves.

• Trop de nouvelles tentatives ou un intervalle trop court : l'application consomme des ressources excessives et peut submerger le serveur.

Évitez l'imbrication des nouvelles tentatives

L'imbrication des nouvelles tentatives, où une opération de relance déclenche une autre boucle de nouvelle tentative, peut entraîner des répétitions ou un nombre illimité de tentatives. Implémentez la logique de nouvelle tentative à un seul niveau de votre pile applicative.

Journalisez les échecs de nouvelle tentative

Générez des journaux de nouvelle tentative au niveau WARN. Enregistrez uniquement lorsque la dernière tentative échoue, et non à chaque essai, afin d'éviter le bruit dans les journaux.

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>5.0.0</version>
</dependency>

Instance standard ou cluster en mode proxy (JedisPool)

Pour les instances standard ou les clusters en mode proxy, utilisez PooledConnectionProvider avec UnifiedJedis.

L'exemple suivant relance la commande SET jusqu'à 5 fois en 10 secondes à l'aide d'un backoff exponentiel. Si toutes les tentatives échouent, une exception est levée.

PooledConnectionProvider provider = new PooledConnectionProvider(HostAndPort.from("127.0.0.1:6379"));
int maxAttempts = 5; // Maximum number of retries
Duration maxTotalRetriesDuration = Duration.ofSeconds(10); // Maximum total retry duration
UnifiedJedis jedis = new UnifiedJedis(provider, maxAttempts, maxTotalRetriesDuration);
try {
    System.out.println("set key: " + jedis.set("key", "value"));
} catch (Exception e) {
    // The operation failed after maxAttempts retries or after maxTotalRetriesDuration elapsed.
    e.printStackTrace();
}

Cluster en mode de connexion directe (JedisCluster)

Pour les clusters en mode de connexion directe, utilisez JedisCluster. Le paramètre maxAttempts définit le nombre maximal de tentatives et sa valeur par défaut est 5. Une exception est levée si toutes les tentatives échouent.

HostAndPort hostAndPort = HostAndPort.from("127.0.0.1:30001");
int connectionTimeout = 5000;
int soTimeout = 2000;
int maxAttempts = 5;
ConnectionPoolConfig config = new ConnectionPoolConfig();
JedisCluster jedisCluster = new JedisCluster(hostAndPort, connectionTimeout, soTimeout, maxAttempts, config);
try {
    System.out.println("set key: " + jedisCluster.set("key", "value"));
} catch (Exception e) {
    // The operation failed after maxAttempts retries.
    e.printStackTrace();
}

Config config = new Config();
config.useSingleServer()
    .setTimeout(1000)
    .setRetryAttempts(3)
    .setRetryInterval(1500) // ms
    .setAddress("redis://127.0.0.1:6379");
RedissonClient connect = Redisson.create(config);

var conn = ConnectionMultiplexer.Connect("redis0:6380,redis1:6380,connectRetry=3");

clientOptions.isAutoReconnect() ? Reliability.AT_LEAST_ONCE : Reliability.AT_MOST_ONCE;