Comment créer un verrou distribué avec Redis?

Sur le redis documentation, j'ai trouvé une primitive de verrouillage peuvent être mises en œuvre via SETNX:

http://redis.io/commands/setnx

  • C4 envoie SETNX de verrouillage.foo afin d'acquérir le verrou
  • S'est écrasé le client C3 tient toujours, alors Redis répondrons avec 0 à C4.
  • C4 envoie OBTENIR un verrou.foo pour vérifier si la serrure est expiré. Si elle ne l'est pas, il va dormir pendant un certain temps et recommencez depuis le début.
  • Au lieu de cela, si le verrou est expiré parce que le temps Unix à l'écluse.toto est plus vieux que le temps Unix courant, C4 tente d'effectuer:

    GETSET de verrouillage.foo

  • En raison de la GETSET sémantique, C4 pouvez vérifier si la vieille valeur stockée à clé est toujours une estampille expiré. Si elle l'est, la serrure a été acquis.
  • Si un autre client, par exemple C5, a été plus rapide que le C4 et les acquis de la serrure avec la GETSET opération, la C4 GETSET opération sera de retour non expiré timestamp. C4 simplement redémarrer à partir de la première étape. Notez que même si C4 mis la clé un peu quelques secondes dans l'avenir, ce n'est pas un problème.

Cependant, certains utilisateurs ont estimé, à l'aide d'un timestamp UNIX de l'expiration, le client et le serveur est temps d'être parfaitement synchronisés. Est-il une meilleure alternative à la création d'un mondial et de la distribution de verrouillage dans le Redis?

source d'informationauteur dyip1 | 2013-12-23

  1. 11

    Utilisation SET au lieu de SETNX. SET accepte les arguments pour la date d'expiration en secondes et millisecondes au lieu de timestamp UNIX de valeur.

    L'ancien SETNX à base de modèle est documentée que pour des raisons historiques.

    De SETNX description:

    REMARQUE: à Partir de Redis 2.6.12 il est possible de créer un beaucoup
    plus simple de verrouillage primitive à l'aide de la commande SET pour acquérir le verrou,
    et un simple script Lua pour libérer le verrou. Le modèle est documenté
    dans l'ENSEMBLE de commande de la page.

  2. 8

    À l'aide de redis >= 2.6 script LUA solution serait génial. Script Lua toujours exécuté automatiquement si:

    --lockscript, parameters: lock_key, lock_timeout
local lock = redis.call('get', KEYS[1])
if not lock then    
    return redis.call('setex', KEYS[1], ARGV[1], "locked");
end
return false

    L'autre solution basée sur de nouvelles options de SET commande

    SET lock_key "locked" EX lock_timeout NX

    À l'aide de redis < 2.6 le modèle avec le multi peut être utilisé:

    MULTI
SETNX tmp_unique_lock some_value
EXPIRE tmp_unique_lock
RENAMENX tmp_unique_lock real_lock
EXEC
  3. 3

    suivez le lien

    beau projet en expliquant verrouillage

    http://redis.io/topics/distlock

    https://github.com/mrniko/redisson

  4. 1

    Nouveaux arguments pour ENSEMBLE sont assez pour régler le verrouillage de l', mais elles ne fonctionnent que sur le Redis >= v2.6.12 vous avez également besoin de penser à la façon dont la serrure est unset et expirer etc.

    J'ai écrit un post sur notre Ingénierie blog sur distribué des verrous à l'aide Redis. Il couvre un script sur la façon de définir et de libérer le verrou de manière fiable, la validation et de l'impasse de la prévention. J'ai également inclure un module écrit en Node.js vous pouvez l'utiliser pour verrouiller tout droit sorti de la boîte.

  5. 1

    Je gem ed les SET EX NX solution misterion mentionné dans un endroit frais gem - simple_redis_lock

    Le code est simple et ressemble à ceci:

    def lock(key, timeout)
  if @redis.set(key, Time.now, nx: true, px: timeout)
    begin
      yield
    ensure
      release key
    end
  end
end
  6. 1

    Bon article sur les verrous avec Redis: "Comment faire distribué de verrouillage".

    Je pense que le Redlock algorithme est un mauvais choix, car il n'est “ni poisson, ni volaille”: elle est inutilement lourd et coûteux pour l'efficacité de l'optimisation des serrures, mais il n'est pas suffisamment sûr pour les situations dans lesquelles l'exactitude dépend de la serrure.

    En particulier, l'algorithme rend dangereux hypothèses sur les délais et les horloges système (essentiellement en supposant un système synchrone avec délimitée retard de réseau et délimitée temps d'exécution pour les opérations), et il viole les propriétés de sécurité si ces hypothèses ne sont pas respectées. En outre, il manque une installation pour produire de l'escrime jetons (ce qui protéger un système contre de longs retards dans le réseau ou en pause).

    Taooka résoudre tous les problèmes décrits. Il isole cassé clients et nul ne peut obtenir un verrou jusqu'à ce que le cassé client a accès à la modification des données.