When distributed locking effect. When to use between different redis client, using a watch or lock, will depend on the performance of the system will cause losses to monitor when a key is frequently accessed using the watch command, you need to consider whether the locks.
Think about what issues there may be before lock design
We first need to understand the issues that may arise to use locks:
-
Process holding the lock, because the operation time is too long, which led to the lock is automatically released, but the process itself does not know the lock is released, and may even fall further erroneous release locks held by other processes.
-
And it intends to hold a lock for a long time to perform the operation process has collapsed, but other processes do not know which process is holding a lock can not detect the process holding the lock has collapsed.
-
In a process holding the lock expires after multiple processes at the same time to acquire the lock, and are given a lock.
-
Multiple processes to acquire the lock, and thought only you get to the lock.
redis can be executed on the latest hardware 100,000 operations per second, can perform 225,000 operations per second on high-end hardware, so the above problem in the case of high concurrent high load is entirely possible occur.
Design a simple lock v1.0
Correct locking
Use setnxthe command is a prerequisite to achieve this lock is achieved in the figure below. 获取锁Function:
How it works: When a key is not present, set a value for the key, otherwise attempt within a certain time.
Carefully release lock
When locked, the use
setnxof a key set uuid, the id can be released when the lock is used to monitor watch, if id does not change, only to release the lock, the same id can secure the release of the lock operation will not be repeated repeatedly
The following is a function to release the lock:
Instead of using locks and watch a performance comparison of both
The following code is redis in actiona book case, a consistency in the purchase of goods in the market to achieve, used here just to achieve a distributed lock design consistency problem:
In this code inside the lock name is
lock:market, so is not the only one lock, you can customize the N multiple locks and then the author gives a performance comparison based on business needs:
Since the introduction of the lock, each operation is actually
市场the object actually was locked, so we can see will be affected to some extent on the number of shelves of goods becomes less, but other aspects of the upgrade is still very obvious. the reason for this is加锁的粒度过大due to the whole market are locked, the impact will be relatively large. normally, when the shelves as long as it has nothing to do with the items you purchase, it should not be locked fishes.
Design a fine-grained lock v2.0
1.0 lock improvements, will reduce the size of the lock, the lock only to buy goods, so the competition for the lock on the decline, and then on the shelves of merchandise to enhance the performance of the entire system and thus will increase.
When using a fine-grained locks comparison 1.0 is as follows:
The book does not give 2.0 lock code, only the graph showing the performance of a plurality of N For fine-grained and coarse-grained selection, often it is determined according to the actual situation. Not necessarily fine-grained like.
Lock design with a timeout feature of v3.0
The above does not release the lock when the holder of a crash. This will result in a state of lock has been acquired. To solve this problem, we need to add a lock timeout function.
The time-out design is based on the following core principles:
-
setnx lock command after the assignment, to be used to lock add EXPIRE expiration time.
-
If a program crashes between setnx and expire (extreme case), other processes trying to acquire the lock, you need to check the remaining time to expiration of the lock, the lock does not expire if you find the time, you will need to re-add a lock expiration time. Although there there may be multiple clients simultaneously added to the lock expired time, but it will not be much difference between, so it can not be considered.
The following code is a function to acquire the lock after optimization:
Note: This code fragment relatively old, new redis is set nx and ex support options set the time, so the amount of code a lot less.
The number of client-side design a lock, you can restrict access to resources v4.0
Previous generations lock feature is that when the future of the resource lock, the lock can only be held by a client process to access the resource, the ability to design such a lock, allowing them access to the n-th process. This lock has a name is called
计数信号量.
Technical semaphore some contrast with the ordinary lock, then the normal client when applying for a lock if it fails, it will wait for some time continue to apply. If the client application when the semaphore failed, it returns the resource is busy information directly.
The book is also designed a scene:
Market access market is no longer limited to within the game, but the process can be used to access the external market, the same account can only process a maximum of five access.
Fair and unfair semaphore semaphore
Here is a concept related to the equity issue. The book gives design semaphore is an ordered collection, the process id as a member of an ordered set of id will be added to the timestamp as an ordered set of scores, each after adding a collection of processes, check their ranking, if more than 5, they prove that they have no right to acquire a semaphore, you need to remove yourself from this set, but using the timestamp value as a problem occurs, different hosts time may be different.
In order to avoid unfair phenomenon, usually in conjunction with a counter, and the counter value through a calculation algorithm as an ordered set of scores. But for 32-bit platforms redis server, counter prone to overflow. So for this situation, the role of the counter is not large.