如何優雅處理重復請求/并發請求？

作者：佚名 2021-06-17 09:32:39

開發后端

本文討論的是如何在服務端優雅地統一處理這種情況，如何禁止用戶重復點擊等客戶端操作不在本文的討論范疇。

[[406095]]

前言

一些用戶請求在某些情況下是可能重復發送的，如果是查詢類操作并無大礙，但其中有些涉及寫入操作，一旦重復了，可能會導致很嚴重的后果。例如交易接口如果重復請求，可能會重復下單。

重復的場景有可能是：

黑客攔截了請求，重放；
前端/客戶端因為某些原因請求重復發送了，或者用戶在很短的時間內重復點擊了；
網關重發；
……

本文討論的是如何在服務端優雅地統一處理這種情況，如何禁止用戶重復點擊等客戶端操作不在本文的討論范疇。

利用唯一請求編號去重

你可能會想到，只要請求有唯一的請求編號，那么就能借用 Redis 做去重。只要這個唯一請求編號在 Redis 存在，證明處理過，那么就認為是重復的。

代碼基本如下：

String KEY = "REQ12343456788";//請求唯一編號  
 long expireTime =  1000;// 1000毫秒過期，1000ms內的重復請求會認為重復  
 long expireAt = System.currentTimeMillis() + expireTime;  
 String val = "expireAt@" + expireAt;  
 //redis key還存在的話要就認為請求是重復的 
 Boolean firstSet = stringRedisTemplate.execute((RedisCallback<Boolean>) connection -> connection.set(KEY.getBytes(), val.getBytes(), Expiration.milliseconds(expireTime), RedisStringCommands.SetOption.SET_IF_ABSENT)); 
 final boolean isConsiderDup;  
 if (firstSet != null && firstSet) {// 第一次訪問  
     isConsiderDup = false;  
 } else {// redis值已存在，認為是重復了  
     isConsiderDup = true;

業務參數去重

上面的方案能解決具備唯一請求編號的場景，例如每次寫請求之前都是服務端返回一個唯一編號給客戶端，客戶端帶著這個請求號做請求，服務端即可完成去重攔截。

但是，很多的場景下，請求并不會帶這樣的唯一編號！那么我們能否針對請求的參數作為一個請求的標識呢？

先考慮簡單的場景，假設請求參數只有一個字段 reqParam，我們可以利用以下標識去判斷這個請求是否重復。

用戶ID:接口名:請求參數

String KEY = "dedup:U="+userId + "M=" + method + "P=" + reqParam;

那么當同一個用戶訪問同一個接口，帶著同樣的 reqParam 過來，我們就能定位到他是重復的了。

但是問題是，我們的接口通常不是這么簡單，以目前的主流，我們的參數通常是一個 JSON。那么針對這種場景，我們怎么去重呢？

1、計算請求參數的摘要作為參數標識

假設我們把請求參數（JSON）按KEY做升序排序，排序后拼成一個字符串，作為 KEY 值呢？但這可能非常的長，所以我們可以考慮對這個字符串求一個 MD5 作為參數的摘要，以這個摘要去取代 reqParam 的位置。

String KEY = "dedup:U="+userId + "M=" + method + "P=" + reqParamMD5;

這樣，請求的唯一標識就打上了！

注：MD5 理論上可能會重復，但是去重通常是短時間窗口內的去重（例如一秒），一個短時間內同一個用戶同樣的接口能拼出不同的參數導致一樣的 MD5 幾乎是不可能的。

2、繼續優化，考慮剔除部分時間因子

上面的問題其實已經是一個很不錯的解決方案了，但是實際投入使用的時候可能發現有些問題：某些請求用戶短時間內重復的點擊了（例如 1000 毫秒發送了三次請求），但繞過了上面的去重判斷（不同的 KEY 值）。

原因是這些請求參數的字段里面，是帶時間字段的，這個字段標記用戶請求的時間，服務端可以借此丟棄掉一些老的請求（例如5秒前）。如下面的例子，請求的其他參數是一樣的，除了請求時間相差了一秒：

//兩個請求一樣，但是請求時間差一秒  
   String req = "{\n" +  
           "\"requestTime\" :\"20190101120001\",\n" +  
           "\"requestValue\" :\"1000\",\n" +  
           "\"requestKey\" :\"key\"\n" +  
           "}";  
   String req2 = "{\n" +  
           "\"requestTime\" :\"20190101120002\",\n" +  
           "\"requestValue\" :\"1000\",\n" +  
           "\"requestKey\" :\"key\"\n" +  
           "}";

這種請求，我們也很可能需要擋住后面的重復請求。所以求業務參數摘要之前，需要剔除這類時間字段。還有類似的字段可能是 GPS 的經緯度字段（重復請求間可能有極小的差別）。

請求去重工具類的代碼落地

public class ReqDedupHelper {  
    /**  
     *  
     * @param reqJSON 請求的參數，這里通常是JSON  
     * @param excludeKeys 請求參數里面要去除哪些字段再求摘要  
     * @return 去除參數的MD5摘要  
     */  
    public String dedupParamMD5(final String reqJSON, String... excludeKeys) {  
        String decreptParam = reqJSON;  
        TreeMap paramTreeMap = JSON.parseObject(decreptParam, TreeMap.class);  
        if (excludeKeys!=null) {  
            List<String> dedupExcludeKeys = Arrays.asList(excludeKeys);  
            if (!dedupExcludeKeys.isEmpty()) { 
                 for (String dedupExcludeKey : dedupExcludeKeys) {  
                    paramTreeMap.remove(dedupExcludeKey);  
                }  
            }  
        }  
        String paramTreeMapJSON = JSON.toJSONString(paramTreeMap);  
        String md5deDupParam = jdkMD5(paramTreeMapJSON);  
        log.debug("md5deDupParam = {}, excludeKeys = {} {}", md5deDupParam, Arrays.deepToString(excludeKeys), paramTreeMapJSON);  
        return md5deDupParam;  
    }  
    private static String jdkMD5(String src) {  
        String res = null;  
        try {  
            MessageDigest messageDigest = MessageDigest.getInstance("MD5");  
            byte[] mdBytes = messageDigest.digest(src.getBytes());  
            res = DatatypeConverter.printHexBinary(mdBytes);  
        } catch (Exception e) {  
            log.error("",e);  
        }  
        return res;  
    }  
}

下面是一些測試日志：

public static void main(String[] args) {  
    //兩個請求一樣，但是請求時間差一秒  
    String req = "{\n" +  
            "\"requestTime\" :\"20190101120001\",\n" +  
            "\"requestValue\" :\"1000\",\n" +  
            "\"requestKey\" :\"key\"\n" +  
            "}";  
    String req2 = "{\n" +  
            "\"requestTime\" :\"20190101120002\",\n" +  
            "\"requestValue\" :\"1000\",\n" +  
            "\"requestKey\" :\"key\"\n" +  
            "}";   
    //全參數比對，所以兩個參數MD5不同  
    String dedupMD5 = new ReqDedupHelper().dedupParamMD5(req);  
    String dedupMD52 = new ReqDedupHelper().dedupParamMD5(req2);  
    System.out.println("req1MD5 = "+ dedupMD5+" , req2MD5="+dedupMD52);   
    //去除時間參數比對，MD5相同  
    String dedupMD53 = new ReqDedupHelper().dedupParamMD5(req,"requestTime");  
    String dedupMD54 = new ReqDedupHelper().dedupParamMD5(req2,"requestTime");  
    System.out.println("req1MD5 = "+ dedupMD53+" , req2MD5="+dedupMD54);  
}

日志輸出：

req1MD5 = 9E054D36439EBDD0604C5E65EB5C8267 , req2MD5=A2D20BAC78551C4CA09BEF97FE468A3F  
req1MD5 = C2A36FED15128E9E878583CAAAFEFDE9 , req2MD5=C2A36FED15128E9E878583CAAAFEFDE9

日志說明：

一開始兩個參數由于 requestTime 是不同的，所以求去重參數摘要的時候可以發現兩個值是不一樣的；
第二次調用的時候，去除了 requestTime 再求摘要（第二個參數中傳入了”requestTime”），則發現兩個摘要是一樣的，符合預期。

總結

至此，我們可以得到完整的去重解決方案，如下：

String userId= "12345678";//用戶  
String method = "pay";//接口名  
String dedupMD5 = new ReqDedupHelper().dedupParamMD5(req,"requestTime");//計算請求參數摘要，其中剔除里面請求時間的干擾  
String KEY = "dedup:U=" + userId + "M=" + method + "P=" + dedupMD5;  
long expireTime =  1000;// 1000毫秒過期，1000ms內的重復請求會認為重復  
long expireAt = System.currentTimeMillis() + expireTime; 
String val = "expireAt@" + expireAt;  
// NOTE:直接SETNX不支持帶過期時間，所以設置+過期不是原子操作，極端情況下可能設置了就不過期了，后面相同請求可能會誤以為需要去重，所以這里使用底層API，保證SETNX+過期時間是原子操作 
Boolean firstSet = stringRedisTemplate.execute((RedisCallback<Boolean>) connection -> connection.set(KEY.getBytes(), val.getBytes(), Expiration.milliseconds(expireTime), 
         RedisStringCommands.SetOption.SET_IF_ABSENT));  
final boolean isConsiderDup;  
if (firstSet != null && firstSet) {  
    isConsiderDup = false;  
} else {  
    isConsiderDup = true;  
}

【責任編輯：龐桂玉 TEL：（010）68476606】

責任編輯：龐桂玉來源： java版web項目

重復請求并發請求 Java