面試阿里被問：「你的項目是如何處理重複請求/併發請求的？」

對於一些用戶請求，在某些狀況下是可能重複發送的，若是是查詢類操做並沒有大礙，但其中有些是涉及寫入操做的，一旦重複了，可能會致使很嚴重的後果，例如交易的接口若是重複請求可能會重複下單。

重複的場景有多是：

黑客攔截了請求，重放
前端/客戶端由於某些緣由請求重複發送了，或者用戶在很短的時間內重複點擊了。
網關重發
….
本文討論的是如何在服務端優雅地統一處理這種狀況，如何禁止用戶重複點擊等客戶端操做不在本文的討論範疇。

利用惟一請求編號去重

你可能會想到的是，只要請求有惟一的請求編號，那麼就能借用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。那麼針對這種場景，咱們怎麼去重呢？

計算請求參數的摘要做爲參數標識

假設咱們把請求參數（JSON）按KEY作升序排序，排序後拼成一個字符串，做爲KEY值呢？但這可能很是的長，因此咱們能夠考慮對這個字符串求一個MD5做爲參數的摘要，以這個摘要去取代reqParam的位置。

String KEY = "dedup:U="+userId + "M=" + method + "P=" + reqParamMD5;
這樣，請求的惟一標識就打上了！

注：MD5理論上可能會重複，可是去重一般是短期窗口內的去重（例如一秒），一個短期內同一個用戶一樣的接口能拼出不一樣的參數致使同樣的MD5幾乎是不可能的。

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

上面的問題其實已是一個很不錯的解決方案了，可是實際投入使用的時候可能發現有些問題：某些請求用戶短期內重複的點擊了（例如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的經緯度字段（重複請求間可能有極小的差異）。

請求去重工具類，Java實現

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 ) 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; }