Many libraries use Redis for distributed locking, but some of these good libraries haven’t considered all of the pitfalls that may arise in a distributed …
Join the DZone community and get the full member experience. There are several resources in a system that mustn’t be used simultaneously by multiple processes if the program operation must be correct. For example, a file mustn’t be simultaneously updated by multiple processes or the use of printers must be restricted to a single process simultaneously. Therefore, exclusive access to such a shared resource by a process must be ensured. This exclusiveness of access is called mutual exclusion between processes. The sections of a program that need exclusive access to shared resources are referred to as critical sections. Solutions are needed to grant mutual exclusive access by processes. We can use distributed locking for mutually exclusive access to resources. A distributed lock service should satisfy the following properties: Mutual exclusion: Only one client can hold a lock at a given moment. This is an essential property of a distributed lock. Deadlock free: Every request for a lock must be eventually granted; even clients that hold the lock crash or encounter an exception. Many distributed lock implementations are based on the distributed consensus algorithms (Paxos, Raft, ZAB, Pacifica) like Chubby based on Paxos, Zookeeper based on ZAB, etc., based on Raft, and Consul based on Raft. There is also a proposed distributed lock by Redis creator named RedLock. Many libraries use Redis for distributed locking, but some of these good libraries haven’t considered all of the pitfalls that may arise in a distributed environment. In the following section, I show how to implement a distributed lock step by step based on Redis, and at every step, I try to solve a problem that may happen in a distributed system. Please note that I used a leased-based lock, which means we set a key in Redis with an expiration time (leased-time); after that, the key will automatically be removed, and the lock will be free, provided that the client doesn’t refresh the lock. Complete source code is available on the GitHub repository: https://github.com/siahsang/red-utils For simplicity, assume we have two clients and only one Redis instance. A plain implementation would be: But what is wrong with that? Suppose the first client requests to get a lock, but the server response is longer than the lease time; as a result, the client uses the expired key, and at the same time, another client could get the same key, now both of them have the same key simultaneously! It violet the mutual exclusion. The following diagram illustrates this situation: To solve this problem, we can set a timeout for Redis clients, and it should be less than the lease time.
