面試阿里被問:“你的項(xiàng)目是如何處理重復(fù)請(qǐng)求/并發(fā)請(qǐng)求的?”

作者：Jaskey Lam

原文鏈接（底部鏈接可直達(dá)）：

http://jaskey.github.io/blog/2020/05/19/handle-duplicate-request/

對(duì)于一些用戶請(qǐng)求，在某些情況下是可能重復(fù)發(fā)送的，如果是查詢類操作并無大礙，但其中有些是涉及寫入操作的，一旦重復(fù)了，可能會(huì)導(dǎo)致很嚴(yán)重的后果，例如交易的接口如果重復(fù)請(qǐng)求可能會(huì)重復(fù)下單。

重復(fù)的場(chǎng)景有可能是：

1. 黑客攔截了請(qǐng)求，重放
2. 前端/客戶端因?yàn)槟承┰蛘?qǐng)求重復(fù)發(fā)送了，或者用戶在很短的時(shí)間內(nèi)重復(fù)點(diǎn)擊了。
3. 網(wǎng)關(guān)重發(fā)
4. ….

本文討論的是如何在服務(wù)端優(yōu)雅地統(tǒng)一處理這種情況，如何禁止用戶重復(fù)點(diǎn)擊等客戶端操作不在本文的討論范疇。

利用唯一請(qǐng)求編號(hào)去重

你可能會(huì)想到的是，只要請(qǐng)求有唯一的請(qǐng)求編號(hào)，那么就能借用Redis做這個(gè)去重——只要這個(gè)唯一請(qǐng)求編號(hào)在redis存在，證明處理過，那么就認(rèn)為是重復(fù)的

代碼大概如下：

????String?KEY?=?"REQ12343456788";//請(qǐng)求唯一編號(hào)
????long?expireTime?=??1000;//?1000毫秒過期，1000ms內(nèi)的重復(fù)請(qǐng)求會(huì)認(rèn)為重復(fù)
????long?expireAt?=?System.currentTimeMillis()?+?expireTime;
????String?val?=?"expireAt@"?+?expireAt;

????//redis?key還存在的話要就認(rèn)為請(qǐng)求是重復(fù)的
????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?{//?redis值已存在，認(rèn)為是重復(fù)了
????????isConsiderDup?=?true;
????}

業(yè)務(wù)參數(shù)去重

上面的方案能解決具備唯一請(qǐng)求編號(hào)的場(chǎng)景，例如每次寫請(qǐng)求之前都是服務(wù)端返回一個(gè)唯一編號(hào)給客戶端，客戶端帶著這個(gè)請(qǐng)求號(hào)做請(qǐng)求，服務(wù)端即可完成去重?cái)r截。

但是，很多的場(chǎng)景下，請(qǐng)求并不會(huì)帶這樣的唯一編號(hào)！那么我們能否針對(duì)請(qǐng)求的參數(shù)作為一個(gè)請(qǐng)求的標(biāo)識(shí)呢？

先考慮簡(jiǎn)單的場(chǎng)景，假設(shè)請(qǐng)求參數(shù)只有一個(gè)字段reqParam，我們可以利用以下標(biāo)識(shí)去判斷這個(gè)請(qǐng)求是否重復(fù)。用戶ID:接口名:請(qǐng)求參數(shù)

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

那么當(dāng)同一個(gè)用戶訪問同一個(gè)接口，帶著同樣的reqParam過來，我們就能定位到他是重復(fù)的了。

但是問題是，我們的接口通常不是這么簡(jiǎn)單，以目前的主流，我們的參數(shù)通常是一個(gè)JSON。那么針對(duì)這種場(chǎng)景，我們?cè)趺慈ブ啬兀?/p>

計(jì)算請(qǐng)求參數(shù)的摘要作為參數(shù)標(biāo)識(shí)

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

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

這樣，請(qǐng)求的唯一標(biāo)識(shí)就打上了！

注：MD5理論上可能會(huì)重復(fù)，但是去重通常是短時(shí)間窗口內(nèi)的去重（例如一秒），一個(gè)短時(shí)間內(nèi)同一個(gè)用戶同樣的接口能拼出不同的參數(shù)導(dǎo)致一樣的MD5幾乎是不可能的。

繼續(xù)優(yōu)化，考慮剔除部分時(shí)間因子

上面的問題其實(shí)已經(jīng)是一個(gè)很不錯(cuò)的解決方案了，但是實(shí)際投入使用的時(shí)候可能發(fā)現(xiàn)有些問題：某些請(qǐng)求用戶短時(shí)間內(nèi)重復(fù)的點(diǎn)擊了（例如1000毫秒發(fā)送了三次請(qǐng)求），但繞過了上面的去重判斷（不同的KEY值）。

原因是這些請(qǐng)求參數(shù)的字段里面，是帶時(shí)間字段的，這個(gè)字段標(biāo)記用戶請(qǐng)求的時(shí)間，服務(wù)端可以借此丟棄掉一些老的請(qǐng)求（例如5秒前）。如下面的例子，請(qǐng)求的其他參數(shù)是一樣的，除了請(qǐng)求時(shí)間相差了一秒：

???//兩個(gè)請(qǐng)求一樣，但是請(qǐng)求時(shí)間差一秒
????String?req?=?"{\n"?+
????????????"\"requestTime\"?:\"20190101120001\",\n"?+
????????????"\"requestValue\"?:\"1000\",\n"?+
????????????"\"requestKey\"?:\"key\"\n"?+
????????????"}";

????String?req2?=?"{\n"?+
????????????"\"requestTime\"?:\"20190101120002\",\n"?+
????????????"\"requestValue\"?:\"1000\",\n"?+
????????????"\"requestKey\"?:\"key\"\n"?+
????????????"}";

這種請(qǐng)求，我們也很可能需要擋住后面的重復(fù)請(qǐng)求。所以求業(yè)務(wù)參數(shù)摘要之前，需要剔除這類時(shí)間字段。還有類似的字段可能是GPS的經(jīng)緯度字段（重復(fù)請(qǐng)求間可能有極小的差別）。

請(qǐng)求去重工具類，Java實(shí)現(xiàn)

public?class?ReqDedupHelper?{

????/**
?????*
?????*?@param?reqJSON?請(qǐng)求的參數(shù)，這里通常是JSON
?????*?@param?excludeKeys?請(qǐng)求參數(shù)里面要去除哪些字段再求摘要
?????*?@return?去除參數(shù)的MD5摘要
?????*/
????public?String?dedupParamMD5(final?String?reqJSON,?String...?excludeKeys)?{
????????String?decreptParam?=?reqJSON;

????????TreeMap?paramTreeMap?=?JSON.parseObject(decreptParam,?TreeMap.class);
????????if?(excludeKeys!=null)?{
????????????List?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;
????}
}

下面是一些測(cè)試日志：

public?static?void?main(String[]?args)?{
????//兩個(gè)請(qǐng)求一樣，但是請(qǐng)求時(shí)間差一秒
????String?req?=?"{\n"?+
????????????"\"requestTime\"?:\"20190101120001\",\n"?+
????????????"\"requestValue\"?:\"1000\",\n"?+
????????????"\"requestKey\"?:\"key\"\n"?+
????????????"}";

????String?req2?=?"{\n"?+
????????????"\"requestTime\"?:\"20190101120002\",\n"?+
????????????"\"requestValue\"?:\"1000\",\n"?+
????????????"\"requestKey\"?:\"key\"\n"?+
????????????"}";

????//全參數(shù)比對(duì)，所以兩個(gè)參數(shù)MD5不同
????String?dedupMD5?=?new?ReqDedupHelper().dedupParamMD5(req);
????String?dedupMD52?=?new?ReqDedupHelper().dedupParamMD5(req2);
????System.out.println("req1MD5?=?"+?dedupMD5+"?,?req2MD5="+dedupMD52);

????//去除時(shí)間參數(shù)比對(duì)，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

日志說明：

• 一開始兩個(gè)參數(shù)由于requestTime是不同的，所以求去重參數(shù)摘要的時(shí)候可以發(fā)現(xiàn)兩個(gè)值是不一樣的
• 第二次調(diào)用的時(shí)候，去除了requestTime再求摘要（第二個(gè)參數(shù)中傳入了”requestTime”），則發(fā)現(xiàn)兩個(gè)摘要是一樣的，符合預(yù)期。

總結(jié)

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

String?userId=?"12345678";//用戶
String?method?=?"pay";//接口名
String?dedupMD5?=?new?ReqDedupHelper().dedupParamMD5(req,"requestTime");//計(jì)算請(qǐng)求參數(shù)摘要，其中剔除里面請(qǐng)求時(shí)間的干擾
String?KEY?=?"dedup:U="?+?userId?+?"M="?+?method?+?"P="?+?dedupMD5;

long?expireTime?=??1000;//?1000毫秒過期，1000ms內(nèi)的重復(fù)請(qǐng)求會(huì)認(rèn)為重復(fù)
long?expireAt?=?System.currentTimeMillis()?+?expireTime;
String?val?=?"expireAt@"?+?expireAt;

//?NOTE:直接SETNX不支持帶過期時(shí)間，所以設(shè)置+過期不是原子操作，極端情況下可能設(shè)置了就不過期了，后面相同請(qǐng)求可能會(huì)誤以為需要去重，所以這里使用底層API，保證SETNX+過期時(shí)間是原子操作
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;
}

---

推薦閱讀：

• 國(guó)內(nèi)首個(gè)比特幣勒索病毒制作者落網(wǎng)，但過程有點(diǎn)好笑
  

• HashMap 最見功底！
  

• Guava - 拯救垃圾代碼，寫出優(yōu)雅高效，效率提升N倍
  

• Oracle慌了！華為終于對(duì)JDK下手了！
  

喜歡我可以給我設(shè)為星標(biāo)哦

好文章，我“在看”