记一次使用分布式锁遇到设计问题

这个问题估量大部分开发都会遇到，大部分人都会遗失,遇到这样状况，你是否立马能找到问题

源自一个需求，对一个接口进行幂等操控。其时完成思路，创立一个声明注解，标注参数的对象的字段作为幂等符号，运用注解作为切点，进行盘绕告诉操控对事务办法进行增强，如果幂等字段现已存在，不调用事务办法。

代码完成

界说注解

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Idempotent {
    /**
     * 唯一标识
     * @return
     */
    String uniqueKey();
}

界说切面

@Component
@Aspect
@Slf4j
public class IdempotentAspect {
    private String keyTemplate = "system:%s.%s:%s";
    @Autowired
    private RedisDistributedLock distributedLock;
    @Pointcut("@annotation(com.xxx.xx.Idempotency)")
    public void pointcut() {
    }
    @Around("pointcut()")
    public Object around(ProceedingJoinPoint point) throws Throwable {
        String className = point.getTarget().getClass().getName();
        MethodSignature joinPointObject = (MethodSignature) point.getSignature();
        Method method = joinPointObject.getMethod();
        Idempotency annotation = AnnotationUtils.getAnnotation(method, Idempotency.class);
        String field = annotation.uniqueKey();
        Object[] args = point.getArgs();
        String methodName = point.getSignature().getName();
        if (ArrayUtils.isEmpty(args))
            return point.proceed();
        Object targetObject = args[0];
        if (isNull(targetObject))
            return point.proceed();
        PropertyDescriptor propertyDescriptor = BeanUtils.getPropertyDescriptor(targetObject.getClass(), field);
        if (isNull(propertyDescriptor)) {
            log.warn("找不到对象特点 {}", field);
            return point.proceed();
        }
        Object fieldValue = propertyDescriptor.getReadMethod().invoke(targetObject);
        String key = format(keyTemplate,className, methodName, fieldValue.toString());
        boolean lock = distributedLock.lock(key);
        if (lock) {
            //判断fieldValue 在数据库是否存在、而且写入数据库中
            boolean canExecute = false;
            canExecute = findRecord(fieldValue);
            if (canExecute) {
                try {
                    return point.proceed();
                } finally {
                    distributedLock.releaseLock(key);
                }
            }
        }
        //略
    }
}

上面便是盘绕告诉详细完成，省略一些具体操作完成，获取注解的uniqueKey到履行办法的参数对象中获取field值，通过办法名+field值进行加锁，并发操控，根据数据库判断操控履行。
很简单就完成对办法进行大局幂等操控，十分自信连自测都没有进行调用，直接提交到测验环境，成果啪啪打脸。在finally 解锁办法中抛出一个反常org.springframework.dao.InvalidDataAccessApiUsageException: Unexpected exception while processing command; nested exception is org.redisson.client.RedisException: Unexpected exception while processing command。这样的成果我是很懵逼的，没道理会在这儿出问题的啊。我是不是运用错API，毕竟这个是公司封装的散布式东西，在看了一个其他提交的代码，运用办法并没有任何问题。这个反常是redis履行脚本过错导致，我榜首主意是解锁的lua履行出错了，找同事要了类库的源码。

反常分析

散布式完成

@Slf4j
@Component
public class RedisDistributedLock {
@Autowired
private RedisTemplate<String, Object> redisTemplate;
private ThreadLocal<String> lockFlag = new ThreadLocal<>();
private static final String LUA_SCRIPT = "if redis.call("get",KEYS[1]) == ARGV[1] " +
        "then " +
        "    return redis.call("del",KEYS[1]) " +
        "else " +
        "    return 0 " +
        "end ";
public boolean lock(String key) {
    String uuid = UUID.randomUUID().toString();
    lockFlag.set(uuid);
    boolean result = setRedis(key, 10000L);
    return result;
}
private boolean setRedis(final String key, final long expire) {
    try {
        boolean status = redisTemplate.execute((RedisCallback<Boolean>) connection -> {
            byte[] keyByte = redisTemplate.getStringSerializer().serialize(key);
            byte[] uuidByte = redisTemplate.getStringSerializer().serialize(lockFlag.get());
            boolean result = connection.set(keyByte, uuidByte, Expiration.from(expire, TimeUnit.MILLISECONDS), RedisStringCommands.SetOption.ifAbsent());
            return result;
        });
        return status;
    } catch (Exception e) {
        log.error("set redisDistributeLock occured an exception", e);
        //此处应抛出反常，用来标识redis访问失败的状况
        throw e;
    }
}
public boolean releaseLock(String key) {
    try {
        Boolean result = redisTemplate.execute((RedisCallback<Boolean>) connection -> {
            byte[] scriptByte = redisTemplate.getStringSerializer().serialize(LUA_SCRIPT);
            return connection.eval(scriptByte, ReturnType.BOOLEAN, 1
                    , redisTemplate.getStringSerializer().serialize(key)
                    , redisTemplate.getStringSerializer().serialize(lockFlag.get()));
        });
        return result;
    } catch (Exception e) {
        log.error("release redisDistributeLock occured an exception", e);
    } finally {
        lockFlag.remove();
    }
    return false;
}

这看起来是不是一切都很正常，就像标准答案相同正确，问题到底出来哪里呢。我们先别急着成果，自己想一下，所有的线索现已给出来，可以推断出问题了。

回想起两年前，被一个面试官问到一个问题，散布式要具有那些特性。在平常开发中很少运用散布锁，一点概念都没有。但是我脑子一转想到synchronized、Lock这些JDK锁自备的特性，互斥、可重入、高性能。现在回想下，就漏掉一个高可用答案，其他都没什么问题了。而上面的问题就出现在可重入。它运用ThreadLocal<String> lockFlag来保存当前线程持有锁的符号，问题就出来这儿。在切面的办法里，第2次调用lock办法，lockFlag被赋值了两次，会导致榜首次赋值被同一个线程第2次加锁掩盖，然后每次解锁是都会删去锁的value，第2次解锁时lockFlag现已被删去了，所以解锁脚本履行失败了，程序才会抛出反常。lockFlag只能保存同一个线程内一次加锁，当出现一个现场多次加锁，有或许每一次加锁都不是同一个锁，这儿的规划是满意不了这样的场景的。散布锁锁的可重入，我了解和JDK衍生锁不相同，纷歧定是同一把锁，一个线程多次调用锁，散布对不同资源进行确定，这也算是可重入。不知道我们对散布式重入有什么看法，欢迎在评论区说出你的主意，我们一同讨论下。最后的解决方案，运用Stack代替String。

心得

我想其时开发规划这个东西类时，并没有考虑可重入特性，看来八股文背得还不够熟练啊。阅历这个问题后，可重入是每一个锁有必要具有的特性，否则很简单写出死锁的代码。