Redis is an open source key-value database that is currently popular. At present, the back-end architecture of the core is in the form of Redis and MySQL in the database layer, where Redis is primarily used to store state information (such as the current seed peer) and read-write data frequently. Redis runs completely on top of memory with no lock design, very fast! Through the measurement, the read/write speed on the core server reaches 30,000/s.
In highly concurrent applications, there are times when we need to compete for certain resources, such as when many people download a hot resource, there may be a lot of requests to modify peer information for a resource (that is, the IP address and port number of the current insured person is saved), It is necessary to ensure that a request modifies peer information, no other requests are allowed to change, otherwise there will be data coverage issues. But Redis does not provide a lock on the data, so we need to implement it ourselves through the commands provided by Redis:
idea one: implemented by get and set commands It is easy to think of this, that is, when each request arrives, it is determined if the lock exists, and if it does not exist, set is created. This method has a disadvantage, because get and set is two Redis request, there is a delay between the two, in a high concurrency environment, it is possible to get detected after the lock is not saved before the set is set by another thread, then the current thread is set, so that the lock is invalid. So this approach can only deal with situations where concurrency is not very high.
train of thought two: through setnx and expire command realization When accessing a resource that requires mutually exclusive access, a lock key is set by the Setnx command, and SETNX determines whether the lock exists, creates it if it does not exist, returns success if it exists, and returns the server to the client, instructing the client to retry later. The expire command is used to set an expiration time for the lock, which prevents the thread from crash, causing the lock to remain valid, resulting in a deadlock. For example: The set lock is valid for 100 seconds, so the lock will automatically fail after 100 seconds even if the line Cheng.
SETNX Lock "Lock"
set the expiration time if successful
Expire Lock 100
Delete lock after access to mutex resource ends
Del Lock
idea three: using watch and Redis to implement the transaction commandsthe effect of this approach is similar to the idea of two. The lock's key value uniquely identifies the change request (for example, time + user ID) when the request is made to watch the resource lock and then through the process of creating the lock in the transaction execution. If there are other threads currently requesting the resource, it will return an error retry if the lock is determined to exist (such as the "server overload, auto-retry" hint of the tracker return). If there are multiple requests at the same time to determine that the lock does not exist and create the lock, it will also be due to watch the lock, causing the previous watch thread to perform a transaction failure, return the client automatically retry. So that the ultimate goal of achieving the lock.
Brief analysis on Redis implementing lock mutex Access resource
