Shulou(Shulou.com)06/01 Report--

What this article shares to you is the relevant knowledge about redis distributed locks, the editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

There are generally three ways to implement distributed locks: 1. Database optimistic lock; 2. Distributed lock based on Redis; 3. Distributed locks based on ZooKeeper.

This paper introduces the implementation of distributed locks based on Redis.

The nature of distributed locks:

Reliability. First, to ensure that distributed locks are available, we need to ensure that the implementation of the lock meets at least the following four conditions:

Repulsion. At any given time, only one client can hold the lock.

There is no deadlock. Even if one client crashes while holding the lock without actively unlocking it, it is guaranteed that other clients will be able to lock it.

It is fault tolerant. As long as most of the Redis nodes are functioning properly, the client can lock and unlock.

The person who unlocks the bell must also tie the bell. Locking and unlocking must be the same client, and the client cannot unlock the lock added by others.

The code implements the component dependency

First, we will introduce the Jedis open source component through Maven and add the following code to the pom.xml file:

Redis.clients jedis 2.9.0

Lock code correct posture

Talk is cheap, show me the code . First show the code, and then slowly explain why it is implemented this way:

Public class RedisTool {private static final String LOCK_SUCCESS = "OK"; private static final String SET_IF_NOT_EXIST = "NX"; private static final String SET_WITH_EXPIRE_TIME = "PX" / * attempt to acquire distributed lock * @ param jedis Redis client * @ param lockKey lock * @ param requestId request identification * @ param expireTime timeout * @ return whether to obtain successful * / public static boolean tryGetDistributedLock (Jedis jedis, String lockKey, String requestId, int expireTime) {String result = jedis.set (lockKey, requestId, SET_IF_NOT_EXIST) SET_WITH_EXPIRE_TIME, expireTime) If (LOCK_SUCCESS.equals (result)) {return true;} return false;}}

As you can see, we lock on one line of code: jedis.set (String key, String value, String nxxx, String expx, int time). This set () method has a total of five formal parameters:

The first is key, and we use key as the lock because key is unique.

The second is value, we pass is requestId, many children's shoes may not understand, there is key as a lock is not enough, why do you still use value? The reason is that when we talk about reliability above, if the distributed lock meets the fourth condition, the value must also be tied. By assigning the value of requestId to the lock, we will know which request added the lock, and can have a basis when unlocking it. RequestId can be generated using the UUID.randomUUID (). ToString () method.

The third is nxxx. This parameter we fill in is NX, which means SET IF NOT EXIST, that is, when key does not exist, we perform set operation; if key already exists, we do nothing.

The fourth is expx, this parameter we pass is PX, which means that we want to add an expired setting to the key, the specific time is determined by the fifth parameter.

The fifth is time, which corresponds to the fourth parameter and represents the expiration time of the key.

In general, executing the above set () method results in only two results: 1. There is currently no lock (key does not exist), then the lock operation is performed and the lock is valid, and value represents the locked client. two。 There is already a lock and no action is done.

Our locking code meets the three conditions described in our reliability. First of all, set () adds a NX parameter to ensure that if key already exists, the function will not be called successfully, that is, only one client can hold the lock, which satisfies the mutex. Second, because we set the expiration time for the lock, even if the holder of the lock crashes and does not unlock the lock, the lock will be automatically unlocked (that is, the key will be deleted) without deadlock. Finally, because we assign value to requestId, which represents the locked client request ID, the client can verify whether it is the same client when it is unlocked. Since we only consider the scenario of stand-alone deployment of Redis, we will not consider fault tolerance for the time being.

The above is the relevant knowledge of redis distributed locks, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.