Explication détaillée de l'implémentation du verrouillage distribué dans Redis

Les tâches planifiées que nous utilisions auparavant n'étaient déployées que sur une seule machine. Afin de résoudre le problème du point unique et de garantir qu'une tâche n'est exécutée que par une seule machine, nous devons considérer le problème de verrouillage, nous y consacrons donc du temps. étudié cette question. Comment implémenter un verrou distribué ? Cet article présente principalement des exemples de méthodes d'implémentation des verrous distribués dans Redis. L'éditeur pense que c'est plutôt bon. Maintenant, je vais le partager avec vous et vous donner une référence, j'espère que cela pourra vous aider.

L'essence des verrous est l'exclusion mutuelle, qui garantit qu'un client peut détenir le même verrou à tout moment. Si vous envisagez d'utiliser Redis pour implémenter un verrou distribué, la solution la plus simple consiste à créer une valeur de clé dans le fichier. exemple, lorsque le verrou est libéré, la valeur de la clé est supprimée. Cependant, un verrou distribué fiable et complet nécessite la prise en compte de nombreux détails. Voyons comment écrire un verrou distribué correct.

Verrou distribué autonome SETNX

Nous implémentons donc un verrou simple directement basé sur la commande setNX (SET if Not eXists) de redis. Accédez directement au pseudo code

Acquisition du verrou :

SET resource_name my_random_value NX PX 30000

Déverrouillage :

 if redis.call("get",KEYS[1]) == ARGV[1] then
  return redis.call("del",KEYS[1])
 else
  return 0
 end

Quelques détails doivent être notés :

Tout d'abord, nous devons définir le délai d'attente lors de l'acquisition du verrou. Le délai d'attente est défini pour empêcher le client de planter ou le verrouillage d'être maintenu après un problème de réseau. Tout le système est dans l’impasse.

Utilisez la commande setNX pour vous assurer que les étapes de requête et d'écriture sont atomiques

Lorsque le verrou est libéré, on juge que KEYS[1]) == ARGV[1], ici KEYS [ 1] est la valeur extraite de redis et ARGV[1] est la my_random_value générée ci-dessus. La raison du jugement ci-dessus est de garantir que le verrou est libéré par le titulaire verrouillé. Nous supposons que cette étape de vérification n'est pas effectuée :

1. Le client A acquiert le verrou et le thread suivant se bloque. Le délai est supérieur au délai d'expiration du verrou.

2. Après l'expiration du verrou, le client B acquiert le verrou.

3. Une fois que le client A a récupéré, après avoir traité les événements liés, il initie une commande del vers redis. Le verrou est libéré

4. Le client C acquiert le verrou. À l’heure actuelle, deux clients d’un système détiennent des verrous en même temps.

La clé de ce problème est que le verrou détenu par le client B est libéré par le client A.

Le verrou doit être libéré à l'aide d'un script Lua pour garantir l'atomicité de l'opération. La libération du verrou comprend trois étapes : obtenir, juger et supprimer. Si l’atomicité des trois étapes ne peut être garantie, les verrous distribués auront des problèmes de concurrence.

Après avoir prêté attention aux détails ci-dessus, un verrouillage distribué d'un seul nœud Redis est obtenu.

Il y a encore un seul point de Redis dans ce verrou distribué. Peut-être direz-vous que Redis a une architecture maître-esclave. En cas de panne, passez simplement à l'esclave, mais la réplication Redis est asynchrone.

1. Si le client A obtient le verrouillage sur le maître.

2. Avant que le maître ne synchronise les données avec l'esclave, le maître tombe en panne.

3. Le client B récupère à nouveau le verrou de l'esclave.

De cette façon, en raison du temps d'arrêt du Maître, plusieurs personnes détiennent la serrure en même temps. Si votre système peut accepter que plusieurs personnes détiennent le verrou pendant une courte période. Cette solution simple résoudra le problème.

Mais si ce problème est résolu. Redis fournit officiellement une solution Redlock.

Implémentation de RedLock

Afin de résoudre le problème du point unique Redis. L'auteur de Redis a proposé la solution de RedLock. Le plan est très intelligent et concis.
L'idée principale de RedLock est d'utiliser plusieurs maîtres Redis en même temps pour la redondance, et ces nœuds sont complètement indépendants et il n'est pas nécessaire de synchroniser les données entre ces nœuds.

Supposons que nous ayons N nœuds Redis, N doit être un nombre impair supérieur à 2. Étapes de mise en œuvre de RedLock :

1. Obtenir l'heure actuelle

2. Utilisez la méthode mentionnée ci-dessus pour obtenir les verrous Redis de N nœuds en séquence.

3. Si le nombre de verrous acquis est supérieur à (N/2+1) et que le temps d'acquisition est inférieur à la durée de validité du verrou (lock validate time), on considère qu'un un verrou valide a été acquis. Le temps de déverrouillage automatique est le temps de déverrouillage initial moins le temps passé avant l'acquisition du verrou.

4. Si le nombre de verrous acquis est inférieur à (N/2+1), ou si un nombre insuffisant de verrous sont acquis dans le délai de validité du verrou (durée de validité du verrou), on considère que l'acquisition la serrure a échoué. À ce stade, les messages de déverrouillage doivent être envoyés à tous les nœuds.

La mise en œuvre du déverrouillage est très simple. Lancez une opération de libération sur tous les nœuds Redis, que le verrou ait été acquis avec succès ou non auparavant.

En même temps, vous devez faire attention à plusieurs détails :

L'intervalle entre les tentatives d'acquisition du verrou doit être une plage aléatoire plutôt qu'une heure fixe. Cela peut empêcher plusieurs clients d'envoyer des opérations d'acquisition de verrous au cluster Redis en même temps et éviter une concurrence simultanée. Situation consistant à acquérir le même nombre de serrures en même temps. (Bien que la probabilité soit très faible)

Si un nœud maître tombe en panne, l'intervalle de temps de récupération doit être supérieur à la durée de validité du verrou.

1. Supposons qu'il y ait trois nœuds Redis A, B et C.

2. Le client foo acquiert deux verrous A et B.

3. À ce moment, B est en panne et toutes les données en mémoire sont perdues.

4. Le nœud B répond.

5. A ce moment, la barre client réacquiert le verrou et acquiert deux nœuds, B et C.

6. À ce moment, deux autres clients ont obtenu le cadenas.

Ainsi, si le temps de récupération est supérieur au temps effectif du verrouillage, la situation ci-dessus peut être évitée. Dans le même temps, si les exigences de performances ne sont pas élevées, vous pouvez même activer l'option de persistance de Redis.

Résumé

Après avoir compris la mise en œuvre de la distribution Redis, j'ai en fait l'impression que la plupart des systèmes distribués sont en fait très simples en principe, mais afin d'assurer la fiabilité du système distribué Il y a beaucoup de détails auxquels il faut prêter attention, triviaux et inhabituels.

Le verrouillage distribué implémenté par l'algorithme RedLock est simple et efficace, et l'idée est assez astucieuse.

Mais RedLock est-il nécessairement sûr ? J'écrirai également un article traitant de cette question. Veuillez rester à l'écoute.

Recommandations associées :

Explication détaillée du principe de la méthode de redisson d'implémentation des verrous distribués

Explication détaillée du verrouillage distribué php redis et Exemples de code de file d'attente de tâches

Plusieurs méthodes d'implémentation de verrous distribués

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!