解剖屎山,寻觅黄金之第二弹 天天通讯

2024-9-21 05:18:29来源:程序员客栈

大家好,我3y啊。由于去重【chóng】逻【luó】辑重构【gòu】了几次,好多股东直呼看不懂,于是我今天再安排一波对代【dài】码的【de】解【jiě】析吧。austin支持两种去重【chóng】的类型:N分钟相同内【nèi】容达到N次去【qù】重【chóng】和一【yī】天内N次相同渠道频次【cì】去重。

在最开始,我的第一版实现是这样的:


(资料图片仅供参考)

publicvoidduplication(TaskInfotaskInfo){//配【pèi】置【zhì】示例:{"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);//运营总【zǒng】规【guī】则去重(一天内用户收到【dào】最多同【tóng】一【yī】个渠道的消【xiāo】息次数)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);}

那时候很简单,基【jī】本主体逻辑都写在【zài】这个【gè】入口上了【le】,应该都能看【kàn】得【dé】懂。后【hòu】来,群里滴滴【dī】哥表示这种代码不行,不能【néng】一眼看出来它干了什么【me】。于是怒提了一波pull request重构了一版【bǎn】,入口是这样的:

publicvoidduplication(TaskInfotaskInfo){//配【pèi】置【zhì】样例:{"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);}});}

我猜【cāi】想他的【de】思路就是把构建去重参数和选【xuǎn】择具体【tǐ】的去重【chóng】服【fú】务给【gěi】封【fēng】装起【qǐ】来了,在【zài】最【zuì】外【wài】层【céng】的【de】代码【mǎ】看起来就很简洁了。后【hòu】来又【yòu】跟他聊了下,他的设计思路【lù】是这样的:考【kǎo】虑到以后会有【yǒu】其他规则的去【qù】重就【jiù】把去重逻辑单独封装起来了,之【zhī】后用策略模版的设计模式进行了重【chóng】构,重构后的代码 模版不变,支持各种不同策略【luè】的去重,扩展性更高更强更简洁【jié】

确实牛逼。

我基于上面的思路微改了下入口,代码最终演变成这样:

publicvoidduplication(TaskInfotaskInfo){//配置【zhì】样例:{"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);}}}

到这,应该大多【duō】数人还能跟上吧?在讲具体的代码之【zhī】前,我们先来简单看看【kàn】去【qù】重功【gōng】能的代【dài】码结构(这会对后【hòu】面【miàn】看代码有帮助)

去【qù】重的逻辑可以统【tǒng】一抽象为:在X时间【jiān】段内【nèi】达到了Y阈【yù】值,还记得我曾经说过【guò】:「去重」的本【běn】质【zhì】:「业务Key」+「存储」。那么【me】去重实现的步骤可以【yǐ】简单分为(我这边存储就用的Redis):

通过Key从Redis获取记【jì】录判断该Key在Redis的记【jì】录是【shì】否符【fú】合条件符合条【tiáo】件的则【zé】去重,不符合条件的则【zé】重【chóng】新塞【sāi】进Redis更新记录

为了方便调整去重的参数【shù】,我把X时【shí】间段和Y阈值都放到了配置里【lǐ】{"deduplication_10":{"num":1,"time":300},"deduplication_20":{"num":5}}。目前有两【liǎng】种去重的【de】具体实现:

1、5分钟内相同用户如果收到相同的内容,则应该被过滤掉

2、一天内相同的用户【hù】如果已经【jīng】收到某渠道【dào】内容5次,则【zé】应【yīng】该【gāi】被过滤掉

从【cóng】配置中心拿到配置信息了以【yǐ】后,Builder就是【shì】根据【jù】这两种类【lèi】型去构【gòu】建出DeduplicationParam,就是以【yǐ】下代码:

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

Builder和DeduplicationService都用【yòng】了类【lèi】似的写法(在子类初始化的时候指定类型,在父类【lèi】统一接收【shōu】,放【fàng】到Map里管理)

而统一管理着这些服务有【yǒu】个【gè】中【zhōng】心的地【dì】方,我把这取【qǔ】名为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);}}

前面【miàn】提到的业务【wù】Key,是在AbstractDeduplicationService的子类下构建的【de】:

而【ér】具体的去【qù】重逻辑实现则都【dōu】在LimitService下,{一天内相同的用户如【rú】果已【yǐ】经收到某渠道内容5次}是在SimpleLimitService中处理使用mget和pipelineSetEX就完成了【le】实现。而【ér】{5分【fèn】钟内相同用户如【rú】果收到相同的内容【róng】}是在SlideWindowLimitService中处理【lǐ】,使【shǐ】用了【le】lua脚【jiǎo】本完成了实现。

LimitService的代码【mǎ】都来源于@caolongxiu的pull request,建【jiàn】议大家【jiā】可以对比commit再学习一番:https://gitee.com/zhongfucheng/austin/pulls/19

1、频次去重采用普通的计数去重方法,限制的是每天发送的条数。

2、内容【róng】去【qù】重采【cǎi】用的是新开发的基于redis中zset的滑【huá】动窗口去重,可以做到严格【gé】控制单【dān】位时间内的【de】频次。

3、redis使用lua脚本来保证原子性和减少网络io的损耗

4、redis的key增加前【qián】缀做【zuò】到数据隔离(后期【qī】可能【néng】有动态更换去重方法的需求)

5、把具体【tǐ】限流去重方【fāng】法从DeduplicationService抽取出来,DeduplicationService只【zhī】需设【shè】置构造器【qì】注入时【shí】注入的AbstractLimitService(具体限流去【qù】重【chóng】服务【wù】)类型即可【kě】动态更换去重的方法【fǎ】 6、使用雪花算法生成zset的唯一value,score使用的是当前【qián】的时间【jiān】戳

针对滑动窗口去重【chóng】,有会【huì】引申出新的问【wèn】题:limit.lua的逻辑【jí】?为什么要【yào】移除【chú】时间窗口【kǒu】的【de】之前的数据?为什【shí】么ARGV[4]参数要唯一?为什【shí】么要expire?

A: 使用滑动窗口可以保证N分钟达到【dào】N次进【jìn】行去重。滑【huá】动窗【chuāng】口可以回顾下TCP的,也可以回【huí】顾下刷LeetCode时【shí】的一【yī】些题,那这为什么要【yào】移除,就不陌生了。

为什么ARGV[4]要【yào】唯一,具体可以看【kàn】看zadd这条命令,我们只需【xū】要保【bǎo】证【zhèng】每次add进窗口内的成员【yuán】是【shì】唯一的【de】,那么就不会触发【fā】有【yǒu】更新的【de】操作(我认为这样【yàng】设计【jì】会更【gèng】加简单些),而【ér】唯一Key用雪花算法比较方便。

为什【shí】么expire?,如果这个key只被调用一次。那就很有可【kě】能在【zài】redis内存常【cháng】驻【zhù】了,expire能【néng】避免这种情况。

推荐项目

最后再叨叨【dāo】吧,很【hěn】多人可能会【huì】发一段截图【tú】,跑【pǎo】来问我【wǒ】为什么【me】要这样【yàng】写,为什么【me】要【yào】以这种方式实现,能不能以这种方【fāng】式实现。这时候,我【wǒ】更【gèng】想【xiǎng】看到的是:你【nǐ】已经实现了第二种方式了,然后探讨【tǎo】你写的这种方案【àn】好不好,现有【yǒu】的代码差在哪里。

毕竟问问题很简【jiǎn】单,我又不是客【kè】服,总不能没诚意的【de】问题我都【dōu】得一一回答吧。

如【rú】果想学Java项目的,我还是【shì】强烈推荐【jiàn】我的开【kāi】源项【xiàng】目消息【xī】推送平台Austin,可以用作毕业设计,可以用作校【xiào】招,可以【yǐ】看看生产【chǎn】环【huán】境是怎么推送消息的【de】。

仓库【kù】地【dì】址(可点击阅读原文跳【tiào】转):https://gitee.com/zhongfucheng/austin

我开通了股东服【fú】务【wù】内【nèi】容,感兴趣可以点击下方【fāng】看看,主要针对的是项【xiàng】目哟

VIP服务

为你推荐

最新资讯

股票软件