关于java:记一次使用分布式锁遇到设计问题

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

源自一个需要，对一个接口进行幂等管制。过后实现思路，创立一个申明注解，标注参数的对象的字段作为幂等标记，应用注解作为切点，进行盘绕告诉管制对业务办法进行加强，如果幂等字段曾经存在，不调用业务办法。

代码实现

定义注解

@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 来保留以后线程持有锁的标记，问题就进去这里。在切面的办法里，第二次调用 lock 办法，lockFlag被赋值了两次，会导致第一次赋值被同一个线程第二次加锁笼罩，而后每次解锁是都会删除锁的 value，第二次解锁时 lockFlag 曾经被删除了，所以解锁脚本执行失败了，程序才会抛出异样。lockFlag只能保留同一个线程内一次加锁，当呈现一个现场屡次加锁，有可能每一次加锁都不是同一个锁，这里的设计是满足不了这样的场景的。散布锁锁的 可重入 ，我了解和 JDK 衍生锁不一样，不肯定是同一把锁，一个线程屡次调用锁，散布对不同资源进行锁定，这也算是 可重入 。不晓得大家对分布式重入有什么认识，欢送在评论区说出你的想法，大家一起探讨下。最初的解决方案，应用Stack 代替String。

心得

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