Analysis on Redis implementing lock mutex resource access and redislock mutex

Analysis on Redis implementing lock mutex resource access and redislock mutex
Redis is a popular open-source key-value database. At present, ruisi's background architecture adopts a combination of Redis and MySQL on the database layer. Redis is mainly used to store status information (such as the current seed peer) and read/write frequent data. Redis is fully running on the memory and has no lock design. It is very fast! According to the test, the read/write speed on the ruisi server reaches 30 thousand times/s.
In highly concurrent applications, we often need to compete for some resources, for example, when many people download a popular resource, there may be many requests to modify the peer information of a resource (that is, to save the IP address and port number of the current Spector). When a request needs to modify the peer information, other requests cannot be modified. Otherwise, data overwrites may occur. However, Redis does not provide data locking, so we need to use the commands provided by Redis to implement it ourselves:
Idea 1: Use get and set commandsThis method is easy to think of. When each request arrives, get is used to determine whether the lock exists. If it does not exist, set is created. This method has one drawback. Because get and set are two Redis requests, there is a latency between them. In a highly concurrent environment, it is possible that the lock has been set by another thread before the set after the get detects that the lock is not saved. Then, the current thread is set again, so that the lock will become invalid. Therefore, this method can only deal with a low concurrency.
Method 2: Use the setnx and expire commandsWhen you access resources that require mutual access, use the setnx command to set a lock key. setnx is used to determine whether the lock exists. If it does not exist, the lock is created and a success is returned, if yes, an error is returned. The server returns the error to the client and instructs the client to try again later. The expire command is used to set an expiration time for the lock, which is used to prevent the thread from crash, resulting in the lock being valid all the time, resulting in a deadlock. For example, if the lock validity period is set to 100 seconds, the lock will automatically expire after 100 seconds even if the thread crashes.

setnx lock "lock"

If yes, set the expiration time.

expire lock 100

After the mutex resource is accessed, delete the lock.

del lock

 
Thought 3: using the transaction commands of watch and RedisThe effect of this method is similar to that of idea 2. When the request arrives, watch and change the resource lock first. Then, by executing the lock creation process in the transaction, the lock key value can uniquely identify the request (for example, time + User ID ). If there are other threads requesting this resource, an error will be returned and re-tries will be returned when the lock is determined to exist (for example, ruisi BT tracker returns "server overload, this is the case when the "auto-retry" prompt is displayed ). If multiple requests judge that the modified lock does not exist and the lock is created at the same time, this will also cause the previous watch thread to fail to execute the transaction and return to the client for automatic retry. This eventually achieves the goal of locking.