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

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

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

(资料图片仅供参考)

publicvoidduplication(TaskInfotaskInfo){//配置示例【lì】:{"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);//文案【àn】去重【chóng】DeduplicationParamcontentParams=DeduplicationParam.builder().deduplicationTime(contentDeduplication.getLong(TIME)).countNum(contentDeduplication.getInteger(NUM)).taskInfo(taskInfo).anchorState(AnchorState.CONTENT_DEDUPLICATION).build();contentDeduplicationService.deduplication(contentParams);//运营总规则去重(一天内用户【hù】收到最多【duō】同【tóng】一个渠道的【de】消息次数【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);}

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

publicvoidduplication(TaskInfotaskInfo){//配【pèi】置样【yàng】例：{"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】想他的思路就【jiù】是把构建去重参数和【hé】选择具【jù】体的去重服【fú】务给封装起来了，在最【zuì】外层的代【dài】码看起来就很简洁【jié】了【le】。后来又【yòu】跟他聊了下，他【tā】的设计【jì】思【sī】路是这样的：考虑到【dào】以【yǐ】后会有其他【tā】规则的去重就把【bǎ】去重逻【luó】辑【jí】单独【dú】封装起来了，之后用策略【luè】模【mó】版的设计模式进行【háng】了重构，重构后的代码 模版不变，支持各种【zhǒng】不同策略的【de】去重，扩展性更高更强更简【jiǎn】洁

确实牛逼。

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

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);}}}

到这，应该大多数人还能跟上吧？在【zài】讲具体的代【dài】码【mǎ】之前，我们【men】先【xiān】来简单看【kàn】看去【qù】重【chóng】功能的【de】代码【mǎ】结构（这会对后面看代码有帮助）

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

通过Key从Redis获【huò】取记录判断该Key在Redis的【de】记录是【shì】否符合【hé】条件符合条件的则去【qù】重，不符合条件的则【zé】重【chóng】新【xīn】塞进【jìn】Redis更新记录

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

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

2、一天内相同【tóng】的用户如果已经收到某【mǒu】渠道内容5次【cì】，则【zé】应【yīng】该被过滤掉【diào】

从【cóng】配置中心拿到配置信息【xī】了以后，Builder就是根据这两种类型去构建【jiàn】出DeduplicationParam，就是【shì】以【yǐ】下代码【mǎ】：

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

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

而统一管理【lǐ】着这些【xiē】服【fú】务有【yǒu】个中心的地方，我把这取名为【wéi】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);}}

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

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

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

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

2、内【nèi】容去重采【cǎi】用的是新开发的基于redis中zset的滑动窗【chuāng】口【kǒu】去【qù】重【chóng】，可以做到严格控制【zhì】单位【wèi】时间内的频次。

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

4、redis的key增加前缀做到数据隔离（后期可【kě】能有【yǒu】动态更换去【qù】重方法的【de】需【xū】求）

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

针【zhēn】对滑【huá】动窗【chuāng】口去重，有会【huì】引申出新的问【wèn】题【tí】：limit.lua的逻辑？为什么要移除【chú】时间窗口的之前【qián】的数【shù】据？为什么ARGV[4]参数【shù】要唯一？为什么要expire？

A: 使用滑动窗【chuāng】口可以【yǐ】保证N分【fèn】钟达【dá】到N次进行去重【chóng】。滑动窗口【kǒu】可以回顾下【xià】TCP的，也可以回顾下刷LeetCode时的一【yī】些题，那这为什么【me】要移除，就不陌生了。

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

为【wéi】什么expire？，如果这【zhè】个【gè】key只被调用一次。那就很【hěn】有可能【néng】在redis内存常驻了，expire能避免这种情况。

推荐项目

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

毕【bì】竟问【wèn】问【wèn】题很简单，我又不是客【kè】服，总不能没诚意【yì】的问题我都得一【yī】一回答吧。

如果【guǒ】想学Java项目的，我【wǒ】还是强烈推荐【jiàn】我的开源项【xiàng】目消息推送平台Austin，可以用作毕业设计，可以【yǐ】用【yòng】作校【xiào】招【zhāo】，可【kě】以【yǐ】看看生产环境是怎么推送消息【xī】的。

仓库地址【zhǐ】（可点击阅读【dú】原文跳转）：https://gitee.com/zhongfucheng/austin

我开通了股东【dōng】服【fú】务内【nèi】容，感【gǎn】兴趣可以点击下方看看，主【zhǔ】要针对的是项目哟

VIP服务