Pit and solutions distributed lock (redis) applications

Pit and solutions distributed lock (redis) applications

Usage scenarios : two servers clustered deployment docking station engineering (engineering data synchronization), each project task execution timing using a spring, one minute to perform a scan.
, Intermediate scan push data tables, for processing.

Problem Description : random phenomenon appears part of the data is scanned twice.

BACKGROUND problem : design goals: Code execution timing of scanning is increased distributed lock, after acquiring the lock, the query to the intermediate state data from the data in Table 1 is changed to 0, then the identifier has been processed, another server I will not go scanned.

Analysis : Distributed Lock does not take effect two servers at the same time lead to the implementation of the same data.
Key: 1 to be treated in the process of scanning data into, whether it is independent
whether the valid duration 2. Distributed Lock

The analysis found that the following wording:

 if(CacheUtil.getLock(key,second)){
 	 try{
 	 	//扫描待处理数据，并且将数据改成处理中，避免被下个进程扫描到
 	 	//处理数据逻辑
 	 }catch(Throwable e){
                logger.error(e.getMessage(),e);
     }finally{
		CacheUtil.unlock(key);
	}
 }

public static boolean getLock(String key, int expires) {
        try {
            logger.info("获取锁开始:" + key + " timestamp:" + System.currentTimeMillis());
            if (getCache().setnx(key, System.currentTimeMillis())) {
                logger.info("获取锁成功:key ==> " + key + " 值为:" + getCache().get(key));
                return true;
            } else {
                long currentValueL = 0L;

                try {
                    String currentValue = getCache().get(key) == null ? "0" : String.valueOf(getCache().get(key));
                    currentValueL = Long.parseLong(currentValue);
                } catch (Exception var5) {
                    currentValueL = 0L;
                }

                if (currentValueL < System.currentTimeMillis() - (long)expires) {
                    logger.info("锁过期，删除旧锁:key ==> " + key + " timestamp:" + System.currentTimeMillis());
                    unlock(key);//*此处和上面的CacheUtil.unlock(key);逻辑是一样的*
                    return getCache().setnx(key, System.currentTimeMillis());
                } else {
                    logger.info("获取锁结束:" + key + " timestamp:" + System.currentTimeMillis());
                    return false;
                }
            }
        } catch (Exception var6) {
            logger.error("OH,MY GOD! SOME ERRORS OCCURED! AS FOLLOWS :获取锁异常key ==> " + key, var6);
            return false;
        }
    }

 public static void unlock(String key) {
        try {
            cacheManager.unlock(key);
            logger.info("解锁成功  key ==> " + key + " timestamp:" + System.currentTimeMillis());
        } catch (Exception var2) {
            logger.info("解锁失败  key ==> " + key + " 不存在,或已解锁! timestamp:" + System.currentTimeMillis());
        }

    }

  public void unlock(String key) {
        this.del(key);//未做任何处理，直接删除了，所以如果无条件调用它，就会出现暴力删除的动作
    }
    

Analysis of the flow of FIG production appears not lock the scene:

Conclusion:
1. timing task scan is preferable to use a logical segment time of scanning, the start time may be used to generate a queue, FIFO, distributed environment protection Uniqueness of the data fetch.

2. You can use the database lock shackles and redis locked,
if locked with a database, you can use something like select * from xxx where id = xxxx for update to lock this data, then who obtain this data to lock, then who will get a lock, you can go down. But this efficiency is poor.

The use redis lock, locking is performed by api setnx, i.e., if there is set value, the set value is not present. Who set the value, who will get the lock.

3. For unlocking logic, can not unlock the violence, we must determine whether this lock is valid only if the invalid can be deleted, otherwise the situation lock failure occurs.