本文介绍了如何使用Redis创建分布式锁?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在redis文档中,我发现可以通过SETNX实现基本锁:

On the redis documentation, I found a primitive lock can be implemented via SETNX:

http://redis.io/commands/setnx

崩溃的客户端C3仍然保留它,因此Redis将以0答复C4.

The crashed client C3 still holds it, so Redis will reply with 0 to C4.

C4发送GET lock.foo以检查锁是否过期.如果不是,它将休眠一段时间并从头开始重试.

C4 sends GET lock.foo to check if the lock expired. If it is not, it will sleep for some time and retry from the start.

相反,如果由于在lock.foo上的Unix时间早于当前的Unix时间而使锁过期,则C4尝试执行:

Instead, if the lock is expired because the Unix time at lock.foo is older than the current Unix time, C4 tries to perform:

  • 由于GETSET语义,C4可以检查存储在key上的旧值是否仍然是过期的时间戳.如果是,则已获取锁定.

  • Because of the GETSET semantic, C4 can check if the old value stored at key is still an expired timestamp. If it is, the lock was acquired.

    如果另一个客户端(例如C5)比C4快,并通过GETSET操作获得了锁定,则C4 GETSET操作将返回未过期的时间戳. C4将仅从第一步重新启动.请注意,即使C4在将来几秒钟设置了密钥,这也不成问题.

    If another client, for instance C5, was faster than C4 and acquired the lock with the GETSET operation, the C4 GETSET operation will return a non expired timestamp. C4 will simply restart from the first step. Note that even if C4 set the key a bit a few seconds in the future this is not a problem.

    但是,正如某些用户所评论的那样,使用UNIX时间戳作为到期时间要求客户机和服务器的时间完全同步.有没有更好的选择来在Redis中创建全局/分布式锁?

    However, as some users commented, using a UNIX timestamp as the expiration requires the client 's and server's time to be perfectly synchronized. Is there a better alternative to create a global/distributed lock in Redis?

    推荐答案

    使用SET代替SETNX. SET接受以秒和毫秒为单位的有效时间参数,而不是UNIX时间戳值.

    Use SET instead of SETNX. SET accepts arguments for expiration time in seconds and milliseconds instead of UNIX timestamp value.

    仅出于历史原因记录了基于SETNX的旧模式.

    The old SETNX based pattern is documented only for historical reasons.

    来自SETNX 说明:

    这篇关于如何使用Redis创建分布式锁?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

  • 08-07 03:32