Java實現(xiàn)10萬+并發(fā)去重，持續(xù)優(yōu)化！
來源：jaskey.github.io/blog/2020/05/19/handle-duplicate-request/
利用唯一請求編號去重
業(yè)務參數(shù)去重
計算請求參數(shù)的摘要作為參數(shù)標識
繼續(xù)優(yōu)化，考慮剔除部分時間因子
請求Redis去重工具類 + Java實現(xiàn)
對于一些用戶請求，在某些情況下是可能重復發(fā)送的，如果是查詢類操作并無大礙，但其中有些是涉及寫入操作的，一旦重復了，可能會導致很嚴重的后果，例如交易的接口如果重復請求可能會重復下單。
重復的場景有可能是：
黑客攔截了請求，重放
前端/客戶端因為某些原因請求重復發(fā)送了，或者用戶在很短的時間內(nèi)重復點擊
網(wǎng)關重發(fā)
….
本文討論的是如何在服務端優(yōu)雅地統(tǒng)一處理這種情況，如何禁止用戶重復點擊等客戶端操作不在本文的討論范疇。
利用唯一請求編號去重
可能會想到的是，只要請求有唯一的請求編號，那么就能借用Redis做這個去重——只要這個唯一請求編號在redis存在，證明處理過，那么就認為是重復的
代碼大概如下：
String KEY = "REQ12343456788";//請求唯一編號long expireTime = 1000;// 1000毫秒過期，1000ms內(nèi)的重復請求會認為重復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;}
業(yè)務參數(shù)去重
上面的方案能解決具備唯一請求編號的場景，例如每次寫請求之前都是服務端返回一個唯一編號給客戶端，客戶端帶著這個請求號做請求，服務端即可完成去重攔截。
但是，很多的場景下，請求并不會帶這樣的唯一編號！那么我們能否針對請求的參數(shù)作為一個請求的標識呢？
先考慮簡單的場景，假設請求參數(shù)只有一個字段reqParam，我們可以利用以下標識去判斷這個請求是否重復。用戶ID:接口名:請求參數(shù)
String KEY = "dedup:U="+userId + "M=" + method + "P=" + reqParam;那么當同一個用戶訪問同一個接口，帶著同樣的reqParam過來，我們就能定位到他是重復的了。
但是問題是，我們的接口通常不是這么簡單，以目前的主流，我們的參數(shù)通常是一個JSON。那么針對這種場景，我們怎么去重呢？
計算請求參數(shù)的摘要作為參數(shù)標識
假設我們把請求參數(shù)（JSON）按KEY做升序排序，排序后拼成一個字符串，作為KEY值呢？但這可能非常的長，所以我們可以考慮對這個字符串求一個MD5作為參數(shù)的摘要，以這個摘要去取代reqParam的位置。
String KEY = "dedup:U="+userId + "M=" + method + "P=" + reqParamMD5;這樣，請求的唯一標識就打上了！
注：MD5理論上可能會重復，但是去重通常是短時間窗口內(nèi)的去重（例如一秒），一個短時間內(nèi)同一個用戶同樣的接口能拼出不同的參數(shù)導致一樣的MD5幾乎是不可能的。
繼續(xù)優(yōu)化，考慮剔除部分時間因子
//兩個請求一樣，但是請求時間差一秒String req = "{\n" +"\"requestTime\" :\"20190101120001\",\n" +"\"requestValue\" :\"1000\",\n" +"\"requestKey\" :\"key\"\n" +????????????"}";String req2 = "{\n" +"\"requestTime\" :\"20190101120002\",\n" +"\"requestValue\" :\"1000\",\n" +"\"requestKey\" :\"key\"\n" +"}";
這種請求，我們也很可能需要擋住后面的重復請求。所以求業(yè)務參數(shù)摘要之前，需要剔除這類時間字段。還有類似的字段可能是GPS的經(jīng)緯度字段（重復請求間可能有極小的差別）。
public?class?ReqDedupHelper?{/**** @param reqJSON 請求的參數(shù)，這里通常是JSON* @param excludeKeys 請求參數(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<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" +????????????"}";//全參數(shù)比對，所以兩個參數(shù)MD5不同String dedupMD5 = new ReqDedupHelper().dedupParamMD5(req);String dedupMD52 = new ReqDedupHelper().dedupParamMD5(req2);????System.out.println("req1MD5?=?"+?dedupMD5+"?,?req2MD5="+dedupMD52);//去除時間參數(shù)比對，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=A2D20BAC78551C4CA09BEF97FE468A3Freq1MD5 = C2A36FED15128E9E878583CAAAFEFDE9 , req2MD5=C2A36FED15128E9E878583CAAAFEFDE9
日志說明：
一開始兩個參數(shù)由于requestTime是不同的，所以求去重參數(shù)摘要的時候可以發(fā)現(xiàn)兩個值是不一樣的
第二次調(diào)用的時候，去除了requestTime再求摘要（第二個參數(shù)中傳入了”requestTime”），則發(fā)現(xiàn)兩個摘要是一樣的，符合預期。
總結(jié)
至此，我們可以得到完整的去重解決方案，如下：
String userId= "12345678";//用戶String method = "pay";//接口名String dedupMD5 = new ReqDedupHelper().dedupParamMD5(req,"requestTime");//計算請求參數(shù)摘要，其中剔除里面請求時間的干擾String?KEY?=?"dedup:U="?+?userId?+?"M="?+?method?+?"P="?+?dedupMD5;long expireTime = 1000;// 1000毫秒過期，1000ms內(nèi)的重復請求會認為重復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;}
全棧架構(gòu)社區(qū)交流群
?「全棧架構(gòu)社區(qū)」建立了讀者架構(gòu)師交流群，大家可以添加小編微信進行加群。歡迎有想法、樂于分享的朋友們一起交流學習。