建站
咨詢
售后
建站咨詢
新聞中心
[[406095]]
前言
一些用戶請(qǐng)求在某些情況下是可能重復(fù)發(fā)送的，如果是查詢類操作并無大礙，但其中有些涉及寫入操作，一旦重復(fù)了，可能會(huì)導(dǎo)致很嚴(yán)重的后果。例如交易接口如果重復(fù)請(qǐng)求，可能會(huì)重復(fù)下單。
我們提供的服務(wù)有：成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、微信公眾號(hào)開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、文山州ssl等。為成百上千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的文山州網(wǎng)站制作公司
重復(fù)的場(chǎng)景有可能是：
- 黑客攔截了請(qǐng)求，重放；
- 前端/客戶端因?yàn)槟承┰蛘?qǐng)求重復(fù)發(fā)送了，或者用戶在很短的時(shí)間內(nèi)重復(fù)點(diǎn)擊了；
- 網(wǎng)關(guān)重發(fā)；
- ……
本文討論的是如何在服務(wù)端優(yōu)雅地統(tǒng)一處理這種情況，如何禁止用戶重復(fù)點(diǎn)擊等客戶端操作不在本文的討論范疇。
利用唯一請(qǐng)求編號(hào)去重
你可能會(huì)想到，只要請(qǐng)求有唯一的請(qǐng)求編號(hào)，那么就能借用 Redis 做去重。只要這個(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>
1、計(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 幾乎是不可能的。
2、繼續(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)求去重工具類的代碼落地
- 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;
- }
【責(zé)任編輯：龐桂玉 TEL：（010）68476606】
當(dāng)前名稱：如何優(yōu)雅處理重復(fù)請(qǐng)求/并發(fā)請(qǐng)求？
網(wǎng)頁網(wǎng)址：http://m.fisionsoft.com.cn/article/ccehgeh.html
