接口防重复提交的技术解决方案

分布式锁在技术层面有两种应用场景：
1. 可以保证幂等性（防重与幂等有区别：幂等通常是对并发请求的防重控制；防重除了需要分布式保证幂等以外，还需要做数据防重校验，因为重复请求可能不是并发请求过来的，有可能是隔了很长时间的重复数据提交，就是用DCL）
2. 实现进程同步（类似于线程synchronized锁）：当锁存在时，需要不断尝试重试取锁，实现自旋等待。

 

无论是http接口，还是rpc接口，防重复提交（接口防重）都是绕不过的话题。

重复提交与幂等，既有区别，又有联系。幂等的意思是，对资源的一次请求与多次请求，作用是相同的。例如，HTTP的POST方法是非幂等的。如果程序处理不好，重复提交会导致非幂等，引起系统数据故障。防重复提交，当属于幂等的范畴，首先通过技术手段来实现，其次，又要有对业务数据的唯一性验证。

 

常见的B/S场景的重复提交，用户手抖或因为网络问题，服务端在极短时间内两次甚至更多次收到同样的http请求。

rpc接口的重复提交，一种是不恰当的程序调用，即程序漏洞导致重复提交。在一种，比如拿dubbo来说，因为网络传输问题，会触发重试调用。

 

防重提交的方案，常见的是加锁。分布式系统，一般是借助redis或zk等分布式锁。对于java单体应用，有网友说可以用语言本身的synchronized锁机制，严格来说，这样是不恰当的，因为synchronized是多线程下的同步锁，只会阻塞线程执行，而不会阻断线程的执行。

 

【说明几点】

1.  lockKey的设置
加锁是为了拦截重复请求。key一定要与业务操作请求的请求数据有关，具有系统全局唯一性。通常的命名规范是业务操作前缀+业务数据，比如key="user.add."+userVo.toString(); key="withdraw."+userId。

反例：key=“withdraw.”;。这是一棒子打死的节奏。锁的颗粒度太大了，一个用户提现操作在执行的过程中，其他用户都无法进行提现操作。对于通常的系统提现场景来说，很显然说不过去。

反例：key="withdraw."+userId+DateUtils.format(new Date(),"yyyy-MM-dd HH:mm:ss");。因为加了时间戳，那么，非这个时刻的相同用户的提现请求就能重新上锁，从而达不到分布式锁的效果。同样的还有加UUID或雪花算法生成的唯一Id，都达不到分布式锁的控制效果。
1. 锁的有效期
下文代码会提到，释放锁的代码在finally中执行，以保证当程序因异常中断的时候仍然能够释放锁。不过，jvm也会导致finally不被执行。加锁的时间需要按业务逻辑执行时间来评估一个保守的值。太短自然是不行的，会导致重入故障；如果太久，在没有及时释放锁时候，其他请求无法进入，就会产生死锁。
2. 上锁的原子性
有的上锁方案是利用jedis的setnx(lockKey, requestId)和expire(lockKey, expireTime)，因为是两条命令，所以不具备原子性。假如程序执行了setnx后突然崩溃，会导致锁一直存在，最终导致死锁。
3. 关于释放锁
释放锁原则：解铃还须系铃人。即，clientA（线程A）上锁，只能由clientA（线程A）来解锁。释放锁的操作同样要具备原子性。另，如上文所述，释放锁的代码在finally代码中执行。

 

redis分布式锁的实现

类图：

 

RedisDistributedLock

package com.emax.zhenghe.rpcapi.provider.config.distributeRedisLock;

import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;
import org.springframework.stereotype.Component;

import javax.annotation.Resource;
import java.util.Arrays;
import java.util.UUID;
import java.util.concurrent.TimeUnit;

@Component
@Slf4j
public class RedisDistributedLock extends AbstractDistributedLock {

    @Autowired
    @Resource
    private RedisTemplate<Object, Object> redisTemplate;

    private ThreadLocal<String> lockFlag = new ThreadLocal<String>();

    public static final String UNLOCK_LUA;

    static {
        StringBuilder sb = new StringBuilder();
        sb.append("if redis.call(\"get\",KEYS[1]) == ARGV[1] ");
        sb.append("then ");
        sb.append("    return redis.call(\"del\",KEYS[1]) ");
        sb.append("else ");
        sb.append("    return 0 ");
        sb.append("end ");
        UNLOCK_LUA = sb.toString();
    }


    public RedisDistributedLock() {
        super();
    }

    @Override
    public boolean lock(String key, long expire, int retryTimes, long sleepMillis) {
        boolean result = setRedis(key, expire);
        // 如果获取锁失败，按照传入的重试次数进行重试
        while ((!result) && retryTimes-- > 0) {
            try {
                log.debug("lock failed, retrying..." + retryTimes);
                Thread.sleep(sleepMillis);
            } catch (InterruptedException e) {
                return false;
            }
            result = setRedis(key, expire);
        }
        return result;
    }

    /**
     *
     * @param key
     * @param expire MILLISECONDS
     * @return
     */
    private boolean setRedis(final String key, final long expire) {
        try {
            String uuid = UUID.randomUUID().toString();
            lockFlag.set(uuid);
            return redisTemplate.opsForValue().setIfAbsent(key,uuid,expire,TimeUnit.MILLISECONDS);
        } catch (Exception e) {
            log.info("redis lock error.", e);
        }
        return false;
    }


    @Override
    public boolean releaseLock(String key) {
        // 释放锁的时候，有可能因为持锁之后方法执行时间大于锁的有效期，此时有可能已经被另外一个线程持有锁，所以不能直接删除
        try {
            DefaultRedisScript<Boolean> defaultRedisScript = new DefaultRedisScript<Boolean>(UNLOCK_LUA,Boolean.class);
            return redisTemplate.execute(defaultRedisScript,Arrays.asList(key),lockFlag.get());
        } catch (Exception e) {
            log.error("release lock occured an exception", e);
        } finally {
            // 清除掉ThreadLocal中的数据，避免内存溢出
            lockFlag.remove();
        }
        return false;
    }
}
    

 

AbstractDistributedLock

package com.emax.zhenghe.rpcapi.provider.config.distributeRedisLock;

public abstract class AbstractDistributedLock implements DistributedLock {
 
    @Override
    public boolean lock(String key) {
        return lock(key , TIMEOUT_MILLIS, RETRY_TIMES, SLEEP_MILLIS);
    }
 
    @Override
    public boolean lock(String key, int retryTimes, long sleepMillis) {
        return lock(key, TIMEOUT_MILLIS, retryTimes, sleepMillis);
    }
 
    @Override
    public boolean lock(String key, long expire) {
        return lock(key, expire, RETRY_TIMES, SLEEP_MILLIS);
    }
 
    @Override
    public boolean lock(String key, long expire, int retryTimes) {
        return lock(key, expire, retryTimes, SLEEP_MILLIS);
    }
 
}

 

DistributedLock 

package com.emax.zhenghe.rpcapi.provider.config.distributeRedisLock;

public interface DistributedLock {
    
     long TIMEOUT_MILLIS = 30000;
    
     int RETRY_TIMES = 2;
    
     long SLEEP_MILLIS = 500;
    
     boolean lock(String key);boolean lock(String key, int retryTimes, long sleepMillis);
    
     boolean lock(String key, long expire);
    
     boolean lock(String key, long expire, int retryTimes);
    
     boolean lock(String key, long expire, int retryTimes, long sleepMillis);
    
     boolean releaseLock(String key);
}

 

调用：

    @Autowired
    private RedisDistributedLock distributedLock;

    @Test
    public void lock11() throws Exception {
        String key = "examplekey" + System.currentTimeMillis();
        try {
            boolean lock = distributedLock.lock(key, 2000L, 1, 100L);
            log.info("===================" + lock);
        } finally {
            distributedLock.releaseLock(key);
        }
    }

 

 

进一步封装，实现代码解耦

上面的加锁和释放锁都暴露在了业务调用方，增加了业务调用方的职责，同时，如果使用不当，还会产生bug。

接下来，我们稍作重构。看看下面的RedisLockTemplate

package com.emax.zhenghe.rpcapi.provider.config.distributeRedisLock;

import lombok.extern.slf4j.Slf4j;
import org.apache.commons.lang3.StringUtils;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

/**
 * redis分布式锁并发控制模板类
 *
 * @author zhangguozhan
 */
@Slf4j
@Component
public class RedisLockTemplate {
    @Autowired
    private RedisDistributedLock redisDistributedLock;

    /**
     * redis分布式锁控制
     *
     * @param key               锁名
     * @param expireMS          锁的生命周期，单位：毫秒
     * @param redisLockCallback callback方法
     * @return
     */
    public Object execute(String key, long expireMS, RedisLockCallback redisLockCallback) {
        return execute(key, expireMS, redisLockCallback, true, 2);
    }

    /**
     * redis分布式锁控制
     *
     * @param key
     * @param expireMS
     * @param redisLockCallback
     * @param isAutoReleaseLock callback方法执行完成后自动释放锁
     * @return
     */
    public Result execute(String key, long expireMS, RedisLockCallback redisLockCallback,
                          boolean isAutoReleaseLock,
                          int retryTimes) {
        log.info("redis分布式锁控制 key={}", key);
        if (StringUtils.isBlank(key)) {
            log.info("try lock failure:key is null");
            return null;
        }
        boolean lock = redisDistributedLock.lock(key, expireMS, retryTimes);
        if (lock) {
            try {
                Result o = redisLockCallback.doInRedisLock();
                return o;
            } finally {
                if (isAutoReleaseLock) {
                    redisDistributedLock.releaseLock(key);
                }
            }
        } else {
            log.info("###key已存在，终止 key={}", key);
            return Result.error(ResultCodeEnum.GET_LOCK_FAIL, "请勿重复发起");
        }

    }
}

 

RedisLockCallback是一个函数式接口

package com.emax.zhenghe.rpcapi.provider.config.distributeRedisLock;

@FunctionalInterface
public interface RedisLockCallback {
    Result doInRedisLock();
}

 

这样，业务的调用就变得很easy了。例如：

Result result = redisLockTemplate.execute(key, 5000L, () -> {
            List<BillVo> billVos = batchInsert(list);
            return Result.ok(billVos);
});

 

 

关于ajax异步请求

 现在的web项目一般都是采用前后端分离的开发模式了，前端的程序框架也百花齐放，常见的有vue、nodejs等等。

 对于用户手抖导致的重复提交，服务端的做法就是利用上面的分布式控制，非首次的请求因为上锁失败而中断处理，前端收到的是“请勿重复提交”这样的提示。我原以为这样可能会影响用户体验。后来咨询前端同事，原来事实并非如此。

自己写了一个demo，模拟重复提交。页面异步重复发起相同的请求，服务端重复处理。第一次是加锁，正常处理请求，第二次是发现锁已存在，上锁失败，直接返回“请勿重复提交”的提示。页面会收到两次的响应结果。不过，因为第二次的请求上锁失败直接返回错误提示，所以响应早于第一次的响应。ajax判断响应的逻辑是如果是成功（正常响应，视为成功），就触发相应的后续处理，如果是失败（“请勿重复提交”视为失败），就toast提示。 因此，虽然toast了一下，只是一瞬间，第一次请求的响应来了之后，就会正常处理页面逻辑。

 

所以，上面的防重机制，也是比较合适的方案。

当然，应该校验的业务逻辑还是要有的，尤其是数据校验。这属于业务范畴了。

 

本文代码已放到github：https://github.com/buguge/api-idempotent.git

前端页面异步请求API，可参阅其中的代码：https://github.com/buguge/api-idempotent/blob/master/mideng/src/main/webapp/user.jsp