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

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

源自一个需求，对一个接口进行幂等控制。当时实现思路，创建一个声明注解，标注参数的对象的字段作为幂等标记，使用注解作为切点，进行环绕通知控制对业务方法进行增强，如果幂等字段已经存在，不调用业务方法。

代码实现

定义注解

@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 redisTemplate;

private ThreadLocal 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) 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) 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 lockFlag来保存当前线程持有锁的标记，问题就出来这里。在切面的方法里，第二次调用lock方法，lockFlag被赋值了两次，会导致第一次赋值被同一个线程第二次加锁覆盖，然后每次解锁是都会删除锁的value，第二次解锁时lockFlag已经被删除了，所以解锁脚本执行失败了，程序才会抛出异常。lockFlag只能保存同一个线程内一次加锁，当出现一个现场多次加锁，有可能每一次加锁都不是同一个锁，这里的设计是满足不了这样的场景的。分布锁锁的可重入，我理解和JDK衍生锁不一样，不一定是同一把锁，一个线程多次调用锁，分布对不同资源进行锁定，这也算是可重入。不知道大家对分布式重入有什么看法，欢迎在评论区说出你的想法，大家一起讨论下。最后的解决方案，使用Stack替代String。

心得

我想当时开发设计这个工具类时，并没有考虑可重入特性，看来八股文背得还不够熟练啊😂。经历这个问题后，可重入是每一个锁必须具备的特性，不然很容易写出死锁的代码。