Redis implements distributed lock
1. Perform setnx according to the lockKey area (set not exist, if the key value is empty, set it normally and return 1, otherwise it will not be set And return 0) operation, if the setting is successful, it means that the lock has been obtained, otherwise the lock has not been obtained.
2. If the lock is not obtained, go to Redis to get the value corresponding to the key. We store a timestamp (expressed in milliseconds, t1) on the key. In order to avoid deadlock and other clients occupying the lock for more than a certain time (5 seconds), the current timestamp of the client is used and compared with the stored timestamp. (Recommended learning: Redis Video Tutorial)
3. If the usage time limit of the key has not been exceeded, return false, indicating that other people are occupying the key and cannot be forced to use it; if the time limit has been exceeded, , then we can unlock it and use our timestamp to replace the value of this field.
4. However, if the get value cannot be obtained after setnx fails, it means that the lock has been released before the operation. At this time, the best way is to re-execute the setnx method to obtain it. Its value is used to obtain the lock.
Release lock: delete key in redis
Zookeeper implements distributed lock
Based on temporary sequential nodes:
1. Customer The end calls the create() method to create a node named "locknode/guid-lock-". It should be noted that the creation type of the node here needs to be set to EPHEMERAL_SEQUENTIAL.
2. The client calls the getChildren("locknode") method to obtain all created child nodes.
3. After the client obtains the paths of all child nodes, if it finds that the node it created in step 1 has the smallest sequence number among all nodes, then the client is considered to have obtained the lock.
4. If the created node does not have the smallest sequence number among all nodes, then the largest node with a smaller sequence number than the node you created will be monitored and wait. Until the next time the monitored child node changes, the child node will be acquired again to determine whether to acquire the lock.
The process of releasing the lock is relatively simple, just delete the child node you created.
Difference:
redis distributed lock, in fact, you need to constantly try to obtain the lock yourself, which consumes more performance
zk distributed lock, if you cannot obtain the lock, just register a listener. There is no need to constantly actively try to obtain the lock, and the performance overhead is small
Another point is that if it is redis If the client that acquires the lock is buggy or hangs up, the lock can only be released after waiting for the timeout period; as for zk, because it creates a temporary znode, as long as the client hangs up, the znode will be gone and it will be automatically released at this time. Lock
For more Redis-related technical articles, please visit the Redis database usage tutorial column to learn!
The above is the detailed content of The difference between zk and redis distributed locks. For more information, please follow other related articles on the PHP Chinese website!