Our last article about the Distributed Lock based redis single node, this single-node problem actually is quite large, if the redis server collapse out how to do it ? Entire business to cool it. So we generally need more redis server together distributed lock.
Algorithmic process
Suppose there are five main server completely independent redis
(1) Request for locking the client (say detailed point that thread also) to get timestamp of the current time.
There each client to each server also uses redis embodiment of a single node for locking.
(2) client in order to try to use the same key, value acquire all locks redis services, also said before, value is the thread id. Acquire a lock to set the lock time than the expiration of the time is much smaller, it is because if a redis server hung up, then the client also silly to wait, then it is a waste of time , generally sets a minimum waiting time, if more than this time, then give up, carried out under a redis server lock.
(3) client's time by subtracting the first step to get all the time after the lock can be acquired, this time difference is less than the TTL (Time expired) time and there are at least three examples of successful redis acquire the lock, the lock access to truly succeed . Because if the time difference is greater than the TTL, then the first set of locks redis probably expired. It also requires more than half redis be locked up for the job.
(4) If the lock is successfully acquired, the real effective time of the lock is TTL minus the time difference between the time the third step; for example: TTL is 5s, get all the locks with the 2s, the real effective lock time 3s (in fact should again minus the clock drift);
(5) If the client fails to acquire the lock for some reason, will begin to unlock all redis instances; because there may have been acquired less than three locks must be released, otherwise affect other client acquire a lock
Whether RedLock algorithm is asynchronous algorithm? ?
It can be seen as a synchronization algorithm; because even interprocess (among multiple computers) without synchronizing clock, but each time the process is substantially the same flow rate; and the clock drift is small relative to the TTL can be ignored, the synchronization algorithm can be seen; ( not strict enough, the algorithm to count clock drift, because if the two computers at both ends of the Earth, the clock drift is very large).
RedLock failure retry
When the client can not acquire the lock should be retried after a random time acquired the lock; and preferably the same transmission time concurrent set command to all instances redis; and a lock has been acquired for the client to complete the task in a timely release of the lock, this is to save time;
RedLock release locks
Since the lock will judge the value is not set up their own time to release the lock, if it is deleted; so when releasing the lock is very simple, as long as the commands are issued to release the lock all instances, regardless of the success of the release of the lock;
RedLock Precautions (Safety arguments):
(1) assuming first client acquires all instances, all instances contain the same key and the expiration time (the TTL), but each instance of the set command can not lead to a different time expires at the same time, before the first set command is Tl, a set command after the last the minimum time is T2, then this lock is acquired valid client TTL- (T2-T1) - clock drift;
(2) to N / 2 + 1 (i.e. more than half) of the embodiment determines whether the acquired lock success, because if less than half is determined successful, there may be a plurality of client successfully acquire the lock occurs, so that the locking effect .
(3) a client locked most cases greater than the time spent at or near the expiration of the lock, the lock is considered invalid, and unlock the redis example (do not perform business); as long as the lock successfully acquired more than half of the time in the TTL is effective locks; otherwise invalid.
The system has a characteristic activity
(1) automatically releases the lock
(2) automatically lock is released acquire the lock failure (less than half), or the task is completed, do not wait until it automatically expire
(3) the client attempts to obtain a lock prior Oh (the first to the second failure retry interval) is greater than the first lock acquisition time consumed;
(4) a retry limit for acquiring the lock to have a certain
Related solutions RedLock performance and crash recovery
(1) If redis no persistent feature acquiring a lock success in clientA, all redis restart, clientB be able to get again to lock, so that violated the exclusive mutually exclusive lock; for example: now 5 redis, so now there is a lock occupies three, one of which bounced off, then the possession of the two locks left, again a thread gets the lock, a look at three will be able to get to.
(2) If you start AOF permanent storage, things would be better, for example: when we restart redis, due to the expiration redis mechanism in accordance with the unix timestamp go, so after the restart, and will expire in accordance with the stipulated time, does not affect business ; but because of the way AOF synced to disk per second by default - twice within one second if the power failure will result in data loss, immediately restart will result in a mutually exclusive lock failure; but if you use synchronous disk mode Always (every write commands are synchronized to the hard disk) resulting in a sharp decline in performance; so in complete lock the effectiveness and performance to make a choice;
(3) an effective solution to ensure both the effectiveness and efficient performance full lock and even power outages method is redis synchronized way to keep the default disk per second, in redis whatever reason, stopped to wait after the restart after the TTL time ( Scientific name: restart delay ); drawback is that in the TTL time equivalent service suspended state;
to sum up
(1) TTL duration must be longer than the normal business performed + service time-consuming to get all redis + clock drift
(2) Get all services redis time consuming far less than the TTL, and acquires the number of locks to be successful in the above general Total: N / 2 + 1
(3) Each time acquisition attempt redis instance lock is much less than when the TTL
There must be retried after a certain number of restrictions (4) tries to acquire all locks fail
(5) After redis collapse (regardless of whether one or all), TTL time to delay the restart redis
(6) in the multi-node redis in conjunction with a single-node distributed lock algorithm to achieve common
