Un verrou Redis plus efficace

Dev
1

Discourse utilise largement les verrous Redis comme mécanisme de synchronisation. L’implémentation des verrous Redis de Discourse (comme illustré ci-dessous) pourrait être améliorée en réduisant le nombre de commandes Redis, diminuant ainsi le temps d’aller-retour et le coût d’exécution pour Redis.

Comment nous pourrions l’améliorer

Les fonctions lock et unlock utilisent toutes deux les transactions Redis. Le processus de lock pourrait être simplifié comme suit :

WATCH key
GET key # Déterminer si la clé a expiré
MULTI
SET key
EXPIRE key, expire_time + 1

La raison d’utiliser une transaction Redis (selon mon hypothèse) semble être de vérifier si la clé a expiré avant de réellement la définir.

Cependant, je pense que nous pourrions simplement utiliser la commande SETEX fournie par Redis, qui définit une clé avec un temps d’expiration. En fait, la documentation Redis SETEX l’utilise comme exemple pour remplacer SET & EXPIRE par SETEX.

Voici les arguments pour justifier ce remplacement :

  1. Définir la valeur comme étant le temps d’expiration et la vérifier avant de définir la clé est inutile. Le mécanisme TTL suffit à garantir que la clé expire correctement.
  2. Même si nous décidons d’utiliser le temps d’expiration comme valeur, aucune transaction n’est nécessaire. Puisque fournir une atomicité entre le GET (ligne 2 du code ci-dessus) et MULTI & EXEC n’apporte rien. En effet, si le verrou n’est pas acquis, une nouvelle tentative sera effectuée.

Note historique

J’ai examiné l’historique des commits Git pour obtenir plus d’informations. Il semble que lorsque le verrou Redis a été introduit, nous n’utilisions pas le TTL fourni par Redis. La fonctionnalité TTL a été introduite bien plus tard.

Je pense donc que nous pourrions aller encore plus loin et supprimer complètement les transactions Redis.

2

Selon Develop with Redis | Docs

Nous pouvons probablement abandonner toute la transaction et effectuer un set avec les options px et nx