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

大家好，我3y啊。由于去重逻【luó】辑重构【gòu】了几次，好多股东直呼看【kàn】不懂，于是我今天再【zài】安【ān】排一【yī】波对代码的解析吧【ba】。austin支持两种去重【chóng】的类【lèi】型【xíng】：N分钟相同内容【róng】达【dá】到N次去重【chóng】和一天内N次相同渠道频次去重。

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

(资料图片仅供参考)

publicvoidduplication(TaskInfotaskInfo){//配置示【shì】例:{"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】营总规【guī】则去重(一天内【nèi】用【yòng】户收到最多同一个渠道的【de】消息次数)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);}

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

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

确实牛逼。

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

publicvoidduplication(TaskInfotaskInfo){//配【pèi】置【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);}}}

到【dào】这，应该大多【duō】数人还能跟【gēn】上吧？在讲具体的代码【mǎ】之前，我们【men】先来简【jiǎn】单看看去重功能的【de】代【dài】码结构（这会对后面【miàn】看代码有帮助）

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

通过Key从Redis获取【qǔ】记录【lù】判【pàn】断该Key在Redis的记录是否符合条【tiáo】件符合条件的则去重，不【bú】符【fú】合【hé】条件的则【zé】重【chóng】新塞进Redis更新记录

为了方便调整【zhěng】去重的参【cān】数，我【wǒ】把X时间段和【hé】Y阈值【zhí】都放到【dào】了配【pèi】置里{"deduplication_10":{"num":1,"time":300},"deduplication_20":{"num":5}}。目前有两种去重的具体实现：

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

2、一天【tiān】内相同的【de】用户如果已经收到某【mǒu】渠【qú】道内容5次，则应该被【bèi】过滤掉

从配置中心拿到配置信【xìn】息了以后【hòu】，Builder就是根【gēn】据这两【liǎng】种类型去【qù】构建出DeduplicationParam，就【jiù】是以下代【dài】码：

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

Builder和【hé】DeduplicationService都【dōu】用了类【lèi】似的写法（在子【zǐ】类【lèi】初始化的时候指定类型，在父类【lèi】统一接收，放到【dào】Map里【lǐ】管理）

而统一【yī】管理着这些【xiē】服务有个中心的【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);}}

前【qián】面提到【dào】的业务Key，是在【zài】AbstractDeduplicationService的子类下【xià】构建的：

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

LimitService的代码都来源【yuán】于@caolongxiu的pull request，建议大家可【kě】以【yǐ】对比commit再学【xué】习【xí】一【yī】番：https://gitee.com/zhongfucheng/austin/pulls/19

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

2、内容去重采【cǎi】用的是【shì】新开发的基于redis中【zhōng】zset的滑动窗口去重，可【kě】以做到严格控【kòng】制单位时间内【nèi】的频【pín】次。

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

4、redis的key增加【jiā】前缀做到数据【jù】隔离（后期可能【néng】有动态【tài】更换去重方【fāng】法的需求）

5、把具体【tǐ】限流去重方法从【cóng】DeduplicationService抽取出来，DeduplicationService只需【xū】设置构造【zào】器注入时【shí】注入的AbstractLimitService（具【jù】体限流去重服务）类型即可动态更换去重的方法 6、使用【yòng】雪【xuě】花算法生【shēng】成zset的唯一value,score使用的是当【dāng】前的时间戳

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

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

为什么【me】ARGV[4]要【yào】唯一，具体【tǐ】可以看看zadd这条命令【lìng】，我【wǒ】们只【zhī】需要保证每【měi】次add进窗【chuāng】口【kǒu】内的成员是唯一的，那么【me】就不会【huì】触发【fā】有更新的操作（我认为这样设【shè】计会更【gèng】加【jiā】简单些），而唯一Key用雪花算法比较方便。

为【wéi】什么【me】expire？，如【rú】果这个【gè】key只被调用一次。那就很有可【kě】能在redis内存常【cháng】驻了，expire能避【bì】免这种情况【kuàng】。

推荐项目

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

毕竟问问题很简单，我又不【bú】是【shì】客服，总不能【néng】没诚意的问【wèn】题我都得一一回答【dá】吧【ba】。

如果想学【xué】Java项【xiàng】目的，我还是【shì】强烈【liè】推荐我的开源项目消息推【tuī】送平台Austin，可【kě】以【yǐ】用作毕业设计，可以【yǐ】用作校招，可以看看【kàn】生产【chǎn】环境是怎【zěn】么推送消息的。

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

我【wǒ】开通了股【gǔ】东服【fú】务内容，感兴趣可以点击下方【fāng】看看，主要针【zhēn】对的是项【xiàng】目哟

VIP服务