大家好,我3y啊。由于去重邏輯重構(gòu)了幾次,好多股東直呼看不懂,于是我今天再安排一波對(duì)代碼的解析吧。austin支持兩種去重的類(lèi)型:N分鐘相同內(nèi)容達(dá)到N次去重和一天內(nèi)N次相同渠道頻次去重。
在最開(kāi)始,我的第一版實(shí)現(xiàn)是這樣的:
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ùn)營(yíng)總規(guī)則去重(一天內(nèi)用戶收到最多同一個(gè)渠道的消息次數(shù))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è)入口上了,應(yīng)該都能看得懂。后來(lái),群里滴滴哥表示這種代碼不行,不能一眼看出來(lái)它干了什么。于是怒提了一波pull request重構(gòu)了一版,入口是這樣的:
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);}});}
我猜想他的思路就是把構(gòu)建去重參數(shù)和選擇具體的去重服務(wù)給封裝起來(lái)了,在最外層的代碼看起來(lái)就很簡(jiǎn)潔了。后來(lái)又跟他聊了下,他的設(shè)計(jì)思路是這樣的:考慮到以后會(huì)有其他規(guī)則的去重就把去重邏輯單獨(dú)封裝起來(lái)了,之后用策略模版的設(shè)計(jì)模式進(jìn)行了重構(gòu),重構(gòu)后的代碼 模版不變,支持各種不同策略的去重,擴(kuò)展性更高更強(qiáng)更簡(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);}}}
到這,應(yīng)該大多數(shù)人還能跟上吧?在講具體的代碼之前,我們先來(lái)簡(jiǎn)單看看去重功能的代碼結(jié)構(gòu)(這會(huì)對(duì)后面看代碼有幫助)
去重的邏輯可以統(tǒng)一抽象為:在X時(shí)間段內(nèi)達(dá)到了Y閾值,還記得我曾經(jīng)說(shuō)過(guò):「去重」的本質(zhì):「業(yè)務(wù)Key」+「存儲(chǔ)」。那么去重實(shí)現(xiàn)的步驟可以簡(jiǎn)單分為(我這邊存儲(chǔ)就用的Redis):
通過(guò)Key從Redis獲取記錄判斷該Key在Redis的記錄是否符合條件符合條件的則去重,不符合條件的則重新塞進(jìn)Redis更新記錄為了方便調(diào)整去重的參數(shù),我把X時(shí)間段和Y閾值都放到了配置里{"deduplication_10":{"num":1,"time":300},"deduplication_20":{"num":5}}。目前有兩種去重的具體實(shí)現(xiàn):
1、5分鐘內(nèi)相同用戶如果收到相同的內(nèi)容,則應(yīng)該被過(guò)濾掉
2、一天內(nèi)相同的用戶如果已經(jīng)收到某渠道內(nèi)容5次,則應(yīng)該被過(guò)濾掉
從配置中心拿到配置信息了以后,Builder就是根據(jù)這兩種類(lèi)型去構(gòu)建出DeduplicationParam,就是以下代碼:
DeduplicationParamdeduplicationParam=deduplicationHolder.selectBuilder(deduplicationType).build(deduplicationConfig,taskInfo);
Builder和DeduplicationService都用了類(lèi)似的寫(xiě)法(在子類(lèi)初始化的時(shí)候指定類(lèi)型,在父類(lèi)統(tǒng)一接收,放到Map里管理)
而統(tǒng)一管理著這些服務(wù)有個(gè)中心的地方,我把這取名為DeduplicationHolder
/***@authorhuskey*@date2022/1/18*/@ServicepublicclassDeduplicationHolder{privatefinalMapbuilderHolder=newHashMap<>(4);privatefinalMap serviceHolder=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,是在AbstractDeduplicationService的子類(lèi)下構(gòu)建的:
而具體的去重邏輯實(shí)現(xiàn)則都在LimitService下,{一天內(nèi)相同的用戶如果已經(jīng)收到某渠道內(nèi)容5次}是在SimpleLimitService中處理使用mget和pipelineSetEX就完成了實(shí)現(xiàn)。而{5分鐘內(nèi)相同用戶如果收到相同的內(nèi)容}是在SlideWindowLimitService中處理,使用了lua腳本完成了實(shí)現(xiàn)。
LimitService的代碼都來(lái)源于@caolongxiu的pull request,建議大家可以對(duì)比commit再學(xué)習(xí)一番:https://gitee.com/zhongfucheng/austin/pulls/19
1、頻次去重采用普通的計(jì)數(shù)去重方法,限制的是每天發(fā)送的條數(shù)。
2、內(nèi)容去重采用的是新開(kāi)發(fā)的基于redis中zset的滑動(dòng)窗口去重,可以做到嚴(yán)格控制單位時(shí)間內(nèi)的頻次。
3、redis使用lua腳本來(lái)保證原子性和減少網(wǎng)絡(luò)io的損耗
4、redis的key增加前綴做到數(shù)據(jù)隔離(后期可能有動(dòng)態(tài)更換去重方法的需求)
5、把具體限流去重方法從DeduplicationService抽取出來(lái),DeduplicationService只需設(shè)置構(gòu)造器注入時(shí)注入的AbstractLimitService(具體限流去重服務(wù))類(lèi)型即可動(dòng)態(tài)更換去重的方法 6、使用雪花算法生成zset的唯一value,score使用的是當(dāng)前的時(shí)間戳
針對(duì)滑動(dòng)窗口去重,有會(huì)引申出新的問(wèn)題:limit.lua的邏輯?為什么要移除時(shí)間窗口的之前的數(shù)據(jù)?為什么ARGV[4]參數(shù)要唯一?為什么要expire?
A: 使用滑動(dòng)窗口可以保證N分鐘達(dá)到N次進(jìn)行去重?;瑒?dòng)窗口可以回顧下TCP的,也可以回顧下刷LeetCode時(shí)的一些題,那這為什么要移除,就不陌生了。
為什么ARGV[4]要唯一,具體可以看看zadd這條命令,我們只需要保證每次add進(jìn)窗口內(nèi)的成員是唯一的,那么就不會(huì)觸發(fā)有更新的操作(我認(rèn)為這樣設(shè)計(jì)會(huì)更加簡(jiǎn)單些),而唯一Key用雪花算法比較方便。
為什么expire?,如果這個(gè)key只被調(diào)用一次。那就很有可能在redis內(nèi)存常駐了,expire能避免這種情況。
推薦項(xiàng)目最后再叨叨吧,很多人可能會(huì)發(fā)一段截圖,跑來(lái)問(wèn)我為什么要這樣寫(xiě),為什么要以這種方式實(shí)現(xiàn),能不能以這種方式實(shí)現(xiàn)。這時(shí)候,我更想看到的是:你已經(jīng)實(shí)現(xiàn)了第二種方式了,然后探討你寫(xiě)的這種方案好不好,現(xiàn)有的代碼差在哪里。
畢竟問(wèn)問(wèn)題很簡(jiǎn)單,我又不是客服,總不能沒(méi)誠(chéng)意的問(wèn)題我都得一一回答吧。
如果想學(xué)Java項(xiàng)目的,我還是強(qiáng)烈推薦我的開(kāi)源項(xiàng)目消息推送平臺(tái)Austin,可以用作畢業(yè)設(shè)計(jì),可以用作校招,可以看看生產(chǎn)環(huán)境是怎么推送消息的。
倉(cāng)庫(kù)地址(可點(diǎn)擊閱讀原文跳轉(zhuǎn)):https://gitee.com/zhongfucheng/austin
我開(kāi)通了股東服務(wù)內(nèi)容,感興趣可以點(diǎn)擊下方看看,主要針對(duì)的是項(xiàng)目喲
VIP服務(wù)
關(guān)鍵詞:
參與評(píng)論
- 要聞速遞:解剖屎山,尋覓黃金之第二彈2023-04-22
- 焦點(diǎn)熱門(mén):短手大???/a>2023-04-22
- 世界觀速訊丨調(diào)查顯示澳門(mén)廠商對(duì)未來(lái)6個(gè)月2023-04-22
- 心胸寬廣作文800字(實(shí)用40篇)_全球微速訊2023-04-22
- 網(wǎng)絡(luò)直播為文藝院團(tuán) 打造更廣闊“第二舞臺(tái)2023-04-22
- 涼皮制作方法(涼皮的制作方法與步驟)-天2023-04-22
- 五冶集團(tuán)承攬沙鋼這項(xiàng)大修提前完工,為后續(xù)2023-04-21
- 即將推出 阿爾法羅密歐迷你殺手MiToGTA 2023-04-21
- 世界熱點(diǎn)評(píng)!湖北省二級(jí)建造師系統(tǒng)_湖北省2023-04-21
- 今日歐元/美元匯率走勢(shì)圖分析(4月21日) 2023-04-21
- 全球新消息丨浙江傳媒學(xué)院分?jǐn)?shù)線播音主持類(lèi)2023-04-21
- 智能服裝理論與應(yīng)用_對(duì)于智能服裝理論與應(yīng)2023-04-21
- 單純形表法例題詳解線性規(guī)劃_單純形表_天天2023-04-21
- 烤鴨放一晚上還能吃嗎 烤鴨第二天還能吃嗎2023-04-21
- 【環(huán)球新視野】歐洲房車(chē)錦標(biāo)賽2023-04-21
- 秦剛在“中國(guó)式現(xiàn)代化與世界”藍(lán)廳論壇上發(fā)2023-04-21
- 全球觀速訊丨全志科技4月21日快速反彈2023-04-21
- 天潤(rùn)乳業(yè)擬現(xiàn)金收購(gòu)新農(nóng)乳業(yè)100%股權(quán)_速讀2023-04-21
- 關(guān)注:國(guó)脈科技:4月21日召開(kāi)董事會(huì)會(huì)議2023-04-21
- 環(huán)球焦點(diǎn)!以賽代訓(xùn)!京城家庭照護(hù)員開(kāi)展“2023-04-21
- 貨拉拉客服電話人工服務(wù)電話_分期樂(lè)客服人2023-04-21
- 愛(ài)爾蘭官員:監(jiān)管機(jī)構(gòu)得先了解AIGC,而不是2023-04-21
- 山東省濰坊市發(fā)布大風(fēng)黃色預(yù)警2023-04-21
- 西外環(huán)高速路燈照明工程獲批 今年6月30日2023-04-21
- 歧路亡羊的故事概括100字 歧路亡羊的故事2023-04-21
- 【報(bào)資訊】數(shù)字經(jīng)濟(jì)+AI拉動(dòng)數(shù)據(jù)算力增長(zhǎng)2023-04-21
- 《最終幻想16》首部預(yù)告與近期對(duì)比:視覺(jué)效2023-04-21
- 非遺印象|六代匠人傳承老山砂罐燒制技藝 2023-04-21
- 1165個(gè)村落列入四川傳統(tǒng)村落名錄2023-04-21
- 深圳樓市突傳大消息!究竟真相如何? 環(huán)球2023-04-21