（給ImportNew加星標，提高Java技能）
利用唯一請求編號去重
業務參數去重
計算請求參數的摘要作為參數標識
繼續優化，考慮剔除部分時間因子
請求去重工具類，Java實現
總結
對於一些用戶請求，在某些情況下是可能重複發送的，如果是查詢類操作並無大礙，但其中有些是涉及寫入操作的，一旦重複了，可能會導致很嚴重的後果，例如交易的接口如果重複請求可能會重複下單。
重複的場景有可能是：
黑客攔截了請求，重放
前端/客戶端因為某些原因請求重複發送了，或者用戶在很短的時間內重複點擊了
網關重發
….
本文討論的是如何在服務端優雅地統一處理這種情況，如何禁止用戶重複點擊等客戶端操作不在本文的討論範疇。可能會想到的是，只要請求有唯一的請求編號，那麼就能借用Redis做這個去重——只要這個唯一請求編號在redis存在，證明處理過，那麼就認為是重複的
StringKEY="REQ12343456788";//請求唯一編號longexpireTime=1000;//1000毫秒過期，1000ms內的重複請求會認為重複longexpireAt=System.currentTimeMillis()+expireTime;Stringval="expireAt@"+expireAt;//rediskey還存在的話要就認為請求是重複的BooleanfirstSet=stringRedisTemplate.execute((RedisCallback<Boolean>)connection->connection.set(KEY.getBytes(),val.getBytes(),Expiration.milliseconds(expireTime),RedisStringCommands.SetOption.SET_IF_ABSENT));finalbooleanisConsiderDup;if(firstSet!=null&&firstSet){//第一次訪問isConsiderDup=false;}else{//redis值已存在，認為是重複了isConsiderDup=true;}上面的方案能解決具備唯一請求編號的場景，例如每次寫請求之前都是服務端返回一個唯一編號給客戶端，客戶端帶着這個請求號做請求，服務端即可完成去重攔截。
但是，很多的場景下，請求並不會帶這樣的唯一編號！那麼我們能否針對請求的參數作為一個請求的標識呢？先考慮簡單的場景，假設請求參數只有一個字段reqParam，我們可以利用以下標識去判斷這個請求是否重複。用戶ID:接口名:請求參數StringKEY="dedup:U="+userId+"M="+method+"P="+reqParam;那麼當同一個用戶訪問同一個接口，帶着同樣的reqParam過來，我們就能定位到他是重複的了。但是問題是，我們的接口通常不是這麼簡單，以目前的主流，我們的參數通常是一個JSON。那麼針對這種場景，我們怎麼去重呢？| 計算請求參數的摘要作為參數標識假設我們把請求參數（JSON）按KEY做升序排序，排序後拼成一個字符串，作為KEY值呢？但這可能非常的長，所以我們可以考慮對這個字符串求一個MD5作為參數的摘要，以這個摘要去取代reqParam的位置。StringKEY="dedup:U="+userId+"M="+method+"P="+reqParamMD5;
這樣，請求的唯一標識就打上了！
註：MD5理論上可能會重複，但是去重通常是短時間窗口內的去重（例如一秒），一個短時間內同一個用戶同樣的接口能拼出不同的參數導致一樣的MD5幾乎是不可能的。| 繼續優化，考慮剔除部分時間因子上面的問題其實已經是一個很不錯的解決方案了，但是實際投入使用的時候可能發現有些問題：某些請求用戶短時間內重複的點擊了（例如1000毫秒發送了三次請求），但繞過了上面的去重判斷（不同的KEY值）。
原因是這些請求參數的字段裡面，是帶時間字段的，這個字段標記用戶請求的時間，服務端可以藉此丟棄掉一些老的請求（例如5秒前）。如下面的例子，請求的其他參數是一樣的，除了請求時間相差了一秒：
//兩個請求一樣，但是請求時間差一秒Stringreq="{\n"+"\"requestTime\":\"20190101120001\",\n"+"\"requestValue\":\"1000\",\n"+"\"requestKey\":\"key\"\n"+"}";Stringreq2="{\n"+"\"requestTime\":\"20190101120002\",\n"+"\"requestValue\":\"1000\",\n"+"\"requestKey\":\"key\"\n"+"}";這種請求，我們也很可能需要擋住後面的重複請求。所以求業務參數摘要之前，需要剔除這類時間字段。還有類似的字段可能是GPS的經緯度字段（重複請求間可能有極小的差別）。publicclassReqDedupHelper{/****@paramreqJSON請求的參數，這裡通常是JSON*@paramexcludeKeys請求參數裡面要去除哪些字段再求摘要*@return去除參數的MD5摘要*/publicStringdedupParamMD5(finalStringreqJSON,String...excludeKeys){StringdecreptParam=reqJSON;TreeMapparamTreeMap=JSON.parseObject(decreptParam,TreeMap.class);if(excludeKeys!=null){List<String>dedupExcludeKeys=Arrays.asList(excludeKeys);if(!dedupExcludeKeys.isEmpty()){for(StringdedupExcludeKey:dedupExcludeKeys){paramTreeMap.remove(dedupExcludeKey);}}}StringparamTreeMapJSON=JSON.toJSONString(paramTreeMap);Stringmd5deDupParam=jdkMD5(paramTreeMapJSON);log.debug("md5deDupParam={},excludeKeys={}{}",md5deDupParam,Arrays.deepToString(excludeKeys),paramTreeMapJSON);returnmd5deDupParam;}privatestaticStringjdkMD5(Stringsrc){Stringres=null;try{MessageDigestmessageDigest=MessageDigest.getInstance("MD5");byte[]mdBytes=messageDigest.digest(src.getBytes());res=DatatypeConverter.printHexBinary(mdBytes);}catch(Exceptione){log.error("",e);}returnres;}}下面是一些測試日誌：
publicstaticvoidmain(String[]args){//兩個請求一樣，但是請求時間差一秒Stringreq="{\n"+"\"requestTime\":\"20190101120001\",\n"+"\"requestValue\":\"1000\",\n"+"\"requestKey\":\"key\"\n"+"}";Stringreq2="{\n"+"\"requestTime\":\"20190101120002\",\n"+"\"requestValue\":\"1000\",\n"+"\"requestKey\":\"key\"\n"+"}";//全參數比對，所以兩個參數MD5不同StringdedupMD5=newReqDedupHelper().dedupParamMD5(req);StringdedupMD52=newReqDedupHelper().dedupParamMD5(req2);System.out.println("req1MD5="+dedupMD5+",req2MD5="+dedupMD52);//去除時間參數比對，MD5相同StringdedupMD53=newReqDedupHelper().dedupParamMD5(req,"requestTime");StringdedupMD54=newReqDedupHelper().dedupParamMD5(req2,"requestTime");System.out.println("req1MD5="+dedupMD53+",req2MD5="+dedupMD54);}req1MD5=9E054D36439EBDD0604C5E65EB5C8267,req2MD5=A2D20BAC78551C4CA09BEF97FE468A3Freq1MD5=C2A36FED15128E9E878583CAAAFEFDE9,req2MD5=C2A36FED15128E9E878583CAAAFEFDE9日誌說明：
一開始兩個參數由於requestTime是不同的，所以求去重參數摘要的時候可以發現兩個值是不一樣的第二次調用的時候，去除了requestTime再求摘要（第二個參數中傳入了」requestTime」），則發現兩個摘要是一樣的，符合預期。StringuserId="12345678";//用戶Stringmethod="pay";//接口名StringdedupMD5=newReqDedupHelper().dedupParamMD5(req,"requestTime");//計算請求參數摘要，其中剔除裡面請求時間的干擾StringKEY="dedup:U="+userId+"M="+method+"P="+dedupMD5;longexpireTime=1000;//1000毫秒過期，1000ms內的重複請求會認為重複longexpireAt=System.currentTimeMillis()+expireTime;Stringval="expireAt@"+expireAt;//NOTE:直接SETNX不支持帶過期時間，所以設置+過期不是原子操作，極端情況下可能設置了就不過期了，後面相同請求可能會誤以為需要去重，所以這裡使用底層API，保證SETNX+過期時間是原子操作BooleanfirstSet=stringRedisTemplate.execute((RedisCallback<Boolean>)connection->connection.set(KEY.getBytes(),val.getBytes(),Expiration.milliseconds(expireTime),RedisStringCommands.SetOption.SET_IF_ABSENT));finalbooleanisConsiderDup;if(firstSet!=null&&firstSet){isConsiderDup=false;}else{isConsiderDup=true;}轉自：薛定諤的風口豬
鏈接：https://jaskey.github.io/blog/2020/05/19/handle-duplicate-request/
- EOF -
Spring Cloud Stream整合Rabbit之重複投遞
消息隊列面試連環問：如何保證消息不丟失？處理重複消息？消息有序性？消息堆積處理？
看完本文有收穫？請轉發分享給更多人
關注「ImportNew」，提升Java技能
點讚和在看就是最大的支持❤️
留言列表