Teach you how to correctly use Redis's SETNX to implement the lock mechanism

The following column of Redis Tutorial will introduce to you the correct use of Redis’s SETNX to implement the lock mechanism. I hope it will be helpful to friends in need!

setNX is the abbreviation of set if not exists, that is, it is set only when it does not exist. It returns 1 when the setting is successful and 0 when the setting fails. It can be used to achieve the lock effect, but many people have some problems that they do not consider during use.

For example, a certain interface for querying the database adds a cache because of a relatively large number of requests, and sets it to refresh after the cache expires. When the amount of concurrency is relatively large and the cache expires, a large number of concurrent requests will directly query the database, causing an avalanche. The avalanche problem can be avoided if a locking mechanism is used to control only one request to update the cache. The following is a locking method that many people subconsciously think of

$rs = $redis->setNX($key, $value);
if ($rs) {
    //处理更新缓存逻辑
    // ......
    //删除锁
    $redis->del($key);
}

Get the lock through setNX. If successful, update the cache and then delete the lock. In fact, there is a serious problem here: if the cache exits unexpectedly for some reason, the lock will not be deleted and will always exist, so that the cache will never be updated. In order to solve this problem, some people may think of setting an expiration time for the lock, as follows

$redis->multi();
$redis->setNX($key, $value);
$redis->expire($key, $ttl);
$redis->exec();

Because setNX does not have the function of setting the expiration time, it needs to use Expire to set it, and Multi/Exec needs to be used to ensure that the requested Atomicity to prevent setNX from succeeding but failing to Expire. There is still a problem with this: when multiple requests arrive, although only one request's setNX can succeed, any request's Expire can succeed. This means that even if the lock cannot be obtained, the expiration time can be refreshed, causing the lock to remain locked. It's effective, but it still doesn't solve the above problem. Obviously setNX cannot meet the demand. Starting from Redis 2.6.12, SET covers the functions of SETEX. SET itself also includes the function of setting the expiration time, so using SET can solve the problems encountered above.

$rs = $redis->set($key, $value, array('nx', 'ex' => $ttl));
if ($rs) {
    //处理更新缓存逻辑
    // ......
    //删除锁
    $redis->del($key);
}

This step is actually problematic. If a request takes longer to update the cache than the validity period of the lock, causing the lock to become invalid during the cache update process, another request will acquire the lock, but the previous request will When the cache update is completed, if you delete the lock directly, you may accidentally delete the lock created by other requests. So to avoid this problem, you can introduce a random value when creating the lock and judge it when deleting the lock

$rs = $redis->set($key, $random, array('nx', 'ex' => $ttl));
if ($rs) {
     //处理更新缓存逻辑
    // ......
    //先判断随机数，是同一个则删除锁
    if ($redis->get($key) == $random) {
        $redis->del($key);
    }
}

The above is the detailed content of Teach you how to correctly use Redis's SETNX to implement the lock mechanism. For more information, please follow other related articles on the PHP Chinese website!