如何優雅處理重復請求/并發請求?
前言
一些用戶請求在某些情況下是可能重復發送的,如果是查詢類操作并無大礙,但其中有些涉及寫入操作,一旦重復了,可能會導致很嚴重的后果。例如交易接口如果重復請求,可能會重復下單。
重復的場景有可能是:
- 黑客攔截了請求,重放;
- 前端/客戶端因為某些原因請求重復發送了,或者用戶在很短的時間內重復點擊了;
- 網關重發;
- ……
本文討論的是如何在服務端優雅地統一處理這種情況,如何禁止用戶重復點擊等客戶端操作不在本文的討論范疇。
利用唯一請求編號去重
你可能會想到,只要請求有唯一的請求編號,那么就能借用 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。那么針對這種場景,我們怎么去重呢?
1、計算請求參數的摘要作為參數標識
假設我們把請求參數(JSON)按KEY做升序排序,排序后拼成一個字符串,作為 KEY 值呢?但這可能非常的長,所以我們可以考慮對這個字符串求一個 MD5 作為參數的摘要,以這個摘要去取代 reqParam 的位置。
- String KEY = "dedup:U="+userId + "M=" + method + "P=" + reqParamMD5;
這樣,請求的唯一標識就打上了!
注:MD5 理論上可能會重復,但是去重通常是短時間窗口內的去重(例如一秒),一個短時間內同一個用戶同樣的接口能拼出不同的參數導致一樣的 MD5 幾乎是不可能的。
2、繼續優化,考慮剔除部分時間因子
上面的問題其實已經是一個很不錯的解決方案了,但是實際投入使用的時候可能發現有些問題:某些請求用戶短時間內重復的點擊了(例如 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 的經緯度字段(重復請求間可能有極小的差別)。
請求去重工具類的代碼落地
- 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<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;
- }
【責任編輯:龐桂玉 TEL:(010)68476606】