Redis cache tool Jedis performs cross-JVM lock (Distributed Application)

Recently, redis encountered multiple concurrent processing of the same cache. In this case, the locking mechanism is required. I wanted to use the readwritelock that comes with Java to set the read/write lock. This is also the method used by the previous company. After further discussion, we will be able to exclude it. The reason is none, that is, the write lock on server a cannot restrict the same method on server B, that is, it is not applicable to the distributed deployment environment.

Later, I checked the materials in many ways. The final decision is to use the redis method setnx for the locking mechanism. There are many locks for setnx on the Internet. However, most of them share the same defect: Using setnx to lock and del to release the lock. In this case. If the lock is not released due to an exception after locking, the lock will become a deadlock. Reference: http://blog.csdn.net/java2000_wl/article/details/8740911

Then there was a new idea, using setnx and expire in combination, so that the lock has a validity period. In this way, when an exception occurs, the lock can be automatically released once the validity period expires. There are some improvements, but because setnx and expire are two steps, they are not Atomic. If an exception occurs after the setnx operation, it will still cause a deadlock.

Then, we will consider how to make the setnx and expire operations synchronized and atomic. In this case, set the value of setnx to a certain time point after the current time (such as one minute later). Can this indirectly Replace the expire operation. Yes, this method can be implemented. Now, with Del, you can lock and unlock the lock (and unlock the lock due to exceptions ). But there are still some defects, because this situation will lead to competition, refer to: https://github.com/huangz1990/redis/commit/18dbaee4f40f435970a09da427b8f45bd26b4072#diff-b643df753e12d0d07a872f91487c957dR34

Based on the solution provided in the above link (the new algorithm IDEA), the validity period is used to determine whether to delete the key, instead of directly assigning a new value to the key, using GetSet, then, judge whether the obtained value is equal to the original value. If the obtained value is equal, the lock is obtained. Finally, you can manually unlock the key (that is, you can delete the key ). The following code is provided:

Public Boolean lock (string key, long timeout) {Boolean locksuccess = false; shardedjedis = pool. getresource (); try {long start = system. currenttimemillis (); string lockkey = "lock _" + key; do {long result = shardedjedis. setnx (lockkey, String. valueof (system. currenttimemillis () + lockkey_expire_time * 1000 + 1); If (result = 1) {locksuccess = true; break;} else {string locktimestr = shardedjedis. get (lockkey); If (stringutils. isnumeric (locktimestr) {// if the key exists, the lock has long locktime = long. valueof (locktimestr); If (locktime <system. currenttimemillis () {// The lock has expired string originstr = shardedjedis. getSet (lockkey, String. valueof (system. currenttimemillis () + lockkey_expire_time * 1000 + 1); If (stringutils. isnoneblank (originstr) & originstr. equals (locktimestr) {// indicates that the lock is obtained by this thread locksuccess = true; break ;}}// if no wait, if (timeout = 0) is returned directly) {break;} // wait for MS to continue locking the thread. sleep (300);} while (system. currenttimemillis ()-Start) <timeout);} catch (exception e) {e. printstacktrace ();} finally {...} return locksuccess;} public void unlock (string key) {shardedjedis = pool. getresource (); try {string lockkey = "lock _" + key; shardedjedis. del (lockkey);} catch (exception e) {e. printstacktrace ();} finally {...}}

This is probably the case ~~~

Sharing!