Exemple d'analyse du verrouillage distribué Redlock dans Redis

Bibliothèque d'implémentation Redlock

• Java Redisson Star 9458

• Bien que l'algorithme derrière soit le même, mais ceci bravo Les chiffres sont effectivement convaincants.

• Verrouillage Redis à point unique

Tout d'abord, examinons brièvement comment le verrouillage Redis à point unique est implémenté.

Obtenez le verrou

SET resource_name my_random_value NX PX 30000

Le client A utilise Redis pour définir une paire clé-valeur et spécifier un délai d'attente pour éviter une impasse. Lorsque d'autres clients accèdent, ils vérifient d'abord si la clé existe déjà et si sa valeur est "my_random_value". S'il existe, attendez, sinon il réussira et exécutera le code métier. Les objets partagés et connus de tous les clients incluent resource_name et my_random_value.

Release lock

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

Comparez si les valeurs correspondantes obtenues par la clé sont égales, supprimez (libérez), sinon cela renverra un échec.

Faille de verrouillage Redis en un seul point

Lorsqu'il n'y a qu'une seule instance Redis, une panne entraînera l'effondrement de tous les services qui en dépendent. Cette faille est extrêmement évidente. Ne convient évidemment pas aux grandes applications.

Problèmes rencontrés par l'architecture maître-esclave Redis simple

Afin d'éviter les points de défaillance uniques, nous construisons une architecture maître/esclave maître/esclave pour Redis, avec un maître et un esclave. Vous rencontrerez un tel problème ci-dessous. Voici des scénarios d'utilisation.

Le Client A acquiert un verrou sur le Maître.

Master a planté lors de la synchronisation de ces données avec Slave (car la synchronisation entre Master et Slave est asynchrone).

1. L'esclave devient Maître.

2. Le client B obtient le verrou via la même clé et la même valeur. Échec du verrouillage distribué

3. Algorithme Redlock

4. Supposons que nous ayons N (en supposant 5) instances maîtres Redis, tous les nœuds sont indépendants les uns des autres, et le système métier est simplement appelé, et il n'y a pas d'autres retransmissions de messages similaires. système auxiliaire. Simulons l'algorithme ci-dessous :

1. Le client obtient l'heure actuelle t0 du serveur, en millisecondes.

Acquérir des serrures en utilisant la même clé et la même valeur dans 5 instances. Lors de l’acquisition d’un verrou professionnel, le client définira un délai d’attente bien inférieur au temps requis pour le verrou professionnel. Par exemple, en supposant que le verrouillage prenne 10 secondes, vous pouvez définir le délai d'attente entre 5 et 50 millisecondes. Phrase réécrite : Afin d'éviter la situation dans laquelle Redis échoue lorsque le client tente d'acquérir le verrou, des mesures doivent être prises. Après l'expiration du délai, passez directement au nœud suivant. 3. Le client soustrait t0 de l'heure actuelle (t1) pour calculer le temps t2 (=t1-t0) mis pour acquérir le verrou. Ce n'est que lorsque t2 est inférieur à la durée de validité commerciale du verrou (c'est-à-dire 10 secondes dans la deuxième étape) et que le client acquiert le verrou sur au moins 3 (5/2+1) plates-formes que nous considérerons l'acquisition du verrou. réussi.

4. Si la serrure a été acquise, la durée de validité commerciale de la serrure est de 10s-t2.

5. Si le client n'acquiert pas le verrou, il se peut que le verrou ne soit pas acquis sur plus ou égal à N/2+1 instances, ou que le temps effectif (10s-t2) soit un nombre négatif, on essaiera de libérer le verrou, même s'il n'est pas obtenu sur ce nœud.

Déverrouillage du verrouillage

Le déverrouillage est relativement simple, il suffit de supprimer les clés correspondantes sur toutes les instances.

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!