# A proposal for more reliable locks using Redis

DevFeed: [A proposal for more reliable locks using Redis](<https://devfeed.tech/articles/a-proposal-for-more-reliable-locks-using-redis-20668.md>)

Original publisher: [Read original article](<http://antirez.com/news/77>)

Published: 2014-05-16T11:15:32Z

Content type: article

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [Algorithm](<https://devfeed.tech/topics/algorithm.md>), [Availability](<https://devfeed.tech/topics/availability.md>), [Deadlock](<https://devfeed.tech/topics/deadlock.md>), [servers](<https://devfeed.tech/topics/servers.md>)

Tags: [algorithm](<https://devfeed.tech/tags/algorithm.md>), [availability](<https://devfeed.tech/tags/availability.md>), [distributed](<https://devfeed.tech/tags/distributed.md>), [distributed-system](<https://devfeed.tech/tags/distributed-system.md>), [high-availability](<https://devfeed.tech/tags/high-availability.md>), [locks](<https://devfeed.tech/tags/locks.md>), [redis](<https://devfeed.tech/tags/redis.md>)

## AI overview

The article explores a proposal for implementing distributed locks with multiple Redis instances. It frames the design around safety and liveness requirements, including mutual exclusion, freedom from deadlocks, and continued lock availability despite failures or network partitions.

## Source excerpt

----------------- UPDATE: The algorithm is now described in the Redis documentation here => http://redis.io/topics/distlock. The article is left here in its older version, the updates will go into the Redis documentation instead. ----------------- Many people use Redis to implement distributed locks. Many believe that this is a great use case, and that Redis worked great to solve an otherwise hard to solve problem. Others believe that this is totally broken, unsafe, and wrong use case for Redis. Both are right, basically. Distributed locks are not trivial if we want them to be safe, and at the same time we demand high availability, so that Redis nodes can go down and still clients are able to acquire and release locks. At the same time a fast lock manager can solve tons of problems which are otherwise hard to solve in practice, and sometimes even a far from perfect solution is better than a very slow solution. Can we have a fast and reliable system at the same time based on Redis? This blog post is an exploration in this area. I'll try to describe a proposal for a simple algorithm to use N Redis instances for distributed and reliable locks, in the hope that the community may help me analyze and comment the algorithm to see if this is a valid candidate. # What we really want? Talking about a distributed system without stating the safety and liveness properties we want is mostly useless, because only when those two requirements are specified it is possible to check if a design is correct, and for people to analyze and find bugs in the design. We are going to model our design with just three properties, that are what I believe the minimum guarantees you need to use distributed locks in an effective way. 1) Safety property: Mutual exclusion. At any given moment, only one client can hold a lock. 2) Liveness property A: Deadlocks free. Eventually it is always possible to acquire a lock, even if the client that locked a resource crashed or gets partitioned. 3) Liveness pro