“This is the 18th day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021”

First, Java implementation of Redlock algorithm Redisson

Most current implementations of distributed locks based on Redisde have the problems described in the previous section. The above example is sufficient if you are using a single Redis, but generally when using Redis, in order to ensure the availability of Redis is generally used Redis cluster.

Redis distributed lock in Redis distributed lock in Redis distributed lock in Redis distributed lock in Redis distributed lock in Redis distributed lock

Second, The design philosophy of RedLock

2.1 Problems caused by Redis cluster AP

Distributed problem, we have to say about CAP theory: C consistency, A availability, P partition fault tolerance. Generally distributed system design is either AP or CP, while Redis cluster is CP. After data is written to the Master node of Redis, it will be synchronized to the Slave node through asynchronous replication. In this process, Redis cluster still provides services to the outside.

At this time, if the Master node fails to synchronize the Key that was just written into Redis to the Slave node, then the Slave node is upgraded to the Master node, and the Key fails to synchronize, the lock will be lost.

2.2 Design Concept

The scheme is also based on set command shackles and Lua script implementation. Suppose there are N Redis nodes, such as N=5, these nodes are completely independent, we do not apply to replication or any coordination system, the client to obtain the lock steps are as follows:

  1. Gets the current time in milliseconds.

  2. Try, in turn, to obtain the lock from each of the five instances using the same key and random value. When requesting a lock from Redis, the client should set a timeout period that is less than the lock expiration time. For example, if the automatic invalidation time of a lock is 10 seconds, the timeout period must be between 5 and 50 milliseconds. This prevents clients from being blocked for long periods of time while trying to talk to an immediate Redis node. If an instance is unavailable, the client should try to request a lock from another Redis instance as soon as possible.

  3. The client calculates the lock usage time by subtracting the time recorded in Step 1 from the current time. The lock is successful if and only if the lock is obtained from most of the Redis nodes (N/2+1, here 3 nodes) and the time taken to acquire the lock is less than the lock expiration time.

  4. If a lock is obtained, its true validity time is equal to the initial validity time minus the time used to obtain the lock (calculated in Step 3).

  5. If a lock is not acquired for some reason (the lock cannot be acquired for at least N/2 + 1 Redis instances, or the lock is acquired for longer than the valid time), the client should unlock all Redis instances (even if some Redis instances are not locked at all). Prevents some node from acquiring the lock but the client does not get the response so that the lock cannot be reacquired for a later period of time.

In order to solve the problem of data inconsistency, this solution directly abandons the use of only Master nodes for asynchronous replication, and abandons Slave nodes to ensure availability. The official recommendation is 5.

The client is considered to be locked successfully only when the following two conditions are met: Condition 1: The client successfully obtained the lock from more than half of the Redis instances (greater than or equal to N/2+1); Condition 2: The total time it takes for a client to obtain a lock does not exceed the lock validity period.

2.3 Solutions

Because Redis cluster only supports AP, N nodes are used to solve the risk of consistency. N is an odd number, and N Master nodes are independent of each other rather than each other’s Master nodes or clusters. N=2X+1, where N is the number of Redis nodes finally deployed, and X is the number of fault-tolerant machines.

Why tolerance?

How many machine instances failed, I can still tolerate, the so-called tolerance is the data consistency is Ok, CP data consistency can still be satisfied:

  1. Join in the cluster environment, 1 Redis failed, acceptable. 2X+1 = 2 * 1+1 =3, deploy 3, 1 dead, 2 working, then deploy 3.

  2. Join in the cluster environment, 2 Redis failed, acceptable. 2X+1 = 2 * 2+1 =5, deploy 5, 2 dead and 3 working, then deploy 5.

Why is N odd?

The least machine, the most output:

  1. Join in the cluster environment, 1 Redis failed, acceptable. 2N+2= 2 x 1+2 =4. Deploy four NODES
  2. Join in the cluster environment, 2 Redis failed, acceptable. 2N+2 = 2 x 2+2 =6. Deploy six PCS

Iii. Summary and notice

Distributed lock is the most commonly used distributed technology, among which there are a lot of implementation, here through two articles described in detail the advantages and disadvantages and existing problems.

The stand-alone version of Redis has been in line with the use of small and medium-sized systems, large distributed systems, can not only rely on a Redis instance support, must be on the distributed cluster or master and slave architecture, Redis distributed cluster is more commonly used is three master and three slave, master and slave structure one master and more from the specific system, one introduction of Redis cluster, Then there’s the problem of consistency. IO /topics/dist…

As described in this video, joining the Redis cluster environment requires the deployment of N independent Master Redis instances, plus the Slave nodes in the cluster where each Master node resides, and many Redis instances need to be deployed. Whether to use Red Lock depends on their own choice or their own better method.

Here about Redis distributed lock here, after will write about cluster version Redis distributed lock real operation!