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

大家好【hǎo】，我3y啊。由于去重逻辑【jí】重构【gòu】了【le】几次，好多股东直呼看不【bú】懂，于是我今天再安排【pái】一【yī】波对代码【mǎ】的解析【xī】吧【ba】。austin支持两种去重的类【lèi】型：N分钟相同内容达到N次去重和【hé】一天内N次相同渠【qú】道【dào】频【pín】次【cì】去重。

在最开始，我的第一版实现是这样的：

(资料图片仅供参考)

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);//文案去【qù】重【chóng】DeduplicationParamcontentParams=DeduplicationParam.builder().deduplicationTime(contentDeduplication.getLong(TIME)).countNum(contentDeduplication.getInteger(NUM)).taskInfo(taskInfo).anchorState(AnchorState.CONTENT_DEDUPLICATION).build();contentDeduplicationService.deduplication(contentParams);//运营总规【guī】则去重【chóng】(一天内用户收到【dào】最多【duō】同一个渠道的消息【xī】次数)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);}

那时候很简单，基本主体【tǐ】逻【luó】辑都写【xiě】在这个入【rù】口上【shàng】了，应该都能【néng】看得懂【dǒng】。后来，群【qún】里滴滴哥表示这【zhè】种【zhǒng】代码不【bú】行，不能一眼看出来它干了什么。于是怒提了一波【bō】pull request重构了【le】一版，入【rù】口是这样【yàng】的：

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

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

确实牛逼。

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

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

到这，应【yīng】该大【dà】多数人还能跟上【shàng】吧？在讲具体的代码之前【qián】，我们先来简单看看去重【chóng】功【gōng】能的代码结【jié】构（这会对后【hòu】面【miàn】看【kàn】代码有帮助）

去【qù】重【chóng】的逻辑可以统一【yī】抽【chōu】象为：在X时间段内达到了Y阈值，还记得我曾经说过：「去重【chóng】」的本质：「业务Key」+「存储」。那么去重【chóng】实现【xiàn】的【de】步骤可以简单分为（我【wǒ】这边存储就用【yòng】的Redis）：

通【tōng】过Key从Redis获取记【jì】录判【pàn】断该Key在Redis的记【jì】录是否符【fú】合条【tiáo】件【jiàn】符合条件的则去重，不符合条件的则重新【xīn】塞进Redis更新记录

为了方便调【diào】整去重的参【cān】数，我把【bǎ】X时间【jiān】段和Y阈值都放到了【le】配置里{"deduplication_10":{"num":1,"time":300},"deduplication_20":{"num":5}}。目前有【yǒu】两种去重的具体实【shí】现：

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

2、一天【tiān】内相【xiàng】同的用户如果已【yǐ】经【jīng】收到某渠道内容5次【cì】，则应该被【bèi】过滤掉

从配置中心【xīn】拿【ná】到配【pèi】置信【xìn】息了以后，Builder就是根据这两种类型【xíng】去构建出DeduplicationParam，就是以下代码【mǎ】：

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

Builder和DeduplicationService都用【yòng】了类似的【de】写【xiě】法（在子类初始化的时候指定类型，在父类统一接收，放到【dào】Map里管【guǎn】理）

而统一管理着这些服【fú】务【wù】有个中心【xīn】的【de】地方【fāng】，我把这取名为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);}}

前面提到的业务【wù】Key，是在AbstractDeduplicationService的【de】子类下构建的：

而【ér】具体【tǐ】的去重逻辑实现则都【dōu】在LimitService下，{一天内【nèi】相【xiàng】同的用户如果已经收到【dào】某【mǒu】渠道内容5次【cì】}是在SimpleLimitService中处【chù】理使用mget和pipelineSetEX就【jiù】完成了实现。而【ér】{5分钟内相同用户如果收到相同的内容}是在【zài】SlideWindowLimitService中处理【lǐ】，使用了lua脚本完成【chéng】了实现。

LimitService的代码都来【lái】源于@caolongxiu的pull request，建议大【dà】家可【kě】以对【duì】比commit再学【xué】习一番：https://gitee.com/zhongfucheng/austin/pulls/19

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

2、内容去重采用【yòng】的是新开发的基于redis中【zhōng】zset的【de】滑动窗口去重，可以【yǐ】做到严格控制单【dān】位时间内的【de】频次。

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

4、redis的key增【zēng】加前缀【zhuì】做到数据隔离（后【hòu】期可能【néng】有动态更【gèng】换去重方【fāng】法的需求）

5、把【bǎ】具【jù】体限【xiàn】流去重方法从DeduplicationService抽取【qǔ】出来，DeduplicationService只【zhī】需设置构造【zào】器注入【rù】时注入的AbstractLimitService（具体限流去重服务）类型即可动【dòng】态更换【huàn】去重的方法 6、使用雪花算法生成zset的唯【wéi】一value,score使用【yòng】的【de】是当前的时间戳

针对滑动窗口去重，有会引申出新【xīn】的问题：limit.lua的逻【luó】辑？为什么要移【yí】除【chú】时间窗口【kǒu】的之前的数据【jù】？为什么ARGV[4]参【cān】数要唯一？为【wéi】什么要expire？

A: 使用滑动窗口可【kě】以保证N分钟达【dá】到【dào】N次进行去【qù】重。滑动窗口可以回顾下TCP的，也可以【yǐ】回顾【gù】下刷LeetCode时【shí】的一些题，那【nà】这为什么要移【yí】除，就不【bú】陌生【shēng】了。

为什【shí】么ARGV[4]要【yào】唯一，具体可以看看zadd这条【tiáo】命令【lìng】，我【wǒ】们【men】只需要保证每次【cì】add进【jìn】窗口内的成员【yuán】是唯一的，那么就不会触发有更【gèng】新的操作（我认为这样设计会【huì】更加简单些），而唯一Key用雪【xuě】花算【suàn】法比较方便。

为什么expire？，如果【guǒ】这【zhè】个key只被调用一次。那就很有【yǒu】可能在redis内存常驻了，expire能【néng】避免这种【zhǒng】情况【kuàng】。

推荐项目

最后【hòu】再叨叨【dāo】吧，很多人可能【néng】会发一【yī】段截图，跑来问我为什么要这样【yàng】写，为什【shí】么要以这种方式实现，能不【bú】能以【yǐ】这种【zhǒng】方式实现【xiàn】。这时候，我【wǒ】更【gèng】想看到的【de】是：你已经【jīng】实现【xiàn】了【le】第二种方式了，然后探讨你写的这种方案好不好，现有的代【dài】码差在哪【nǎ】里。

毕竟问问题很简单【dān】，我又【yòu】不【bú】是客服【fú】，总不能没诚【chéng】意的问题我都得一一【yī】回答吧。

如果【guǒ】想学Java项目的，我还是强烈推荐我的开【kāi】源项目消【xiāo】息推送平【píng】台Austin，可以用【yòng】作毕【bì】业设计，可以用作【zuò】校招，可以看看生产环【huán】境是怎么推送消【xiāo】息的【de】。

仓库地【dì】址（可点击阅读原文【wén】跳转）：https://gitee.com/zhongfucheng/austin

我开【kāi】通【tōng】了【le】股东服务内【nèi】容，感兴趣可以点击下【xià】方看【kàn】看，主要针对的是项目哟

VIP服务