@PreAcquireNamespaceLock 使用相同user，多实例并发加锁是否存在失效问题？

[douyiii]

场景

生产中多实例分布式部署adminservice，并发请求添加同一Item，数据库中存在两个相同namespaceId,Key,IsDeleted=0的Item数据，导致无法删除该Key，报错为query did not return a unique result:2。

问题定位过程

首先注意到item的CURD操作中都会先去判断数据库中是否存在相同的Item，那么高并发情况下一定会出问题
之后看到到方法声明上都添加了@PreAcquireNamespaceLock注解，具体到tryLock方法中看到，加锁是根据namespaceId来加锁，且mysql表中该字段加了唯一索引
最后感觉到疑问，在tryLock失败时 catch中的checkLock逻辑，如果使用相同user的两个实例并发加锁请求，实例1加锁成功，实例2加锁失败，但catch中调用checkLock方法时，检查发现user与lock表中的user相同，那么也会加锁成功？

请问是否存在这种情况？如果存在如何避免？新人小白，期待解答:)

private void acquireLock(Namespace namespace, String currentUser) {
    if (namespace == null) {
      throw new BadRequestException("namespace not exist.");
    }

    long namespaceId = namespace.getId();

    NamespaceLock namespaceLock = namespaceLockService.findLock(namespaceId);
    if (namespaceLock == null) {
      try {
        tryLock(namespaceId, currentUser);
        //lock success
      } catch (DataIntegrityViolationException e) {
        //lock fail
        namespaceLock = namespaceLockService.findLock(namespaceId);
        checkLock(namespace, namespaceLock, currentUser);
      } catch (Exception e) {
        logger.error("try lock error", e);
        throw e;
      }
    } else {
      //check lock owner is current user
      checkLock(namespace, namespaceLock, currentUser);
    }
  }

private void checkLock(Namespace namespace, NamespaceLock namespaceLock,
                         String currentUser) {
    if (namespaceLock == null) {
      throw new ServiceException(
          String.format("Check lock for %s failed, please retry.", namespace.getNamespaceName()));
    }

    String lockOwner = namespaceLock.getDataChangeCreatedBy();
    if (!lockOwner.equals(currentUser)) {
      throw new BadRequestException(
          "namespace:" + namespace.getNamespaceName() + " is modified by " + lockOwner);
    }
  }

[nobodyiam]

PreAcquireNamespaceLock 是用来实现 namespace.lock.switch 功能的，不是用来解决并发写入的问题。
Apollo 目前用于解决并发写入的问题是采用了在表中增加唯一键的形式 #3866，不过 Item 和 GrayReleaseRule 表有一些特殊场景，所以暂时还没启用唯一键，也欢迎大家可以一起讨论，看看是否有好的解决方案。

[douyiii]

只在namespaceLock表加了唯一键，那么并发对同一namespaceId下的item进行增删改是可能会出现错误的吧。要根据业务需求来修改加锁的粒度了

[nobodyiam]

对同一 namespaceId 下的 item 进行增删改没问题的，对同一个 item 的新增可能会出现重复数据。

[douyiii]

对同一 namespaceId 下的 item 进行增删改没问题的，对同一个 item 的新增可能会出现重复数据。

对item的新增经过测试，高并发情况下很容易出现重复数据；对同一item的删除没问题的，并发请求删除总会有一个请求能删除掉；并发更新的话是否会存在较后请求被较前请求覆盖掉，出现丢失更新的情况？
例如request-1(相对较前)，更新key为1，request-2(相对较后)更新key为2，最后结果为key=1。

[nobodyiam]

并发更新/创建更多的是出现在不同用户的场景，所以 namespace.lock.switch 功能也可以在一定程度上避免此类问题

[douyiii]

并发更新/创建更多的是出现在不同用户的场景，所以 namespace.lock.switch 功能也可以在一定程度上避免此类问题

对于相同用户的并发，lock.switch就不能避免了吧，后续会考虑这方面的优化吗？目前是不是只能修改代码或在客户端用分布式锁？