- 利用唯一請求編号去重
- 業務參數去重
- 計算請求參數的摘要作為參數辨別
- 繼續優化,考慮剔除部分時間因子
- 請求去重工具類,Java實作
- 總結
對于一些使用者請求,在某些情況下是可能重複發送的,如果是查詢類操作并無大礙,但其中有些是涉及寫入操作的,一旦重複了,可能會導緻很嚴重的後果,例如交易的接口如果重複請求可能會重複下單。
重複的場景有可能是:
- 黑客攔截了請求,重放
- 前端/用戶端因為某些原因請求重複發送了,或者使用者在很短的時間内重複點選了。
- 網關重發
- ….
本文讨論的是如何在服務端優雅地統一處理這種情況,如何禁止使用者重複點選等用戶端操作不在本文的讨論範疇。
你可能會想到的是,隻要請求有唯一的請求編号,那麼就能借用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。那麼針對這種場景,我們怎麼去重呢?
假設我們把請求參數(JSON)按KEY做升序排序,排序後拼成一個字元串,作為KEY值呢?但這可能非常的長,是以我們可以考慮對這個字元串求一個MD5作為參數的摘要,以這個摘要去取代reqParam的位置。
String KEY = "dedup:U="+userId + "M=" + method + "P=" + reqParamMD5;
這樣,請求的唯一辨別就打上了!
注:MD5理論上可能會重複,但是去重通常是短時間視窗内的去重(例如一秒),一個短時間内同一個使用者同樣的接口能拼出不同的參數導緻一樣的MD5幾乎是不可能的。
上面的問題其實已經是一個很不錯的解決方案了,但是實際投入使用的時候可能發現有些問題:某些請求使用者短時間内重複的點選了(例如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;
}
Java 的知識面非常廣,面試問的涉及也非常廣泛,重點包括:Java 基礎、Java 并發,JVM、、資料結構、算法、Spring、微服務、MQ 等等,涉及的知識點何其龐大,是以我們在複習的時候也往往無從下手,今天小編給大家帶來一套 Java 面試題,題庫非常全面,包括 Java 基礎、Java 集合、JVM、Java 并發、Spring全家桶、、MySQL、Dubbo、Netty、MQ 等等,包含 Java 後端知識點 2000 +
資料擷取方式:關注公衆号:“程式員白楠楠”擷取