天天滾動(dòng):解剖屎山，尋覓黃金之第二彈

大家好，我3y啊。由于去重邏輯重構了幾次，好多股東直呼看不懂，于是我今天再安排一波對代碼的解析吧。austin支持兩種去重的類(lèi)型：N分鐘相同內容達到N次去重和一天內N次相同渠道頻次去重。

(資料圖)

在最開(kāi)始，我的第一版實(shí)現是這樣的：

publicvoidduplication(TaskInfotaskInfo){//配置示例:{"contentDeduplication":{"num":1,"time":300},"frequencyDeduplication":{"num":5}}JSONObjectproperty=JSON.parseObject(config.getProperty(DEDUPLICATION_RULE_KEY,AustinConstant.APOLLO_DEFAULT_VALUE_JSON_OBJECT));JSONObjectcontentDeduplication=property.getJSONObject(CONTENT_DEDUPLICATION);JSONObjectfrequencyDeduplication=property.getJSONObject(FREQUENCY_DEDUPLICATION);//文案去重DeduplicationParamcontentParams=DeduplicationParam.builder().deduplicationTime(contentDeduplication.getLong(TIME)).countNum(contentDeduplication.getInteger(NUM)).taskInfo(taskInfo).anchorState(AnchorState.CONTENT_DEDUPLICATION).build();contentDeduplicationService.deduplication(contentParams);//運營(yíng)總規則去重(一天內用戶(hù)收到最多同一個(gè)渠道的消息次數)Longseconds=(DateUtil.endOfDay(newDate()).getTime()-DateUtil.current())/1000;DeduplicationParambusinessParams=DeduplicationParam.builder().deduplicationTime(seconds).countNum(frequencyDeduplication.getInteger(NUM)).taskInfo(taskInfo).anchorState(AnchorState.RULE_DEDUPLICATION).build();frequencyDeduplicationService.deduplication(businessParams);}

那時(shí)候很簡(jiǎn)單，基本主體邏輯都寫(xiě)在這個(gè)入口上了，應該都能看得懂。后來(lái)，群里滴滴哥表示這種代碼不行，不能一眼看出來(lái)它干了什么。于是怒提了一波pull request重構了一版，入口是這樣的：

publicvoidduplication(TaskInfotaskInfo){//配置樣例：{"contentDeduplication":{"num":1,"time":300},"frequencyDeduplication":{"num":5}}Stringdeduplication=config.getProperty(DeduplicationConstants.DEDUPLICATION_RULE_KEY,AustinConstant.APOLLO_DEFAULT_VALUE_JSON_OBJECT);//去重DEDUPLICATION_LIST.forEach(key->{DeduplicationParamdeduplicationParam=builderFactory.select(key).build(deduplication,key);if(deduplicationParam!=null){deduplicationParam.setTaskInfo(taskInfo);DeduplicationServicededuplicationService=findService(key+SERVICE);deduplicationService.deduplication(deduplicationParam);}});}

我猜想他的思路就是把構建去重參數和選擇具體的去重服務(wù)給封裝起來(lái)了，在最外層的代碼看起來(lái)就很簡(jiǎn)潔了。后來(lái)又跟他聊了下，他的設計思路是這樣的：考慮到以后會(huì )有其他規則的去重就把去重邏輯單獨封裝起來(lái)了，之后用策略模版的設計模式進(jìn)行了重構，重構后的代碼 模版不變，支持各種不同策略的去重，擴展性更高更強更簡(jiǎn)潔

確實(shí)牛逼。

我基于上面的思路微改了下入口，代碼最終演變成這樣：

publicvoidduplication(TaskInfotaskInfo){//配置樣例：{"deduplication_10":{"num":1,"time":300},"deduplication_20":{"num":5}}StringdeduplicationConfig=config.getProperty(DEDUPLICATION_RULE_KEY,CommonConstant.EMPTY_JSON_OBJECT);//去重ListdeduplicationList=DeduplicationType.getDeduplicationList();for(IntegerdeduplicationType:deduplicationList){DeduplicationParamdeduplicationParam=deduplicationHolder.selectBuilder(deduplicationType).build(deduplicationConfig,taskInfo);if(Objects.nonNull(deduplicationParam)){deduplicationHolder.selectService(deduplicationType).deduplication(deduplicationParam);}}}

到這，應該大多數人還能跟上吧？在講具體的代碼之前，我們先來(lái)簡(jiǎn)單看看去重功能的代碼結構（這會(huì )對后面看代碼有幫助）

去重的邏輯可以統一抽象為：在X時(shí)間段內達到了Y閾值，還記得我曾經(jīng)說(shuō)過(guò)：「去重」的本質(zhì)：「業(yè)務(wù)Key」+「存儲」。那么去重實(shí)現的步驟可以簡(jiǎn)單分為（我這邊存儲就用的Redis）：

為了方便調整去重的參數，我把X時(shí)間段和Y閾值都放到了配置里{"deduplication_10":{"num":1,"time":300},"deduplication_20":{"num":5}}。目前有兩種去重的具體實(shí)現：

1、5分鐘內相同用戶(hù)如果收到相同的內容，則應該被過(guò)濾掉

2、一天內相同的用戶(hù)如果已經(jīng)收到某渠道內容5次，則應該被過(guò)濾掉

從配置中心拿到配置信息了以后，Builder就是根據這兩種類(lèi)型去構建出DeduplicationParam，就是以下代碼：

DeduplicationParamdeduplicationParam=deduplicationHolder.selectBuilder(deduplicationType).build(deduplicationConfig,taskInfo);

Builder和DeduplicationService都用了類(lèi)似的寫(xiě)法（在子類(lèi)初始化的時(shí)候指定類(lèi)型，在父類(lèi)統一接收，放到Map里管理）

而統一管理著(zhù)這些服務(wù)有個(gè)中心的地方，我把這取名為DeduplicationHolder

/***@authorhuskey*@date2022/1/18*/@ServicepublicclassDeduplicationHolder{privatefinalMapbuilderHolder=newHashMap<>(4);privatefinalMapserviceHolder=newHashMap<>(4);publicBuilderselectBuilder(Integerkey){returnbuilderHolder.get(key);}publicDeduplicationServiceselectService(Integerkey){returnserviceHolder.get(key);}publicvoidputBuilder(Integerkey,Builderbuilder){builderHolder.put(key,builder);}publicvoidputService(Integerkey,DeduplicationServiceservice){serviceHolder.put(key,service);}}

前面提到的業(yè)務(wù)Key，是在A(yíng)bstractDeduplicationService的子類(lèi)下構建的：

而具體的去重邏輯實(shí)現則都在LimitService下，{一天內相同的用戶(hù)如果已經(jīng)收到某渠道內容5次}是在SimpleLimitService中處理使用mget和pipelineSetEX就完成了實(shí)現。而{5分鐘內相同用戶(hù)如果收到相同的內容}是在SlideWindowLimitService中處理，使用了lua腳本完成了實(shí)現。

LimitService的代碼都來(lái)源于@caolongxiu的pull request，建議大家可以對比commit再學(xué)習一番：https://gitee.com/zhongfucheng/austin/pulls/19

1、頻次去重采用普通的計數去重方法，限制的是每天發(fā)送的條數。

2、內容去重采用的是新開(kāi)發(fā)的基于redis中zset的滑動(dòng)窗口去重，可以做到嚴格控制單位時(shí)間內的頻次。

3、redis使用lua腳本來(lái)保證原子性和減少網(wǎng)絡(luò )io的損耗

4、redis的key增加前綴做到數據隔離（后期可能有動(dòng)態(tài)更換去重方法的需求）

5、把具體限流去重方法從DeduplicationService抽取出來(lái)，DeduplicationService只需設置構造器注入時(shí)注入的AbstractLimitService（具體限流去重服務(wù)）類(lèi)型即可動(dòng)態(tài)更換去重的方法 6、使用雪花算法生成zset的唯一value,score使用的是當前的時(shí)間戳

針對滑動(dòng)窗口去重，有會(huì )引申出新的問(wèn)題：limit.lua的邏輯？為什么要移除時(shí)間窗口的之前的數據？為什么ARGV[4]參數要唯一？為什么要expire？

A: 使用滑動(dòng)窗口可以保證N分鐘達到N次進(jìn)行去重?；瑒?dòng)窗口可以回顧下TCP的，也可以回顧下刷LeetCode時(shí)的一些題，那這為什么要移除，就不陌生了。

為什么ARGV[4]要唯一，具體可以看看zadd這條命令，我們只需要保證每次add進(jìn)窗口內的成員是唯一的，那么就不會(huì )觸發(fā)有更新的操作（我認為這樣設計會(huì )更加簡(jiǎn)單些），而唯一Key用雪花算法比較方便。

為什么expire？，如果這個(gè)key只被調用一次。那就很有可能在redis內存常駐了，expire能避免這種情況。

最后再叨叨吧，很多人可能會(huì )發(fā)一段截圖，跑來(lái)問(wèn)我為什么要這樣寫(xiě)，為什么要以這種方式實(shí)現，能不能以這種方式實(shí)現。這時(shí)候，我更想看到的是：你已經(jīng)實(shí)現了第二種方式了，然后探討你寫(xiě)的這種方案好不好，現有的代碼差在哪里。

畢竟問(wèn)問(wèn)題很簡(jiǎn)單，我又不是客服，總不能沒(méi)誠意的問(wèn)題我都得一一回答吧。

如果想學(xué)Java項目的，我還是強烈推薦我的開(kāi)源項目消息推送平臺Austin，可以用作畢業(yè)設計，可以用作校招，可以看看生產(chǎn)環(huán)境是怎么推送消息的。

倉庫地址（可點(diǎn)擊閱讀原文跳轉）：https://gitee.com/zhongfucheng/austin

我開(kāi)通了股東服務(wù)內容，感興趣可以點(diǎn)擊下方看看，主要針對的是項目喲

VIP服務(wù)

標簽：